Core Web Vitals for Ecommerce: LCP, INP and CLS Thresholds by Platform

Most store owners start reading up on Core Web Vitals for their ecommerce site after seeing red numbers in Google Search Console, or after hearing that "Google punishes slow sites." The truth is more measured: Core Web Vitals is one ranking signal among many, and how well you score depends heavily on the platform your store runs on. We cover the general introduction to the three metrics and how to measure them in our Core Web Vitals article — here we focus on what's specific to ecommerce: catalogues with thousands of product photos, payment and recommendation scripts, and banners and pop-ups that shift the page layout at the worst possible moment.

Three metrics and their thresholds — measured at the 75th percentile

Core Web Vitals is a set of three performance metrics, each with a precisely defined "good / needs improvement / poor" threshold:

• LCP (Largest Contentful Paint) — the time it takes to render the largest visible element on the page. According to web.dev: "A good LCP value is 2.5 seconds or less." Google's threshold table classes anything above 4,000 ms as poor, and everything in between as needing improvement. In a store, LCP is often decided by the main product photo, a promotional slider on the homepage, or the first row of a category grid.
• INP (Interaction to Next Paint) — the time between a user's interaction (a click, a tap, a key press) and the moment the browser actually updates the screen in response. web.dev states: "An INP below or at 200 milliseconds means a page has good responsiveness. An INP above 200 milliseconds and below or at 500 milliseconds means a page's responsiveness needs improvement." Above 500 ms, a page has poor responsiveness. This is the metric directly tied to the "Add to cart" button, category filters and variant configurators.
• CLS (Cumulative Layout Shift) — a measure of unexpected layout shifts. According to web.dev: "Good CLS values are 0.1 or less. Poor values are greater than 0.25." Anything in between needs improvement. In a store, the usual culprit is a cookie-consent banner, a discount pop-up, or a late-loading ad that slots in above the content right as the customer starts scrolling.

All three thresholds are measured at the 75th percentile of visits, separately for mobile and desktop. web.dev puts it this way: "a good threshold to measure is the 75th percentile of page loads, segmented across mobile and desktop devices." For a single metric, web.dev explains: "if at least 75 percent of page views to a site meet the 'good' threshold, the site is classified as having 'good' performance for that metric." To pass Core Web Vitals as a whole, a page has to clear that bar on all three metrics at once — back on the Web Vitals overview: "Tools that assess Core Web Vitals compliance should consider a page passing if it meets the recommended targets at the 75th percentile for all three of the Core Web Vitals metrics."

INP replacing FID — the change from 12 March 2024

If you've come across an article or a training course that still lists FID (First Input Delay) as one of the three Core Web Vitals metrics, you're looking at an outdated version. Google announced on the web.dev blog: "Today's the day! After years of work, we're finally ready to make Interaction to Next Paint (INP) a stable Core Web Vital metric," noting that the change addresses "many of the shortcomings of First Input Delay (FID)." The post carries a last-updated date of 2024-03-12 — 12 March 2024. Chrome then deprecated FID: its tools would "no longer guarantee FID availability," and developers had until 9 September 2024 to move over to INP.

The difference isn't cosmetic. FID only measured the delay before the browser started processing the very first interaction — and only the first one. INP measures responsiveness across the page's entire lifecycle, for every interaction, and reports the longest one observed, ignoring outliers. A store where adding the first product to the cart feels instant, but filtering a category after scrolling down starts to lag, could have scored well on FID and poorly on INP. If your reporting vendor or SEO plugin still shows FID as the headline responsiveness metric, that's a sign the tool hasn't been updated since March 2024.

How much it actually weighs in Google's ranking

Core Web Vitals are officially part of page experience — the group of signals Google uses to describe how good it is to use a page. Google's own Search Central documentation is direct about it: "Google Search always seeks to show the most relevant content, even if the page experience is sub-par. But for many queries, there is lots of helpful content available." It continues: "There is no single signal. Our core ranking systems look at a variety of signals that align with overall page experience." And the part that matters most to a store owner staring at a report in Search Console: "Keep in mind that getting good results in reports like Search Console's Core Web Vitals report or third-party tools doesn't guarantee that your pages will rank at the top of Google Search results; there's more to great page experience than Core Web Vitals scores alone."

The same page adds a more precise distinction a paragraph later: "Core Web Vitals are used by our ranking systems," but "Beyond Core Web Vitals, other page experience aspects don't directly help your website rank higher in search results." The practical takeaway: CWV is a real but limited signal — it mostly acts as a tiebreaker when you're competing against sites of broadly similar content quality. A green score in Search Console won't outweigh thin product content or a page that isn't indexed; good content with a weak CWV score can still beat weaker content with a good one. That's not a reason to ignore performance — it's a reason not to treat it as your only SEO lever.

Field data vs. lab data — where the numbers actually come from

Two kinds of data tell you different things about performance, and you need both:

• Field data comes from real users. web.dev defines it as: "Field data is determined by monitoring all users who visit a page and measuring a given set of performance metrics for each one of those users' individual experiences." The source is CrUX (Chrome User Experience Report) — developer.chrome.com describes it as "a dataset that reflects how real-world Chrome users experience popular destinations on the web." It's CrUX field data — not a crawler's own measurement — that feeds the Core Web Vitals report in Search Console (more on that below).
• Lab data comes from a controlled environment: "Lab data is determined by loading a web page in a controlled environment with a predefined set of network and device conditions" (web.dev). This is the result of a PageSpeed Insights test or a local Lighthouse run — repeatable, but disconnected from the real network conditions your customers are actually on.

