Your product page's largest element arrives last on mobile

Before touching the image pipeline, find out what the browser thinks the largest element is. On a throttled mid-range phone, roughly half of product pages report something other than the product shot: a promotional bar, a cookie banner, a lifestyle banner above the gallery, or a block of review text. Optimising the product image on those pages moves nothing, and teams spend weeks there.

The measurement takes minutes. Load the page on a real device or an emulated one at a 390 CSS pixel viewport with network and CPU throttling, and read the reported largest-contentful-paint entry — DevTools shows it, and a PerformanceObserver watching that entry type reports the element in production. Do it 3 times and take the worst, because a warm cache hides the problem you are looking for.

Confirm the element before you optimise anything

There are only 2 useful outcomes of that first check, and they lead to different pages of work. If the reported element is not the product image, the fix is a layout or content decision — the thing above the product shot is too big, and no image work will help until it is smaller or gone. If it is the product image, you have an image-delivery problem, and the next question is which of 3 stages lost the time.

One thing to rule out first: whether the whole storefront got slower rather than this page. If every page regressed at once and nobody deployed, that is a different investigation entirely — the storefront got slower and nobody shipped code.

The four causes, and the signature that names each

Discovery: the request that starts too late

Browsers scan the HTML for resources before the document has finished parsing, and start downloading images they find there. An image whose URL only appears after a JavaScript gallery component mounts cannot benefit from that scan: the browser has to download the bundle, parse it, execute it, resolve the component's data, and only then discover the image. On a mid-range phone over a constrained connection that sequence is easily a second of dead time before the request is even made.

• Put a real img element for the first frame in the server-rendered HTML. Everything else in the gallery can mount later; the first one cannot.
• Remove loading=lazy from that image. Lazy loading is correct for the other 8 shots in the gallery and actively harmful on the largest one, because it tells the browser to wait.
• Add fetchpriority=high to it, and only to it. Marking 4 images high priority is the same as marking none.
• Check for a redirect before the document. A geo or currency redirect adds a full round trip before any HTML arrives, and it delays every subsequent step — see shoppers landing in the wrong country's storefront.
• If you preload, match exactly. A preload whose candidate set differs from what the img resolves to downloads the image twice and makes the page slower than doing nothing.

Negotiation: bytes with no relationship to the screen

A 390 CSS pixel viewport on a 3x device needs about 1,170 device pixels of image width for a full-bleed product shot. Serving the same 2,400 pixel master used on desktop means roughly 4 times the pixel data and a much larger multiple in bytes once compression is accounted for. This is the most common finding and the easiest to fix, and it is fixed in the markup as often as in the CDN.

The subtler version is a sizes attribute that lies. If the image renders at half the viewport width but sizes says 100vw, the browser dutifully picks a candidate twice as wide as it needs — every time, on every product page, invisibly. Check the attribute against the rendered width at 2 or 3 breakpoints rather than trusting it, because nothing warns you when it is wrong.

Paint: downloaded early, shown late

The signature here is unmistakable once you look for it: the image finishes downloading well before the reported paint. The bytes arrived; something was preventing them from being displayed. Almost always this is the gallery — slides positioned by script, an opacity that starts at 0 and animates in on mount, or a carousel that measures the container before revealing anything.

The fix is to make the first frame render correctly with no JavaScript at all, then let the gallery enhance it. That means the first slide is visible in CSS, sized by an aspect ratio so it does not shift when the image lands, and the carousel takes over on mount without re-mounting the image. Everything competing for the main thread in those first seconds makes this worse, and third-party widgets are usually the heaviest of them — where an on-site assistant should live is partly this decision: an assistant on your site versus a presence in someone else's.

The bytes arrived on time. A carousel measuring its container decided the shopper should wait another 800 milliseconds to see them.

The decision tree

1. Capture on a throttled 390 pixel viewport, 3 times, cold cache. Record the reported largest element.
2. If it is not the product image, stop. Fix the layout above the gallery first, then re-measure — the answer will have changed.
3. Compare the image request start time to the document start. A gap of more than a few hundred milliseconds means the browser did not find it in the HTML: a discovery problem.
4. Compare transferred bytes to rendered CSS pixels. Wildly out of proportion means format or candidate selection: a negotiation problem. Check sizes before blaming the CDN.
5. Compare download-complete to the reported paint. A meaningful gap means the image was ready and something withheld it: a script-order problem.
6. Re-measure after each single change. Changing 3 things at once on a page with this many interacting layers tells you nothing about which one worked.

What this does not fix

Image delivery is the largest single lever on a product page and it is not the only one. A slow first byte, a heavy third-party script stack and a bloated client bundle all sit underneath this work, and none of them is addressed by better imagery. Neither is correctness: a page that paints in under 2 seconds and then shows a price the cart disagrees with has traded one complaint for another — the cart price does not match the page price is a different investigation with a different fix.

It is also worth being precise about the target. The widely used threshold for a good largest-contentful-paint is 2.5 seconds at the 75th percentile of real visits, but the definition and the thresholds are maintained by Google in the Core Web Vitals documentation and they have changed before — check the current text rather than quoting a number from memory, including this one. Lab captures are for diagnosis; the number that matters comes from field data.

Most of this work is unglamorous and easy to get subtly wrong — a preload that duplicates a download, a sizes attribute that quietly doubles every image on the site. If you are choosing someone to do it, the questions worth asking are in choosing a development partner. The surrounding architecture decisions sit in storefront architecture and platform choice, within software for retail and ecommerce; where the same page also has to answer machine readers, that overlaps with AI agents and automation.

• performance
• LCP
• product pages
• storefront architecture