Core Web Vitals on an ecommerce site: what's actually worth fixing

A PageSpeed Insights lab score can read 92 out of 100 while the field data underneath it, built from real visitors rather than one test run, is still failing all three metrics on the same page, and that gap is usually where the instruction to "fix Core Web Vitals" goes wrong. It skips the only question that actually matters: which of the three failing metrics is costing the business something, and which one is just failing a lab test nobody outside Google ever looks at.

Core Web Vitals (Google's three field-measured page experience metrics: Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift) affects ranking, but as a minor, tie-breaking signal, not the lever most audits treat it as. On an ecommerce site the scores usually fail for reasons specific to the template: heavy product imagery, variant galleries that shift layout, and third-party scripts (reviews widgets, payment badges, tag managers) that only misbehave for real visitors, not for a lab test running against an empty cache. This article covers what each metric measures, why store templates fail them in a way blog pages don't, the image and variant gallery problem specifically, why lab and field data disagree, and how much ranking impact to expect once the scores improve, written as a diagnosis guide rather than a step-by-step optimisation checklist for the ecommerce marketing lead or in-house developer who's been handed a red score and told to fix it.

What LCP, INP and CLS actually measure, in plain terms

Core Web Vitals is three separate tests bundled under one name, and they don't fail for the same reasons, so treating a red score as one problem is where most fixes go wrong from the start.

Largest Contentful Paint (LCP) measures how long it takes the biggest visible element to finish rendering. On a product page that's almost always the hero product image. Good is under 2.5 seconds, poor is over 4 seconds.

Interaction to Next Paint (INP) measures how long the page takes to visibly respond after a click, tap or keypress, sampled across every interaction in the visit rather than just the first one. It replaced First Input Delay as the official Core Web Vital in March 2024, and the swap matters: FID only measured the very first interaction, so a site could pass FID and still freeze on the "add to basket" click, the fourth or fifth interaction a real shopper actually makes. Good is under 200 milliseconds, poor is over 500.

Cumulative Layout Shift (CLS) measures how much visible content jumps around unexpectedly while the page is loading or after it looks settled. Good is under 0.1, poor is over 0.25.

All three are field metrics first. Google's real numbers come from the Chrome User Experience Report (CrUX), anonymised data from real Chrome users who actually visited the page, not one simulated test run.

Why store templates fail these metrics in a way blog pages don't

A blog post is text and one or two images, rendered once, with almost nothing that reflows after it appears. A product page is a different animal: hero image, thumbnail rail, colour or size swatches, a stock indicator, a reviews summary, a delivery estimate, sometimes an upsell carousel. A category page adds a filter bar and a grid of product images that all need to render before it feels usable. Every one of those is a candidate for a layout shift or a late-loading interaction, and a template that's fine on a two-paragraph landing page routinely falls over on a product detail page (PDP) with a dozen moving parts.

I've seen this often enough on Magento and Shopify audits to treat it as a rule of thumb: on ecommerce, CLS and LCP failures cluster almost entirely on product and category templates, not on content pages. A green blog next to red PDPs comes down to the shape of the page, nothing more mysterious than that.

The images and variant gallery problem

The hero image is usually the LCP element on a PDP, and it's also usually the least optimised image on the site, because product photography gets uploaded once by a merchandising team focused on quality, not file size or delivery format. A large, unoptimised image served without a modern format like WebP or AVIF, and without a size matched to the viewport it's actually rendering into, is the single most common LCP failure across the ecommerce audits I run.

The variant gallery makes the CLS side of this worse. Colour and size swatches that swap the hero image on click are fine if the image container has a fixed aspect ratio reserved in advance. They cause a visible jump if the container only takes its size from whichever image happens to load first. The same problem shows up in "you might also like" carousels lower down the page: if the carousel mounts after its images have already started loading, everything below it shifts the moment it appears.

Third-party scripts: the usual real culprit

If the hero image explains most LCP failures, third-party scripts explain most of the CLS and INP failures I've seen, and they're the harder problem because you often don't own the code causing it. A reviews widget that injects itself after the page has already rendered pushes everything below it down, sometimes by hundreds of pixels, well after the page looked finished. A tag manager firing several marketing pixels in sequence, each one doing its own work on the page, is a common cause of a page that scores fine on LCP but drags on INP the moment a real visitor tries to click something while those scripts are still settling.

This is where a platform without server access changes the job. On 18 Carati's Magento store, where BYLT runs technical SEO and tracking without ever touching the client's code or server, a fix like this has to travel as a browser-ready prototype that their own developers ship as a Magento theme override, not a line we can delete ourselves. It's slower than fixing your own codebase, and it's also the honest version of how most agencies actually have to work on a platform they don't control.

Lab data versus field data, and why they disagree

PageSpeed Insights gives you two different reports on the same page, and I'd rank conflating them as the second-biggest way this kind of audit goes wrong, right after treating the three metrics as one number. The lab data, at the top of the report, is a single simulated run on Google's servers, with an empty cache and a fixed network throttle, and it runs against a fixed script each time, though the result still shifts a few points run to run on normal variance in server response and network conditions. The field data, below it, is 28 days of real Chrome users on real devices, real networks and real sessions, complete with cached state and whatever cookie choice they actually made.

Scripts behave differently under those two conditions. A cookie consent banner or a live chat widget, plenty of ecommerce chrome only fires for a first-time visitor with no prior cookie, and the lab test is always exactly that visitor, while most real ones aren't. A tag manager can load faster in the lab's clean, empty-cache environment than for a returning customer whose browser is carrying months of first-party data. That gap reflects two genuinely different visitors, not a fault in the tool.

The failure mode: a good lab score sitting on top of bad field data

This is the pattern I'd flag first on almost any Core Web Vitals job: someone chases the lab score, gets it green, ships the fix, and the field data, the only number that actually feeds ranking, doesn't move, because the thing hurting real visitors never touched the lab test in the first place. It's usually a script that only fires under a condition the lab test doesn't simulate: a real cookie consent state, a logged-in session, a browser extension.

The fix is to work the other way round. Pull the field data first, from PageSpeed Insights if there's enough traffic or the CrUX dashboard directly if there isn't, and diagnose from there before touching anything. Chasing a green lab score while the field data stays red aims the whole job at the wrong problem, not a half-finished version of the right one.

How much this actually moves rankings

Google has been consistent about the actual weight of Core Web Vitals in ranking: it's one signal among many, closer to a tie-breaker between pages that are otherwise similarly relevant than a lever that outranks a competitor with thinner content or weaker links. I've never seen Core Web Vitals work alone move a page from position eight to position two. I have seen it stop a page losing ground it had otherwise earned, and I've seen the underlying fixes, faster images, fewer blocking scripts, lift conversion rate on their own terms, independent of any ranking effect, which is usually the bigger number on the table anyway.

That's the honest framing for anyone whose real question is "will this get me to page one": probably not by itself. Will it stop the site quietly bleeding ranking and revenue at the same time? Usually, yes.

Where a platform rebuild changes the maths

Most Core Web Vitals problems are fixable inside the platform you already have: image optimisation, reserved space for dynamic content, and an audit of which scripts actually earn their place on which template. The exception is when the platform's own rendering model is the bottleneck rather than any script running on top of it. That's a genuinely different problem, and it's part of why Periodico's storefront was rebuilt headless on Next.js rather than inside a standard theme: control over exactly what renders, when and in what order, isn't something you can bolt onto a template you don't own the rendering pipeline for.

Going headless for Core Web Vitals reasons alone is a big swing for what's usually a script-and-image problem, and I'd only recommend it once the cheaper fixes have actually been tried and the ceiling turns out to be the platform itself rather than the dozen things layered on top of it.

When fixing Core Web Vitals is not the right first move

If your site is converting reasonably, ranking reasonably, and the Core Web Vitals report is the only red flag on an otherwise healthy account, it's rarely the thing worth a large budget first. I'd put it behind a broken checkout funnel, a product feed with disapproved items, or tracking that's undercounting conversions, because those cost more money faster than a borderline LCP score does.

The other case where I'd hold off: a site that's mid-migration or mid-redesign. Optimising Core Web Vitals on a template you're about to replace is work that gets thrown away. Fix it on the template that's actually going to stay live.

If your Core Web Vitals report reads red and nobody's told you which part of it actually matters, our web team can separate the ranking-relevant fixes from the cosmetic ones before any of it gets built, and the SEO side of that work is where we check the fix against the field data, not just the lab score.