Core Web Vitals: what fails and how to check

Google's own field data says a little under half of mobile sites pass all three Core Web Vitals, and the metric that fails most often is loading speed, not the one most operators assume is the problem. You can find out which side of that line your own site sits on in the next ten minutes, for free, with no login, using the same tool Google itself points to.

This piece is built around that check. Each section below states something an ecommerce or SaaS operator commonly believes about Core Web Vitals, gives you the sourced reality, and hands you the exact step to run against your own site before you read the next one. By the end you will know your own pass or fail verdict and which metric is behind it, not just the general shape of the problem.

The myth: "my site feels fast, so Core Web Vitals doesn't apply to me"

Core Web Vitals are three specific, numeric metrics, and none of them is "feels fast." Largest Contentful Paint (LCP) measures loading: a page is "good" at 2.5 seconds or less. Interaction to Next Paint (INP) measures responsiveness: 200 milliseconds or less is good. Cumulative Layout Shift (CLS) measures whether the page jumps around while it loads: 0.1 or less is good. All three are assessed at the 75th percentile of real page loads, split separately for mobile and desktop (Google web.dev, "Web Vitals", fetched 20 September 2026).

That 75th percentile is the detail worth sitting with. It is not your fastest visitor and not your average visitor. It is the point where a quarter of your real traffic had a worse experience than the number you are looking at. The data behind it is the Chrome UX Report (CrUX), "a dataset that reflects how real-world Chrome users experience popular destinations on the web" (Chrome for Developers, "Chrome UX Report", last updated 8 February 2024). It is not a lab simulation and not a guess. It is measured off actual visits to your site, including the one from an old Android phone on patchy 4G, because that visit counts too, and at the 75th percentile it is visitors like that one who decide your score.

So "feels fast" usually means "feels fast on the machine and connection I tested it on." That is one data point. CrUX is thousands, gathered over time from whoever actually turned up, and it doesn't round in your favour just because the office wifi is quick.

This also explains why two people at the same company can disagree about whether the site is slow. The founder testing on a new laptop over fibre and the customer on a three-year-old phone over patchy mobile data are not describing the same page, even though they typed the same URL. Core Web Vitals exist precisely to settle that argument with a number instead of two competing impressions.

Start here. Open pagespeed.web.dev now, in another tab, no account and no sign-up required, and paste in your homepage URL. Leave the report open. You will come back to it in the next section.

The myth: "a green Lighthouse score in Chrome DevTools means I pass"

The report you just ran gives you two different things, and they can disagree with each other. One is lab data: a single simulated page load, on a specific device and network profile, run the moment you clicked "Analyze." The other is field data: the CrUX numbers described above, aggregated from real visits over roughly the trailing 28 days. Chrome's own documentation on CrUX confirms it is this field dataset, not Lighthouse's lab run, that "is used by Google Search to inform the page experience ranking factor" (Chrome for Developers, "Chrome UX Report", last updated 8 February 2024).

A site can score well in a single lab run on a fast test rig and still fail the field assessment, because the field number includes every visitor on a five-year-old phone over patchy data who never shows up in a lab test. The reverse happens too, less often: a site with a mediocre lab score but a healthy real-user base on fast connections and modern devices can still pass in the field. The lab score is a diagnostic for one moment. The field score is the one Google, and your actual customers, experience.

On the report you opened a moment ago, look near the top for a section titled something like "Discover what your real users are experiencing on this page." If it says there isn't enough real-user data for that specific URL, don't give up. Google's own PageSpeed Insights documentation says a low-traffic page falls back to whole-site data instead: "PSI will fall back to origin-level granularity, which encompasses all user experiences on all pages of the website" (Google for Developers, "About PageSpeed Insights," last updated 21 October 2024). Test your homepage and, separately, your best-selling product or category page. Between the two you will usually get a field verdict for at least one of them. The line to look for reads either "Core Web Vitals Assessment: Passed" or "Core Web Vitals Assessment: Failed." That verdict, not the lab score below it, is the one that matters.

The ten-minute self-check, in order

Everything above threads through one practical sequence. Written out in full, so you can run it without hunting back through the piece:

None of this needs a developer, an agency, or a login. It needs ten minutes and the URL of your own site.

The myth: "Core Web Vitals barely affects search visibility, so it doesn't really matter"

Google says plainly that it does. Its own documentation states that good Core Web Vitals, "along with other page experience aspects, aligns with what our core ranking systems seek to reward" (Google Search Central, "Understanding Core Web Vitals and Google Search results," last updated 10 December 2025).

It also says, in the same family of documentation, exactly where that stops: "Google Search always seeks to show the most relevant content, even if the page experience is sub-par" (Google Search Central, "Understanding page experience in Google Search results," last updated 10 December 2025). A page that genuinely answers the query best will usually still outrank a faster page that doesn't. Page experience reads more like a tie-breaker than a trump card: among pages of otherwise similar relevance, which is most of an ecommerce category page's real competitive set, it is exactly the kind of difference that decides who gets the click and who doesn't.

Be honest about what this doesn't prove. Google has not published a number for how many ranking places a Core Web Vitals fail costs any specific site, and nobody outside Google can measure that precisely from the outside. What you can measure is whether you pass or fail against a documented threshold Google itself uses. That is worth knowing regardless of exactly how many ranking positions it moves.

The myth: "slow doesn't cost sales, it just annoys people"

This is the myth with the most money behind proving it wrong, and also the myth where the evidence is older than you'd like, so take both figures with that in mind.

