# Core Web Vitals for Ecommerce: The Metrics That Matter

The three Core Web Vitals that matter for ecommerce, realistic retail targets for LCP, INP and CLS, what breaks them, and a checklist to fix them.

Most retailers hear about Core Web Vitals in one of two ways: a marketing agency flags them in an SEO audit, or a developer mentions them after a slow Black Friday. Either way you end up staring at a dashboard full of acronyms, colour-coded red and amber, with no clear sense of which numbers change revenue and which are noise.
There are only three metrics that Google counts as Core Web Vitals, and each one maps to something a shopper actually feels: how quickly the page shows up, how quickly it responds when they tap, and whether it holds still while they read it. This article covers what those three measure on a retail site, the targets worth holding yourself to, what tends to break them on ecommerce stores specifically, and a checklist you can hand to your team.
We build and maintain ecommerce stacks for Australian retailers, and performance work is a standing part of that. The advice below is what we tell our own clients, without the vendor spin.
Why Core Web Vitals matter for retail
Two reasons, and they get conflated more often than they should.
The first is ranking. Core Web Vitals are a confirmed Google ranking signal through the page experience system. They are not the dominant factor; relevance and content still do most of the work, but on a competitive category page where several retailers sell the same product, page experience is one of the tie-breakers.
The second, and the one that shows up in your numbers faster, is conversion. A slow or unstable page loses sales before Google ever re-crawls it. You do not need a case study to believe it: the connection between load time and abandonment is something you can watch in your own analytics once you start segmenting sessions by device and connection speed, and slower sessions almost always convert worse.
So chase Core Web Vitals for revenue first and rankings second. If you fix them purely for SEO you will probably over-invest in the ranking angle and under-invest in the parts that lose you carts.
The three Core Web Vitals and their targets
Google measures each metric at the 75th percentile of real visits, split across mobile and desktop. In plain terms, at least three-quarters of your page loads need to hit the target for the page to pass. An average that looks fine can still fail if your slowest quarter of visitors, often mobile shoppers on a train, are having a bad time.
Largest Contentful Paint (LCP): does the page show up fast?
LCP measures how long it takes for the largest visible element to render, usually your hero image or the main product photo. Google’s “good” threshold is 2.5 seconds or less. On a media-heavy retail site that is a genuine target rather than a gimme, and the biggest offender is almost always the hero image itself.
The common causes on an ecommerce store:

Oversized hero and product images served at full resolution instead of sized and compressed for the device. A 3000px banner pushed to a phone is the classic LCP killer.
Images in the wrong format. Modern formats like WebP and AVIF cut file size substantially over old JPEGs with no visible quality loss.
Render-blocking resources, typically theme CSS and app scripts, that the browser has to fetch and parse before it can paint anything.
Slow server response on category and search pages that run heavy queries, which pushes back the moment the browser can even start rendering.

If your LCP is poor, start with the hero image on your highest-traffic templates. It is the single highest-leverage fix on most stores.
Interaction to Next Paint (INP): does the page respond when tapped?
INP measures responsiveness. When a shopper taps “add to cart”, opens a filter, or expands a size selector, how long before the page visibly reacts? Google’s “good” threshold is 200 milliseconds or less, and anything over 500 milliseconds counts as poor. INP replaced First Input Delay as a Core Web Vital, and the change matters because it captures the responsiveness of every interaction, not just the first.
On retail sites INP is overwhelmingly a third-party script problem. This is the metric that punishes app sprawl:

Review widgets, live chat, personalisation tools, and loyalty apps each ship JavaScript that runs on the main thread and blocks the browser from responding to taps.
Tag managers stacked with marketing tags fire scripts on interaction and page load that compete for the same thread.
Heavy theme code, especially on filtered collection pages where every facet click re-runs logic in the browser.

