Product Image Optimisation for Core Web Vitals

Your supplier sends over gorgeous product photos: 4000 by 4000 pixels, 7 MB each. On your category page you show them as a 300-pixel thumbnail, but the browser still downloads the full 7 MB. With 40 products on a page that is nearly 300 MB of imagery going over the wire. On mobile, on 4G, on the bus.

And that is exactly the moment Google measures. The largest element that appears on screen, almost always a product photo, determines your Largest Contentful Paint. With files like these it sits firmly in the red. Not because your theme is bad or your hosting too cheap, but because the image coming in was never made for a webshop.

Why your product page is slow: the photo is the culprit

When a product page feels slow, everyone points at the theme or the plugins first. Usually unfairly. Images are the heaviest part of an average page: according to the HTTP Archive Web Almanac 2025, roughly 36 to 37 percent of the total page weight, with about 911 KB of imagery on a median mobile homepage, more than JavaScript and fonts combined. On a product catalogue with unprocessed supplier photos that figure is far higher still.

The sting is in the mismatch. A file 4000 pixels wide that you show in a 300-pixel slot is first fetched in full by the browser and only then scaled down. You pay the bandwidth of the big photo and get a small one back.

What Google actually measures: Core Web Vitals and LCP

Google assesses the loading experience of your page with three Core Web Vitals. LCP (Largest Contentful Paint) measures how quickly the largest element becomes visible, INP (Interaction to Next Paint) how quickly your page responds to a click, and CLS (Cumulative Layout Shift) how much the layout still jumps around while loading. The thresholds: LCP under 2.5 seconds, INP under 200 milliseconds, CLS under 0.1.

For product photos, LCP is the vital that hurts. According to web.dev, 2.5 seconds or less is good, 2.5 to 4 seconds needs improvement, and above 4 seconds is poor, measured at the 75th percentile of your page views. It is also the hardest of the three: the Web Almanac 2025 shows that only 62 percent of mobile pages hit a good LCP.

Core Web Vitals are a confirmed part of Google’s page experience signals. Speed will not turn a bad page into a good one, but between two equally relevant results it can be the deciding factor. And your competitor may well have their imagery in order.

What speed really costs you: from load time to revenue

This is not a technical detail for your developer, it hits your till. Google widely cites the figure that 53 percent of mobile visitors drop off at a load time of more than 3 seconds. And Deloitte’s study “Milliseconds Make Millions”, across 37 brands and more than 30 million sessions, showed that a 0.1-second faster load time raised retail conversion by 8.4 percent and average order value by 9.2 percent.

The problem at the source: supplier photos are not made for your webshop

Suppliers shoot for the printer and the catalogue, not for your product page. What you receive is a studio file: a JPEG of 4000 by 4000 pixels, sometimes a 4.2 MB HEIC photo straight off a phone, in a quality that is stunning on paper and pure dead weight online.

• Photos of 6 to 8 MB where your page would need 60 KB.
• Formats like HEIC or TIFF that not every browser shows without a detour.
• The same lifestyle shot delivered twenty times for twenty variants (purple, lilac, violet) and stored twenty times.

Fixing it by hand means opening every file, exporting it at the right size, compressing it and uploading it. For a hundred products that is a day. For a growing range it is never done.

What you can automate: WebP, the right size and dedup

Optimising product photos for your webshop is not a per-product design job. It is three mechanical steps that a pipeline repeats flawlessly and endlessly.

Converting to WebP

According to Google’s own study, WebP delivers files 25 to 34 percent smaller than JPEG at equal visual quality, measured on SSIM. And it is safe: according to caniuse.com, some 96 to 97 percent of browsers support WebP, with JPEG as a fallback for the rest. AVIF goes a little further but has narrower coverage, so WebP is the sensible standard.

The right size per slot

A thumbnail does not need 4000 pixels. Google explicitly advises serving imagery at the right size per device via srcset or picture, so a phone gets a small variant and a large screen gets the big one. Set it up once, and every new photo rolls out automatically in every size.

Store duplicate photos once

Wholesalers often deliver the same lifestyle shot for a whole series of variants. Dedup spots that and stores the file once instead of thirty times. That saves storage and keeps your media library tidy.

What product image optimisation is NOT (and why that is honest)

Worth being clear about, because a lot gets promised in this corner. This is compression and format optimisation. It is not background removal, not watermark removal and certainly not AI upscaling that turns a bad photo into a good one. An ugly source photo stays an ugly photo, only lighter.

And it is non-destructive. Your originals stay put and your shop is never overwritten. You get optimised variants alongside your source, landing neatly in the connection with WooCommerce and Magento. Want to see how that fits your existing structure? Read how SyncRefine reads your existing shop and delivers imagery at the right size.

Checklist: is your imagery ready for speed and Google?

Run through these points before you conclude that your theme is slow:

• Do you serve WebP (with JPEG as a fallback) instead of bare JPEGs?
• Does every slot get its own size, or do you load the big file everywhere?
• Is the photo above the fold NOT lazy-loaded, so your LCP does not drop away?
• Are identical photos stored once instead of per variant?
• Do you measure LCP on mobile at the 75th percentile, not on your fast office wifi?