Deloitte and the media agency 55, in a study commissioned by Google, tracked over 30 million user sessions across 37 leading European and American brand sites, hour by hour, for 30 days at the end of 2019. Retail was one of the four sectors studied. The finding: a 0.1 second improvement in mobile page speed increased retail conversion rates by 8.4% and average order value by 9.2% (Google web.dev, case study "Milliseconds make millions," last updated 24 June 2020). That is six years old as of this piece, it is a Google-commissioned study, and it covers 37 specific sites, not yours. It remains, as far as this piece could establish, the largest published study of its kind, which is exactly why it still gets cited.

The older figure is blunter. Google, working with SOASTA, trained a model on real bounce and conversion data. It found that 53% of mobile visitors abandon a page that takes longer than three seconds to load, and that the probability of a mobile visitor bouncing rises 113% as load time goes from one second to seven (AMP Project blog, "New Industry Benchmarks for Mobile Page Speed," 28 February 2017, citing Google/SOASTA Research, 2017). That's 2017 data, nine years old, and the methodology hasn't, as far as this piece found, been independently re-run and published since.

Use both figures for what they are: directional evidence from real, if dated and vendor-adjacent, research that small speed differences move measurable revenue, not a formula for exactly what fixing your own site is worth. Here's the honest way to size it. Take your monthly sessions (organic, or all traffic, whichever you care about), multiply by your conversion rate, multiply by your average order value. That is the revenue currently running through that traffic. Every full second your real-user LCP sits above the 2.5 second "good" threshold is not cosmetic. It is a genuine drag on some share of that number, per the research above, even though nobody can tell you the exact percentage for your specific site without running the test on your own traffic.

The myth: "my platform already handles this for me"

Shopify is the one platform in this list with a genuinely built-in answer. Its Analytics > Reports section includes a web performance report scored on the same three metrics: LCP, INP and CLS, ranked "Good," "Moderate" or "Poor" at the 75th percentile, matching Google's own thresholds exactly (Shopify Help Center, "Web performance reports," fetched 20 September 2026). It needs the Reports staff permission to view, needs the store's private mode switched off to populate with real visitor data, and only holds 90 days of history. If you're on Shopify, that report already exists in your admin right now and is worth checking alongside PageSpeed Insights, not instead of it, because the admin report won't show you the sitewide Search Console breakdown of exactly which URLs are affected.

Magento, Adobe Commerce, WooCommerce and a custom-built stack have no equivalent built-in report. For those, PageSpeed Insights and Search Console's Core Web Vitals report are the whole toolkit, and they're free regardless of platform. No admin dashboard, on any platform including Shopify's own, fixes anything by itself. A "Poor" label describes the problem. It doesn't rewrite the JavaScript, resize the images, or defer the third-party tag that's causing it.

It's also worth saying plainly what a platform switch does and doesn't buy you here. Moving from one platform to another doesn't move your Core Web Vitals score with it: the new theme, the new apps, and the new third-party scripts you install on day one will set your new baseline, for better or worse. Plenty of stores replatform to "fix speed" and reinstall the same weight of chat widgets, review carousels and marketing pixels within the first month. The check in this piece works the same way on any platform, before or after a rebuild, precisely because it measures the page as it actually loads, not which system generated it.

The myth: "I fixed my speed problems years ago, so I'm still fine" (and its twin: "interactivity is my real weak point")

Interaction to Next Paint became the official interactivity metric on 12 March 2024, replacing First Input Delay: "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" (web.dev blog, "Interaction to Next Paint is officially a Core Web Vital," 12 March 2024). FID only measured the delay before a page's very first interaction started processing. INP measures every interaction across the whole visit and reports the worst one that matters. If your last speed project predates that date, or if it only chased a FID number, it was never checked against the metric that replaced it.

Here's the part that surprises most operators. HTTP Archive's 2025 Web Almanac, built on CrUX data from July 2025 and published 15 January 2026, shows INP is actually the metric most mobile sites already pass: 77% good on mobile, 97% good on desktop. Loading, not interactivity, is the one dragging sites down: only 62% of mobile origins get a good LCP score, and 74% on desktop. CLS sits at 81% good on mobile, but only 72% on desktop, which is worse than desktop's LCP number (HTTP Archive, 2025 Web Almanac, "Performance" chapter, published 15 January 2026).

The industry-wide picture has genuinely improved: the overall share of mobile sites passing all three rose from 32% in 2021 to 48% in 2025, and desktop from 41% to 56% over the same years (same source). Real progress, and still under half. Most operators who believe they "fixed speed" years ago assume their remaining risk sits in interactivity, because it's the newer, less familiar metric with the scarier-sounding name. The data says the opposite: check loading first.

There's a reasonably simple explanation for why LCP stays stubborn while INP improves. INP is largely a JavaScript-execution problem: heavy scripts blocking the main thread when someone taps a button, and browsers, frameworks and third-party tag vendors have all spent real effort making that faster by default over the last two years. LCP is more often a content-weight and rendering-order problem: an oversized hero image, a webfont that blocks text from painting, a render-blocking stylesheet, none of which a framework upgrade fixes on its own. It has to be found and fixed on the specific page, which is exactly what running your own check tells you to go and look for.

What your own numbers are actually worth

By now you have run the check. You know your pass or fail verdict, and if it's a fail, you know which of the three metrics is red. That is the entire promise of this piece, and it is worth having even before anything gets fixed. A specific, named constraint (a hero image that's too heavy, a font that blocks rendering, a chat widget loaded in the head, a checkout script running before anything else on the page) is a scoped, priceable piece of work. It is not a platform migration, and it is not a guess.

If your check came back "Failed" and you want that constraint named and priced rather than left as a red label in a dashboard, that's a short, specific conversation, not a sales pitch. Book a look at what a fix would actually cost.