Building a Product Image Pipeline That Does Not Wreck Your Page Speed
An e-commerce product page is mostly images. A typical listing carries a hero shot, four to eight gallery images, a size chart, several thumbnails, and a row of related products — and if none of that has been thought about, it is comfortably five megabytes of payload before any content loads.
Conversion rate is measurably sensitive to load time on mobile. This is one of the few performance problems with a direct, provable line to revenue.
Start at the source, not the CDN
The instinct is to bolt an image CDN on the front and let it sort things out. That helps, but it papers over the real problem: if your photographer is delivering 6000-pixel JPEGs at quality 100 and your CMS is storing them unchanged, every downstream transformation is working from an unnecessarily heavy master and you are paying for storage and transfer on all of it.
Agree a delivery spec with whoever produces the photography. For most catalogues: longest edge 2400px, JPG or TIFF, sRGB, quality 90. That is comfortably enough for a zoom view on a high-DPI display and roughly a quarter the size of an unconstrained export.
Decide your display sizes before you generate anything
Work backwards from the layout. A typical product page needs perhaps four sizes: a thumbnail around 200px, a gallery image around 800px, a zoom view around 1600px, and a mobile hero around 750px. Generate those and nothing else.
The most expensive mistake in product imagery is shipping the zoom-resolution file into the thumbnail slot. It is invisible in testing on a fast connection and it is the single largest source of wasted bandwidth in most catalogues.
Convert to WebP at quality 80-82
For photographic product shots, quality 80-82 is indistinguishable from the source at any size a customer will view it, and lands roughly a third of the equivalent JPG's weight. Strip metadata on the way out — EXIF blocks add tens of kilobytes per image across thousands of SKUs, and they can carry the photographer's camera serial number.
Two exceptions worth handling separately. Products shot on pure white with hard edges — jewellery, electronics, anything with fine detail against a flat background — sometimes look better in lossless WebP, and are often not much larger. And any image with genuine transparency (cut-out products, overlays) needs WebP's alpha support, which is one of the format's real advantages over JPG.
Serve with a fallback, always
Use a <picture> element with WebP sources and a JPG in the <img> tag. On a commerce site the fallback matters more than on a blog, because a broken image on a product page is a lost sale and because your marketing emails, Open Graph previews and marketplace feeds all need the JPG anyway.
Keep JPGs for everything that leaves the site
Marketplace feeds to Amazon, Google Shopping and eBay want JPG. Email campaigns want JPG. Print catalogues want TIFF or PDF. Your WebP set is for your own site and nowhere else — which is a good reason to treat it as a generated artefact rather than a stored asset.
Audit what you actually ship
Once the pipeline exists, verify it from the outside. Load a product page in DevTools with mobile emulation, filter the Network tab to images, and sort by size. Anything over 200 KB on a mobile viewport deserves an explanation. This check takes two minutes and reliably finds the one template that never got updated.
Expected result
A catalogue that has never been optimised typically sees total product-page image weight fall by 60-70% from correct sizing and WebP conversion together, with no visible change to the photography. The sizing usually accounts for more of that than the format change — which is why doing them in the right order matters.