The Core Web Vitals report
Core Web Vitals are three measures of how a page feels to real visitors: Largest Contentful Paint for loading, Interaction to Next Paint for responsiveness, and Cumulative Layout Shift for visual stability. A page gives a good experience when LCP is 2.5 seconds or less, INP is 200 milliseconds or less, and CLS is 0.1 or less, measured at the 75th percentile of page loads.
Search Console’s Core Web Vitals report uses those thresholds to label groups of your pages Good, Need improvement or Poor. This stop sets out the thresholds, what each metric actually times, and how to read the report.
General information, not business advice. This page explains Google’s published documentation in plain words. Google’s tools change: check Search Console Help, Google Search Central and web.dev for the current version, and ask a qualified professional about your own site.
04.1
The departure board: three metrics, three bands
| Metric | Measures | Good | Need improvement | Poor |
|---|---|---|---|---|
| LCP | Loading | ≤ 2.5 s | ≤ 4 s | > 4 s |
| INP | Responsiveness | ≤ 200 ms | ≤ 500 ms | > 500 ms |
| CLS | Visual stability | ≤ 0.1 | ≤ 0.25 | > 0.25 |
Ranges as published in Search Console Help, checked 7 October 2026. web.dev gives the same “good” mark for all three, and the same “poor” boundary for INP and CLS.
04.2
What each one times
Largest Contentful Paint (LCP)
LCP reports the render time of the largest image, text block or video visible in the viewport, relative to when the user first navigated to the page. It counts from the visitor’s side, so it includes things that happen before your page even arrives, such as redirect time and connection setup, which is one reason field and lab figures differ. In plain terms: how long until the main thing on the screen is there.
Interaction to Next Paint (INP)
INP watches every click, tap and keyboard interaction during a visit and measures how long each takes until the browser can next paint the screen. The final value is the longest interaction observed, ignoring outliers; on pages with many interactions, one highest interaction is ignored for every 50. web.dev calls INP the successor to First Input Delay, which measured only the first interaction. In plain terms: when someone presses something, how long until the page visibly responds.
Cumulative Layout Shift (CLS)
CLS measures the largest burst of unexpected layout shifts during a page’s life. A burst, or session window, is one or more shifts less than a second apart, lasting at most 5 seconds in total. In Search Console’s words, zero means no shifting. In plain terms: how much the page jumps about while someone is trying to read or tap it.
04.3
How the report reads your site
- Real visitors, not a test. The data comes from the Chrome User Experience Report (CrUX), which gathers anonymised performance timings from actual users, known as field data.
- The 75th percentile, over 28 days. A group’s LCP is the time that 75% of page requests met or beat in the last 28 days; INP and CLS are read the same way. That matches web.dev’s advice to measure at the 75th percentile, split by mobile and desktop.
- Groups, not single pages. URLs with a similar experience are grouped, and the status applies to the whole group. The report isn’t designed to look up one URL; for that, Google points to an external test such as PageSpeed Insights.
- The worst metric decides. A group’s status is its poorest metric for that device. Poor CLS with good INP makes the group Poor.
- Mobile and desktop are separate. A group can be Good on mobile and Need improvement on desktop.
- Not every page appears. Only indexed URLs can appear, and a group needs a minimum amount of data for both LCP and CLS. Where a group lacks data, Search Console may roll it up into an origin group for the whole host.
04.4
A worked example
Take an invented group of product pages on mobile. Its figures are made up; the rules applied to them are Google’s.
| Metric | Group value | Band |
|---|---|---|
| LCP | 3.1 s | Need improvement (over 2.5 s, not over 4 s) |
| INP | 180 ms | Good (200 ms or less) |
| CLS | 0.05 | Good (0.1 or less) |
Two metrics are Good, but the group’s status is its worst metric, so on mobile the whole group is labelled Need improvement. Read in plain terms: on three visits in four, the main content of these pages appeared within 3.1 seconds, which is slower than Google’s 2.5-second mark. The fix to look at is loading, not responsiveness or layout.
04.5
Working through the report
- First
Fix everything labelled Poor, then work by the issues affecting the most URLs or your most important ones. Need improvement matters, but less.
- Then
Run an external test for recommended fixes, make the changes, and test again.
- Finally
Choose Start Tracking on the issue’s details page, and follow the validation.
If a lot of pages change status when nothing on your site changed, Google’s explanation is that many pages may have been borderline, and a small site-wide event, such as a jump in traffic or a slower image server, tipped them over.
On search itself, Google highly recommends achieving good Core Web Vitals for success with Search and for a good experience generally, and says this, along with other page experience aspects, aligns with what its core ranking systems seek to reward. That page doesn’t say how much weight the vitals carry.