Core Web Vitals thresholds are a floor, not a target

Google’s Core Web Vitals thresholds (Largest Contentful Paint under 2.5 seconds, Interaction to Next Paint under 200 milliseconds, Cumulative Layout Shift under 0.1) were not set to mark the point where user experience or conversion tops out. Google’s own methodology page states the thresholds are “broad” enough to apply across the whole web, then adds that “many sites would benefit from optimizing even beyond the ‘good’ thresholds and should seek to correlate with their individual business metrics.”² Passing the threshold proves a page cleared a bar calibrated to what the median site could already reach. It says nothing about whether that same site has found the point where its own conversion rate stops responding to speed. For anyone treating a green Core Web Vitals dashboard as the finish line, that gap is where revenue quietly leaks.

Four of ten retail sites in a real-user monitoring study reached their own conversion-optimal loading speed before Google’s 2.5-second “good” threshold, meaning they were already passing while still leaving money on the table.

What are Google’s Core Web Vitals thresholds, and what does ‘good’ actually require?

Google’s current “good” thresholds are LCP at or under 2.5 seconds, INP at or under 200 milliseconds, and CLS at or under 0.1, each measured at the 75th percentile of page loads and scored separately for mobile and desktop.¹ INP (Interaction to Next Paint, how fast a page responds to a click or tap) replaced First Input Delay as the third official metric in March 2024; FID is retired.

Metric	Good	Needs improvement	Poor
LCP (Largest Contentful Paint, how fast the main content loads)	≤ 2.5s	2.5s to 4.0s	> 4.0s
INP (Interaction to Next Paint, how fast the page responds to input)	≤ 200ms	200ms to 500ms	> 500ms
CLS (Cumulative Layout Shift, how much visible content jumps while loading)	≤ 0.1	0.1 to 0.25	> 0.25

As of the May 2026 CrUX release, 55.9% of tracked origins pass all three metrics combined, with per-metric pass rates of 68.6% for LCP, 81.3% for CLS, and 86.6% for INP.⁸ Most of the web is still working toward the floor this article argues is not the ceiling.

Why did Google set the thresholds where it did, perception research or achievability?

Google set the thresholds using a two-step process: perception research narrowed a candidate range, then CrUX (Chrome UX Report, real-world field data from Chrome users) data checked which candidate a meaningful share of existing sites could already hit. That achievability check decided where the final line landed. Google states this directly on its methodology page, describing the goal as thresholds “we can apply across the whole of the web.”²

The LCP threshold traces to Allen Newell’s attention research, which put the window before users lose focus at roughly 0.3 to 3 seconds. Google narrowed the candidate range to 1 to 3 seconds on that basis, then checked CrUX and found 42% of mobile origins and 51% of desktop origins already met a 2.5-second cutoff at the time. That coverage level is why 2.5 seconds is the published number today; the perception research only ever set the outer boundaries Google was willing to consider.²

INP followed the same pattern. Timo Kaaresoja’s virtual-button research found delays up to about 100 milliseconds feel instantaneous, with perceived quality dropping noticeably between 100 and 150 milliseconds. CrUX showed 56% of mobile origins and 96% of desktop origins already met a 200-millisecond good threshold. The “poor” cutoff tells the achievability story even more plainly: Google considered 300 milliseconds first, then loosened it to 500 milliseconds specifically so the web’s highest-traffic sites, the top roughly 10,000 origins, would not all cluster into “poor.”²

CLS is the cleanest case. Google states it had no direct perception research to draw on for layout shift and ran internal testing instead, finding scores of 0.15 and above were consistently disruptive to users and scores at or under 0.1 were noticeable but tolerable. Google considered the stricter 0.05 and rejected it for one reason: it was not practically achievable given how common third-party embeds, such as social media embeds, are across real sites.² Call the resulting number an achievability floor, a threshold set at the level a meaningful share of existing sites could already reach rather than the level where a given site’s own outcomes stop improving. All three Core Web Vitals were built this way. Only CLS shows Google saying so this explicitly.

Does passing Google’s ‘good’ thresholds mean you’ve hit your site’s real performance ceiling?

No. A real-user monitoring study of ten unnamed retail sites found four of them reached their actual bounce-rate plateau, the point where further speed gains stop reducing bounce, before Google’s 2.5-second LCP threshold. Across all ten sites, the LCP value that produced the best bounce rate ranged from 100 milliseconds to 1 second, far stricter than “good.”³

