Core Web Vitals report in Search Console: LCP, INP and CLS

The Core Web Vitals report in Google Search Console shows how your pages perform for real Chrome users, split into mobile and desktop and rated Good, Need improvement or Poor. A page group is Good when its Largest Contentful Paint is 2.5 seconds or less, its Interaction to Next Paint is 200 milliseconds or less and its Cumulative Layout Shift is 0.1 or less, each measured at the 75th percentile of visits over the last 28 days. The numbers come from the Chrome User Experience Report (CrUX), not from a lab test, which is why smaller sites often see no data at all.

What do LCP, INP and CLS measure?

Three metrics, one for each kind of frustration a visitor feels.

Largest Contentful Paint (LCP) measures loading: how long until the largest image, video or text block in the viewport has rendered. On most pages that is a hero image or the headline block.

Interaction to Next Paint (INP) measures responsiveness: how long the page takes to visibly respond after a click, a tap or a key press. It observes interactions throughout the visit, and the value reported is the longest one, ignoring outliers.

Cumulative Layout Shift (CLS) measures visual stability: how much content jumps around unexpectedly, such as the button that moves just as you go to tap it.

INP replaced First Input Delay (FID) as a Core Web Vital on 12 March 2024, and FID was removed from Search Console the same day. FID measured the input delay of the first interaction alone; INP covers every click, tap and key press. Any checklist that still mentions FID is out of date.

What are the thresholds?

Metric	Measures	Good	Need improvement	Poor
LCP	Loading	2.5 s or less	Over 2.5 s, up to 4 s	Over 4 s
INP	Responsiveness	200 ms or less	Over 200 ms, up to 500 ms	Over 500 ms
CLS	Visual stability	0.1 or less	Over 0.1, up to 0.25	Over 0.25

Every value is the 75th percentile. For LCP, that is the time by which 75 percent of visits to the URLs in a group had reached the LCP moment. Using the 75th percentile rather than the median means a page has to be fast for most of its visitors, not just for the typical one on good Wi-Fi.

Where does the data come from?

From CrUX, Google’s dataset of anonymised performance timings from real Chrome users. Not every visit is in it. Chrome’s documentation excludes Chrome on iOS, Android apps that use WebView, and other Chromium browsers such as Microsoft Edge, and counts users who have usage statistics reporting and history sync turned on. A page also has to be publicly discoverable: one that returns a status other than 200 or carries a noindex is left out.

In Search Console, the group metrics cover the last 28 days, the report includes indexed URLs alone (a page that is not indexed will never appear in it), and the example URLs are a sample rather than a full list. That last point catches people out. If a page you care about is missing from the examples, it can still be in a group.

How do URL groups work?

Search Console groups URLs that it judges to provide a similar experience, typically pages built on the same template, and reports one status for the whole group. The group’s status is its slowest metric for that device type: a group with good LCP and INP but a CLS of 0.3 is Poor. That is useful rather than a nuisance: fixing the template usually moves the whole group.

When a URL group has too little data, Search Console falls back to an origin group, which covers every URL under one protocol, host and port. The http and https versions of a site are separate origins.

Why does the report say there is not enough data?

Because CrUX did not record enough visits. Chrome publishes data for a page, and separately for an origin, once it passes a minimum number of visitors, and the exact threshold is not disclosed. Low-traffic sites, sites whose audience mostly uses iPhones, and pages behind a noindex all run into it. A newly added property may show “No data available” for a few days while existing CrUX data is processed, and a URL group without data for both LCP and CLS is left out of the report entirely.

Nothing you change in Search Console fixes this; more traffic does. In the meantime, PageSpeed Insights will run a Lighthouse lab test on any URL, and it falls back to origin-level field data when a single URL has too little.

How to fix an issue and validate it

1. Open Experience → Core Web Vitals and choose Open report next to the mobile or the desktop chart. Start with whichever has more Poor URLs.
2. Pick the issue affecting the most URLs and open its example URLs.
3. Run two or three of those URLs through PageSpeed Insights. The lab data from Lighthouse is what you debug with; the field data tells you whether real visitors agree.
4. Fix the template rather than the page, then deploy.
5. Go back to the issue in Search Console and click Start tracking (Validate fix in some of Google’s documentation). This begins a 28-day monitoring session. If the issue is not present on any URL during that window, it counts as fixed.
6. Wait. Validation does not trigger a recrawl or anything else on Google’s side, and because the data is a rolling 28 days, the chart moves gradually rather than overnight.

Validation moves through Not started, Started, Looking good and then Passed or Failed. If it fails, fix what is left and choose Start new validation.

How much do Core Web Vitals matter for rankings?

Google says Core Web Vitals are used by its ranking systems and recommends achieving good scores. Its page experience documentation is just as clear about the limits: good scores do not guarantee top rankings, Google Search will still show the most relevant content even when its page experience is sub-par, and chasing a perfect score purely for SEO reasons is probably not worth the time. Google’s core ranking systems generally evaluate page experience page by page, not site-wide.

The practical reading is to move Poor groups to Good on the templates that carry your traffic. Shaving 50 milliseconds off a group that is already Good is unlikely to change where you rank. If you want a cadence, a glance at the Poor count once a week is enough; our ten-minute weekly check-in slots it in at minute seven.

Where QueryWatch fits

The Search Console API does not expose the Core Web Vitals report, so no third-party app can show you Search Console’s URL groups or start a validation. Those stay in the web interface, and Google’s Core Web Vitals report help covers every status in detail.

What QueryWatch Pro adds is Core Web Vitals per page: LCP, INP and CLS for a single URL, checked from your phone, which is the view the grouped report deliberately does not give you. Per-page field data still depends on Chrome having recorded enough visits to that page, so a quiet page will have less to show in any tool, ours included. Because the Search Console report includes indexed URLs alone, it is also worth confirming a page is indexed; the free tier covers five URL inspections a day, and URL inspection explained shows what to read in the result.

Every property is on the free tier, and the product page lists what Pro adds. QueryWatch is an independent app and is not affiliated with Google.