Page speed for an online store: fixes that work

There are two kinds of speed measurement and they routinely disagree. A lab test runs one simulated page load on a chosen device and connection, producing a score immediately. Field data records what actual visitors experienced on their own devices and networks, aggregated over time.

Google evaluates Core Web Vitals from field data at the 75th percentile of page loads over a rolling 28-day window. Two consequences follow. Your typical visitor is not the standard — the standard is close to your slowest quarter, which is where older Android devices on congested mobile networks live. And improvements do not appear immediately, because the window has to move past the old data before the reported figure reflects your fix.

This is why a lab score in the nineties can coexist with failing field results, and why chasing the lab number is a common waste of effort. The lab test is a diagnostic that tells you what is slow and why. The field data is the assessment. Use the first to find problems and the second to decide whether you have solved them.

Google's documented 'good' thresholds, all measured at the 75th percentile of real-user data, are: Largest Contentful Paint at or under 2.5 seconds, Interaction to Next Paint at or under 200 milliseconds, and Cumulative Layout Shift at or under 0.1.

On a product page each maps to something concrete. Largest Contentful Paint is almost always your main product image — the largest thing in the viewport — so its file size, format and loading priority determine that number more than anything else does.

Interaction to Next Paint measures how long the page takes to respond visibly after somebody taps. On a store this is usually JavaScript occupying the main thread: a variant selector that does not react, an add-to-cart button that appears to do nothing for half a second. It is the metric most sensitive to third-party scripts.

Cumulative Layout Shift measures content moving after it has been painted. On a store this is the image that loads without reserved space and pushes the price down, or the promotional bar injected late that moves the add-to-cart button just as somebody reaches for it.

A product page is image-heavy by nature, so images are where most of the available improvement sits.

Serve modern formats. WebP and AVIF produce substantially smaller files than JPEG at comparable quality, and support is now broad enough to use them as the primary format with a fallback.

Size to the display, not to the source. Uploading a 3000-pixel-wide photograph into a slot that renders 600 pixels wide means every visitor downloads several times the data they can see. Use responsive image markup so each device gets an appropriate size.

Always set explicit width and height attributes. This lets the browser reserve the correct space before the image arrives, which is the single most effective fix for layout shift.

Lazy-load images below the fold, and never lazy-load the main product image — deferring the element that is your Largest Contentful Paint makes that metric worse, and it is a common self-inflicted regression. Mark the hero image as high priority instead.

For zoom, keep the high-resolution file and load it when the customer initiates zoom rather than including it in the initial page. That preserves the inspection experience without charging every visitor for it.

A typical store accumulates a chat widget, an analytics tag, two advertising pixels, a reviews widget, a heatmap tool, a payment provider's script and a font service. Each was added by somebody for a defensible reason, and nobody owns the total.

The damage lands mainly on responsiveness. These scripts compete for the same main thread that has to handle taps, which is why a page can look finished and still ignore a press on add-to-cart. They are also outside your control: a third party's slow response becomes your slow page, and their change becomes your regression.

The audit is mechanical and effective. List every third-party request the page makes. Beside each, write who asked for it and what decision it informs. Anything without both gets removed — and on most stores that is several items, including tags for advertising campaigns that ended long ago.

For what remains: load it after the page is interactive rather than blocking, and load on interaction where possible. A chat widget that initialises when somebody clicks the chat button rather than on every page load is the highest-value single change available on many stores. And keep payment provider scripts on checkout rather than site-wide.

Cumulative Layout Shift is the cheapest of the three metrics to fix, needs no infrastructure work, and is the one most often left failing.

The causes are a short list. Images and embeds without reserved dimensions, which push everything below them down when they arrive. Web fonts that swap after paint, where a fallback font of different proportions reflows the text — choosing a fallback with similar metrics and setting the font display behaviour deliberately addresses this. Content injected late: cookie notices, promotional bars, region selectors and app-install prompts, all of which typically appear at the top and displace everything.

The rule that resolves most of it: anything that will appear in the layout should have its space reserved from the first paint, even when its content arrives later. A banner slot that is empty and correctly sized causes no shift.

The reason to care is not the score. Layout shift on a store page has a specific commercial cost — a customer reaching for a button that moves, and pressing whatever replaced it. On a checkout page that is an order lost to a defect nobody would report.

Caching and a content delivery network are the right tools for static assets, and they are frequently deployed in the belief that they address everything.

They do not touch the parts of a store that are unique per visitor. A cart, a checkout, a logged-in account page and a personalised recommendation block cannot be served from a cache without serving one customer another's data. Those responses come from your origin every time, which is exactly where a slow store is usually slow.

Behind that live the real causes: database queries without appropriate indexes, product search scanning more than it should, a plugin doing avoidable work on every request, and an origin server physically distant from your customers. None of these is visible in a lab score of your homepage, and none is improved by a CDN.

A workable order of work: fix images first because that is the largest and easiest win, then audit and defer third-party scripts, then reserve space to eliminate layout shift, then add caching and a CDN for assets, and only then investigate the origin. Re-measure in the field after each step, remembering the 28-day window means the reported number lags your change.