This is where INP on Shopify in particular becomes a conversation about your app list. Shopify’s ecosystem makes it easy to install a dozen apps, and each one that injects a script adds to the interaction cost. The fix is rarely a single line of code. It is auditing which apps actually earn their place, deferring or removing the rest, and moving what you can off the main thread. If you are on Shopify and INP is red, a focused performance review of the theme and app stack usually finds more to remove than to add.
Cumulative Layout Shift (CLS): does the page hold still?
CLS measures visual stability, the jump you feel when a page loads and content shoves down just as you go to tap something. Google’s “good” threshold is 0.1 or less. It is the most fixable of the three and often the most annoying to shoppers, because a mistimed shift is what makes someone tap the wrong product or, worse, the wrong button at checkout.
The usual retail culprits:

Promotional banners and announcement bars that load late and push the whole page down when they appear.
Images and embeds without width and height set, so the browser leaves no space for them and the layout reflows once they arrive.
Web fonts that swap in and reflow text after the page has already painted.
Injected content from apps, cookie notices, and personalisation blocks that insert themselves above content the shopper is already reading.

Most CLS is preventable at build time by reserving space for anything that loads asynchronously. A banner that has its slot from the first paint does not shift anything when its content arrives.

How to measure them properly
The one distinction that trips teams up is field data versus lab data.
Field data, also called real user monitoring, is what Google actually uses to assess your site. It comes from the Chrome User Experience Report, which aggregates anonymised measurements from real Chrome visitors. It reflects your genuine mix of devices, connections, and locations. The catch is that it is a rolling 28-day average, so improvements take weeks to show up, and low-traffic pages may not have enough data to report.
Lab data comes from a synthetic test run on demand in a controlled environment. It is repeatable and immediate, which makes it the right tool for debugging, but it runs on one simulated device and connection, so it will never perfectly match your field scores. Chasing a perfect lab result is a trap; the point of a lab test is to find and fix the cause, then confirm the improvement later in the field.
A workable toolkit for a retail team:

PageSpeed Insights shows both field and lab data for a given URL in one place. Start here.
Google Search Console has a Core Web Vitals report that groups your URLs by status across the whole site, which is how you find which templates are failing rather than testing pages one by one.
Chrome DevTools and Lighthouse are for developers diagnosing a specific page locally.
WebPageTest gives a detailed waterfall when you need to see exactly which resource is holding up LCP.

Test your templates, not just your homepage. A store passes or fails per URL, and your product and collection pages carry far more traffic and far more third-party weight than the home page most audits start with.
A diagnostic checklist
Work through this with your developer or agency. It moves from the highest-leverage fixes down.

Pull the Core Web Vitals report in Search Console and note which templates fail: home, collection, product, cart, checkout. Fix by template, worst traffic first.
Run your top three templates through PageSpeed Insights on mobile. Record the field scores, then the lab scores separately.
For LCP: identify the largest element. If it is an image, confirm it is sized for the device, served as WebP or AVIF, and not lazy-loaded (the hero should load eagerly).
For LCP: check for render-blocking CSS and JavaScript, and confirm server response time on collection and search pages is not the bottleneck.
For INP: list every app and tag that injects JavaScript. For each, ask whether it earns its place. Remove or defer the rest.
For INP: test the interactions that matter most (add to cart, filters, variant selectors) and measure the delay on a mid-range phone, not a flagship.
For CLS: reserve space for banners, ads, images, and embeds by setting explicit dimensions or slots. Load announcement bars without pushing content.
For CLS: check web font loading so text does not reflow after paint.
Re-test in the lab to confirm each fix, then watch the field data in Search Console over the following month to confirm real users saw the benefit.

If you get through that and the numbers still will not move, the constraint is usually structural: a theme carrying years of accumulated code, or a platform and hosting setup that caps how fast pages can respond. That is the point where a rebuild or a move to a faster architecture is worth costing, though it is the last resort, not the first. Plenty of stores hit “good” across all three without ever going near a replatform.
Where this fits
Core Web Vitals are a useful, honest proxy for whether your store feels fast, and they are cheap to monitor once you know which three numbers to watch. For most retailers the work is unglamorous: right-size the images, prune the app list, stop the page from jumping. None of it requires a new platform, and most of it pays for itself in recovered conversions well before any ranking benefit shows up.
If your scores are red and you want a second opinion on what is actually causing it, that is the kind of work we do every week across Shopify and other platforms. Get in touch to talk through your options.