Core Web Vitals are the three metrics Google uses to measure the experience of someone opening a page: LCP for the time the main content takes to appear, INP for responsiveness to clicks and taps, and CLS for layout stability while the page finishes loading.
The number that counts is not the one you see when you run a test from your own computer. Google assesses a page on data collected from real Chrome visitors over the last 28 days, and a single metric outside the threshold is enough for the whole group of pages to be marked as needing improvement.
What LCP, INP and CLS measure
Google publishes the thresholds and, by its own rule, does not change them more than once a year.
| Metric | What it measures | Good | Needs improvement | Poor |
|---|---|---|---|---|
| LCP | Appearance of the main element | ≤ 2.5 s | 2.5 - 4 s | > 4 s |
| INP | Response to interactions | ≤ 200 ms | 200 - 500 ms | > 500 ms |
| CLS | Unexpected layout shifts | ≤ 0.1 | 0.1 - 0.25 | > 0.25 |
LCP, Largest Contentful Paint, marks the moment the largest element visible on the first screen finishes rendering. It is almost always the opening image, which is why image weight and format move this metric more than anything else. INP, Interaction to Next Paint, measures the delay between an interaction and the visual update that follows, and reports the worst interaction of the visit, not the first. CLS, Cumulative Layout Shift, is a unitless number: the product of the share of the screen that moves and the distance it moves. It is the metric that describes the moment you are about to tap a button and hit another one instead, one of the most tangible frustrations of user experience on the web.
FID left the Core Web Vitals in March 2024
On 12 March 2024 INP replaced First Input Delay as the third stable metric. In the same announcement the Chrome team set a deadline: 9 September 2024 to remove FID from any integration based on the CrUX or PageSpeed Insights APIs, warning that it would be a breaking change without a major version bump.
Two and a half years later, part of the first page of Google UK has not noticed. On 26 September 2026, for "core web vitals" (1,300 searches a month in the UK, DataForSEO), the webdna article in third organic position is dated 7 July 2022 and names Largest Contentful Paint, First Input Delay and Cumulative Layout Shift as the three Core Web Vitals. The Lilo guide at the bottom of the same page, dated 24 November 2023, lists the same three. Above them all, the AI Overview cites a vendor page stating that Core Web Vitals are "a direct ranking factor". Anyone who reads one of these pages and then goes looking for FID in Search Console will not find it, because it is no longer there.
How Google decides whether a page passes
Three mechanisms, all written in the documentation and almost always skipped in guides.
The first: the threshold applies to the 75th percentile of page loads, not the average, segmented between mobile and desktop. A page passes when three visits out of four fall within the good value, as the web.dev documentation explains.
The second: all three have to pass. The status of a group is that of its worst metric, according to the Search Console help page. Poor CLS and good INP make a poor group.
The third is the most misunderstood. The report does not work on individual URLs but on groups of similar pages, on the assumption that they share the same framework and therefore the same problems. The URL you see in the table is an example standing in for dozens or hundreds of pages. That is why the fix that moves the report is almost always in the template, not on the page you have open.
The window is 28 days. A change published today enters the data gradually and it takes about a month for the value to settle. The validation you start from the Search Console report also lasts 28 days, and a single remaining instance of the problem makes it fail.
Why PageSpeed Insights gives you two different numbers
At the top, if the page has enough traffic, you find the field data: collected from real users' Chrome browsers and aggregated in the Chrome User Experience Report. These are the numbers that end up in Search Console and the ones Google uses. Below is the 0 to 100 score, which comes from a Lighthouse simulation: a single load, with an empty cache, on a device and connection set up in the lab.
The two blocks can tell opposite stories, and that is not a flaw in the tools. A Lighthouse score of 95 on a page your visitors open on a five-year-old smartphone over 4G tells you nothing useful. It works the other way too: a mediocre score on a page that passes in the field data is not a problem to fix, and chasing it is the most common way to burn half a day of development. We have listed which fixes are really worth the time in our guide to page speed.
How many sites actually pass
The HTTP Archive Web Almanac 2025 measures the whole population of sites covered by CrUX, a few million origins.
| Metric | Sites with a good value on mobile | Sites with a good value on desktop |
|---|---|---|
| All three Core Web Vitals | 48% | 56% |
| LCP | 62% | 74% |
| INP | 77% | 97% |
| CLS | 81% | 72% |
In 2021 the share of sites with good Core Web Vitals was 32% on mobile and 41% on desktop, so the curve is rising. But the bottleneck has moved. Interactivity on desktop is now a solved problem, with 97% passing. On mobile the brake is LCP: almost four sites in ten do not make it. And CLS is the only metric where mobile does better than desktop, 81% against 72%, probably because a wide screen has more columns, more banners and more things that move.
One number undoes a common assumption: big sites do not do better. Among the top thousand sites on the web 51% pass on mobile, among the top hundred thousand it drops to 37%, below the overall average. More traffic means more third-party scripts, more consent management, more advertising.
Since December 2025 LCP and INP can be measured outside Chrome too
With the release of Safari 26.2 on 12 December 2025, LCP and INP became Baseline Newly available: the current version of every major browser exposes the APIs needed to measure them. It was one of the goals of Interop 2025. CLS is still implemented only in Chromium-based browsers and has been proposed for Interop 2026.
| Metric | Chrome and Edge | Safari 26.2 and later | Firefox | Ends up in CrUX |
|---|---|---|---|---|
| LCP | Yes | Yes | Yes | Only from Chrome |
| INP | Yes | Yes | Yes | Only from Chrome |
| CLS | Yes | No | No | Only from Chrome |
On Google's side little changes: CrUX still collects only from eligible Chrome users, so Search Console and PageSpeed Insights will not see any extra data. A lot changes if you measure for yourself with a real user monitoring tool. On iOS every browser, Chrome included, runs on the WebKit engine and stays out of CrUX.
How much they count for rankings
Google says it "highly recommends" good Core Web Vitals and writes that this aligns with what its core ranking systems seek to reward. It goes no further, and it has never published a weight. Anyone promising a position in exchange for an LCP under 2.5 seconds is selling something else: speed is one of the ranking factors, not the first.
In practice Core Web Vitals act as a tie-breaker when relevance is equal. They count when two pages answer the same question comparably well and one of them responds badly to a tap. A very fast page with weak content does not beat a slow page that answers the query better, and no amount of technical SEO makes up for content that is off the point. When we run an SEO consulting project, performance comes after structure and content, except where the site is so slow that it loses users before it loses positions.
One point the industry rarely discusses. The public data everyone relies on is blind on iOS, where Chrome and Firefox also run. If a large share of your visits comes from iPhones, the Search Console report describes part of your audience and says nothing about the rest. Since December 2025 that gap can be covered with real user monitoring based on the web-vitals library, which now returns LCP and INP from Safari too. It is worth doing before someone offers to fix an LCP that nobody has ever measured on the right traffic.
Core Web Vitals FAQs
There are three: LCP (Largest Contentful Paint), INP (Interaction to Next Paint) and CLS (Cumulative Layout Shift). First Input Delay is no longer one of them: INP replaced it on 12 March 2024, and support for FID in Chrome tools ended on 9 September 2024.
No. The 0 to 100 score comes from a Lighthouse simulation of a single load. The Core Web Vitals verdict comes from the field data in the Chrome User Experience Report, collected from real visitors. The two values can differ a lot without either of them being wrong.
The measurement window is 28 days, so a change enters the data gradually and it takes about a month for the value to settle. Validation started from Search Console also lasts 28 days.
According to the HTTP Archive Web Almanac 2025, 48% of sites pass on mobile and 56% on desktop. The metric that holds back most sites on mobile is LCP, with 62% good values.
Since Safari 26.2, released on 12 December 2025, LCP and INP can be measured on all major browsers. CLS is still available only in Chromium-based browsers. CrUX data, however, still comes only from Chrome.