Which score matters more? If you have both for a given page, web.dev is direct: "field data is what you should use to prioritize your efforts... it's the most accurate way to really understand what your users are struggling with." Lab data is useful for diagnosing a specific cause (which script is blocking the render, which image is too large) — but not for judging whether your store passes the CWV threshold as a whole.

PageSpeed Insights (PSI) combines both perspectives in one report: "PSI provides both lab and field data about a page," and the real-user data "is powered by the Chrome User Experience Report (CrUX) dataset," covering the "previous 28-day collection period." The Lighthouse score in PSI splits into bands: "90 or above is considered good. 50 to 89... needs improvement, and below 50 is considered poor." The Core Web Vitals report in Google Search Console draws on the same field data — per Google's own description: it groups URLs by status ("Poor," "Need improvement," "Good"), by metric, and by groups of similar pages, where a group's status "is that of the worst performing metric for that URL group." And on the data source: "The data for the Core Web Vitals report comes from the CrUX report" — real-user field data, not a one-off test result.

Core Web Vitals by ecommerce platform — more than double the gap

The theory says there's one threshold for everyone. In practice, what your store actually runs on heavily affects your odds of clearing it. The HTTP Archive Web Almanac 2025 (Chapter 13, "Ecommerce," crawl data from July 2025, published January 2026) measured the share of sites with a "good" CWV score — meaning they pass all three thresholds at the 75th percentile — broken down by ecommerce platform:

The chapter sums it up: "A site is considered 'good' on CWV when it passes all three thresholds," and it attributes the gap between platforms to a single metric: "LCP is the biggest differentiator." For WooCommerce, that shows up clearly: its weak point is specifically LCP (45% good scores on desktop, 39% on mobile in the chapter's per-metric tables), while INP actually does well for it (99% good on desktop, 88% on mobile), and CLS sits at 68% on desktop and 85% on mobile. The main bottleneck, then, is render time for the largest page element; the chapter links WooCommerce's weaker numbers to its "infinite customization nature," and the stronger results elsewhere to platforms that ship fast themes and tightly controlled app ecosystems.

Two caveats on this table. First: the data is global — the Web Almanac detects platforms through technology fingerprinting (Wappalyzer) across a large worldwide sample of sites; there's no separate row for any single country. Second: no edition of the Web Almanac (2024 or 2025) publishes a single aggregate figure for "% of ecommerce sites with good CWV" — only the platform breakdown above. Treat the table as pointing to where a given technology's typical problem lies, not as a verdict on your specific store — you can score meaningfully better or worse than average on the same platform.

What usually breaks LCP, INP and CLS in a store

Each of the three metrics has its own typical failure mode in ecommerce. The Web Almanac 2025 chapter points to the usual sources: for LCP — hero images, product grids and render-blocking CSS/JS; for INP — heavy JavaScript, third-party tags and main-thread contention; for CLS — late-loading product images, personalisation widgets and promotional banners. None of the sources checked publish a percentage breakdown of causes specific to any one market:

• LCP usually breaks on exactly what it measures — the time to deliver the largest visible element. In a store that's typically the main product photo or the homepage hero banner: too large a file, the wrong format, no preload priority, or a backend that's slow to respond with product data before the browser can start rendering anything.
• INP breaks under a pile-up of JavaScript running in response to user interaction — payment scripts, shipping-cost calculators, chat widgets, "similar products" recommenders, all listening for the same clicks and competing for the browser's main thread. The customer clicks "Add to cart," and the page happens to be busy with something else.
• CLS breaks on content inserted after the page has already rendered without reserved space for it — cookie-consent banners, discount pop-ups, late-loading ads, or images with no defined dimensions that "pop in" and push everything below them down.

The underlying mechanism is the same in every case: something loads later than it should, or occupies the browser's thread longer than it should. Fixing it starts with identifying the specific element — and that's what lab data is for, not field data.

A 30-day improvement plan

1. Week 1 — measure before you start fixing anything. Run the Digital Vantage website speed test on the homepage, a category listing and a product page — three different templates with different problem profiles. Check the Core Web Vitals report in Search Console at the same time, so you're also looking at field data, not just a single test run.
2. Week 2 — LCP. Identify which element wins "largest visible element" on each of the three templates. Check its format, file size and whether it carries loading priority. Also check server response time — an optimised image won't help if the backend itself responds slowly.
3. Week 3 — INP. Go through which scripts load and execute on product pages and in the cart. Scripts that aren't needed immediately (chat widgets, marketing pixels, review widgets) can often load with a delay, after the user's first interaction.
4. Week 4 — CLS. Go through the pages with network throttling enabled and check what's shifting the layout: cookie banners, pop-ups, images with no defined dimensions. Reserve space for them up front instead of inserting them after the fact.
5. After 30 days — measure again. Compare your test result and the Search Console data against the starting point. Field data updates with a delay (CrUX collects data over a period, not from a single moment), so you'll see the real picture of the change after a few weeks, not the next day.

Some of this work can be done yourself if you have access to the template code and someone who can edit it; other parts — especially server-side changes, an image CDN, or rebuilding how scripts load — usually need a developer. There's no credible, publicly available average price for this kind of optimisation work, so we're not quoting one here — the cost depends on how many templates a store has, how many third-party scripts are wired in, and whether the problem sits in the code or in the hosting itself. If you'd rather hand this to someone who measures first and prices a specific scope afterwards, get in touch.