Product Photo Compression: Format, Quality and What the Browser Actually Downloads

Brand promotion: this article introduces Guangsuan's WordPress hosting and speed optimization service. It is a vendor-introduction piece, not an independent review.

A product page can look finished on a desktop monitor and still feel slow on a phone. The product photographs are sharp, the layout is clean, and yet the page takes a moment too long to settle. Before booking another shoot or exporting the whole catalogue again, it helps to separate the decisions that are usually discussed as one: the dimensions of the file, the way it is encoded, and the file the browser is actually sent.

This article is for ecommerce and marketing teams who publish product photography and want a repeatable check before upload. It covers format choice, quality comparison and delivery, then sets out what a hosting and speed scope can verify. It does not promise a ranking outcome from image work.

The short answer

Format, quality and delivery are three separate decisions. Choose the format by what the picture has to show; set quality by comparing candidates at the size buyers will actually see; then check the live page to confirm which file the browser downloads. Compression reduces the number of bytes an image takes at the dimensions it was exported at. It does not change those dimensions, and it does not decide which file the page serves to a phone. No format is universally best.

Three jobs that get called “compressing the photos”

Resizing, encoding and choosing a resource for a screen are three different jobs. A store often needs all three rather than another pass over one oversized file.

• The file you export. Pixel width, height and crop. A 3,000-pixel export placed in a phone-sized slot stays large unless the page offers a smaller version.
• The encoding. How the image data is stored, and how much visual information a lossy setting discards.
• The delivered file. The markup and any image service decide which derivative the browser receives. This is the part a media library cannot answer for you.

Choosing a format for product photographs

No format is universally best: photographs, transparent graphics, screenshots and diagrams have different requirements. For a product or scene photograph, AVIF, WebP and JPEG are the formats worth comparing, and the check should cover texture, edges, colour, file size and which clients the store supports.

Two habits keep the comparison honest. First, a cut-out with transparency and a screenshot of a size chart are not the same problem as a lifestyle photograph; PNG or lossless WebP may be the better comparison for sharp text and line work, while a photograph is normally compared across lossy options. Second, changing a filename extension does not convert the file. If a JPEG is renamed to .webp without re-encoding, nothing about its compression has changed.

When a page offers alternative formats, the browser selects the first source it supports rather than judging which version looks better. That is why a format switch has to be checked on the live page, not only in the media library.

How much compression is acceptable

There is no universal byte target that fits every product page, and a percentage figure is not a quality verdict. A workable comparison starts from the original asset, notes the job the image has to do, keeps the intended display sizes, and changes one relevant setting at a time.

Inspect the candidates at the real desktop and phone sizes rather than at 100% on a large monitor. Look at the details that affect identification: fabric texture, stitching, a label, a colour gradient, the edge of a transparent product. For a technical image, read every label and confirm the important geometry is still clear. A photograph that looks acceptable in a grid can still fail when a buyer opens the zoom view.

Lossless compression preserves the decoded pixel information represented by the input to that encoding step. Lossy compression discards some information to reduce size, and acceptable settings depend on the content and viewing conditions. Avoid repeated lossy exports from successive derivatives: once detail is gone, saving the file again in another format does not restore it.

Quality numbers are not portable between tools. A setting labelled 75 in one encoder is not guaranteed to mean the same thing in another, so compare the output rather than the number. A record of the source file, output format, pixel dimensions, setting, resulting bytes and visual decision is more useful than a folder of files named final-final-2.

Confirming what the browser actually downloads

Open the live product page, open the browser's network panel, and find the image request. Note the URL, the content type, the transferred size and the cache status. Then compare the delivered pixel width with the width of the slot the image fills on the device you are testing. This is the check that answers the question a screenshot cannot: is the phone receiving a phone-sized file?

Where the page offers several widths, confirm that the image element actually carries responsive alternatives and a sizes value, so the browser has a smaller candidate to choose from. A performance score is not an image-quality review, and the network panel says nothing about whether the product detail is still legible; inspect both.

After replacing an asset, check its final URL, response, content type, cache behaviour and visible result. A CDN or image service may still serve an older derivative or an unexpected oversized version after a replacement. If that happens, purge the affected URL, re-request it, and confirm the response before treating the change as published.

The first-screen image, lazy loading and layout

Lazy loading is a reasonable default for images below the fold, because they are not needed for the first view. The image needed for the initial view, or identified as the page's largest content element, should not be delayed by it. Deferring the main product photograph delays exactly the content the visitor came to see.

Declared width and height are a separate, cheap improvement. They let the browser reserve space before the image arrives, which reduces the layout movement that makes a page feel unstable while photographs load.

A publish checklist for one product photo

1. Keep the master file, and export the display sizes the page actually uses.
2. Compare format and quality candidates at real phone and desktop sizes, one setting at a time.
3. Confirm that the live page delivers a file sized for the slot, not only that the library holds one.
4. Check that the first-screen image is not deferred behind images further down the page.
5. Write accurate alternative text as a separate task; it describes the image and is not a result of compression.
6. Re-check the URL, response and visible image after any replacement or cache purge.

Where Guangsuan fits

Guangsuan provides WordPress hosting and speed optimization for export-oriented websites and WooCommerce stores. Its published scope includes global CDN setup and configuration and WordPress cache and plugin optimization within the plan. It also states that an inquiry site and an online store are not given the same cache rules, because a logged-in buyer, a cart and a checkout path cannot be treated like a public article.

For image work, the useful part of that scope is the re-test: Guangsuan describes checking the actual selected image, the start of the request and the largest content element under the same device and network conditions, and recording cold-cache, warm-cache and bypass requests separately. Its hosting page also lists product image loading and detail-page caching among the optimization priorities for export B2B sites.

The page states its limits plainly. Guangsuan does not promise full PageSpeed scores on every page, and hosting work is not a ranking or inquiry growth guarantee. Those limits are worth reading before comparing a quote with your own checklist. The published WordPress hosting and speed optimization scope sets out the services, tiers and re-testing standard.

For the format and quality comparison itself, Guangsuan's guide to image compression for SEO separates dimensions, encoding and delivery in more detail.

Before you ask for help: what to prepare

• The live URLs of two or three pages that feel slow: a product page, a category page and the heaviest landing page.
• The image URLs the browser actually downloads, captured from the network panel.
• The platform, theme and the apps or plugins that may rewrite image markup.
• The main customer regions, since delivery and caching are measured from a location.
• The paths that must keep working: cart, checkout, payment callbacks and order emails on a store.
• The image rules you want applied: target dimensions, accepted formats, who writes alternative text and who checks the live page.

Frequently asked questions

Does compressing product images improve Google rankings?

Not as a promise. Compression cannot guarantee a specific ranking gain. Correctly sized and delivered images can improve how a page loads, but ranking also depends on content, competition and the search engine's judgement.

Should every product image be converted to WebP or AVIF?

No. Format is a separate decision from file size, and whether a newer format helps depends on the image, the theme and how the store serves it. Confirm what the stack accepts, convert a small set, check the live pages, and keep the originals so the change can be reversed.

Should the main product image be lazy-loaded?

If it is the first-screen element, no. Defer images below the fold instead, and check which image loads first rather than assuming the feature is configured correctly.

Why does my new image still show the old file?

A cache or CDN may still be serving an older derivative. Check the requested URL, the response headers, the content type and the cache status, then purge the affected URL and verify the response before concluding that the replacement failed.