The study, published by Embrace.io and authored by Tammy Everts, correlated each site’s own LCP against its own bounce rate rather than importing a shared cutoff. The plateau point varied from 500 milliseconds to 5.6 seconds across the ten retailers, direct evidence that no single number fits every site. The author’s own caution is the sharpest summary of the finding: “you should never assume that meeting external thresholds is actually helping your business.”³

Two scope limits matter here, and the study is honest about both. It measures LCP only, with no equivalent data for INP or CLS, and all ten sites are e-commerce retailers, with no B2B or content-site comparison. Treat this as strong evidence for one metric in one vertical rather than a universal replacement for Google’s thresholds.

Does speed keep paying off past the point where you’re already ‘good’?

Yes, and Google’s own published case studies put a number on it: Vodafone measured an 8% sales lift from a 31% LCP improvement, though these are selected success stories rather than a random sample and should be read that way. Vodafone A/B tested a 31% LCP improvement against roughly 34,000 daily visits per arm and measured an 8% increase in sales and a 15% improvement in lead-to-visit rate.⁵ Lazada tripled its LCP speed and saw a 16.9% lift in mobile conversion rate, one of several similar results Google has published in its business-impact case study index alongside Nykaa, NDTV, and Cdiscount.⁴

The strongest supporting evidence for a continuous, non-threshold relationship between speed and business outcome is older and independent of Google’s own selection: “Milliseconds Make Millions,” a 2019 study commissioned by Google and conducted by Deloitte across 37 European and US brand sites and over 30 million user sessions, found that a 0.1-second improvement in load time correlated with an 8.4% increase in conversions and a 9.2% increase in average order value in retail.⁶⁷ That study predates Core Web Vitals as a named metric set and measures raw page load time rather than LCP, INP, or CLS specifically, so I’m treating it as directionally supportive rather than literal CWV data. What it shows, and what Vodafone’s and Lazada’s results reinforce, is a dose-response curve that keeps climbing well past Google’s threshold instead of flattening at it.

Should every site target the same Core Web Vitals bar?

No, and the honest answer depends on what evidence actually supports rather than what would be tidy to claim. A checkout flow where every added 100 milliseconds has a measurable, priced conversion cost has a stronger case for a self-imposed bar tighter than 2.5 seconds, 200 milliseconds, and 0.1 than a content or editorial site competing on read time rather than transaction completion.

My read: the Embrace.io data that anchors this argument is retail-only and LCP-only, so I can’t point to an equivalent study proving a content site’s optimal curve looks different. What I can say is that the achievability floor was built by design to fit the whole web at once, e-commerce checkout flows and static blog pages alike, and a single number engineered for universal applicability is structurally unlikely to be any one site’s actual optimum. That’s a reasoned extrapolation from how the thresholds were built rather than a second RUM study.

How do you set your own performance bar instead of importing Google’s number?

Build a correlation from your own traffic instead of importing Google’s number. Pull real-user LCP or INP values against your own bounce rate or conversion rate, per page template if you have the traffic to segment that way, and find where your curve actually bends. That bend is your target, whatever value it turns out to be.

In my own PDP (product detail page) scoring and Core Web Vitals audit work across enterprise e-commerce clients, the pattern I see most often is a dashboard that reports pass or fail against Google’s thresholds and stops there. That’s a floor check, useful for catching genuine regressions, and a poor substitute for a business-correlated target. Treating CrUX or PageSpeed Insights output as a pass/fail gate rather than an input to a business correlation is the single most common way client teams undersell the value of continuing to invest in speed once the dashboard turns green. The fix is replacing the borrowed threshold with a curve built from your own traffic, not chasing more decimal precision on Google’s number.

Do Core Web Vitals even move rankings once you’re already past ‘good’?

Barely, and Google says so directly. Google’s page-experience documentation states plainly: “Google Search always seeks to show the most relevant content, even if the page experience is sub-par.”⁹ Core Web Vitals function as one signal among many, and a tiebreaker among comparably relevant pages rather than a dominant ranking lever.

That matters for how a site should frame the business case for going beyond “good.” The case rests on conversion and user experience, not on search rankings. With more than four in ten origins still failing to pass the floor as of May 2026, the sites already clearing it and weighing whether to push further are a minority to begin with. Chase the correlation your own traffic shows you; the ranking upside from doing so, if any exists, is a rounding error next to the conversion upside the studies above already demonstrate.