Core Web Vitals in Google Search Console: what the report shows, the thresholds and how to fix

The Core Web Vitals report grades groups of URLs on three real-user metrics, LCP, INP and CLS, separately for mobile and desktop. A group takes the status of its worst metric, and the report needs enough field data to show you anything. The working routine is short: find the device and the failing metric, fix it with the matching web.dev guide, and click Start tracking. Google describes the report in its help page.

What the report reads, and the thresholds

The data comes from the Chrome UX Report: field data from real users, not a lab test. URLs are grouped; a group without enough data is replaced by a wider origin group, and with too little data nothing is shown. Mobile and desktop are labelled separately.

The status ranges are these. Good means LCP at most 2.5 seconds, INP at most 200 milliseconds and CLS at most 0.1. Need improvement means LCP up to 4 seconds, INP up to 500 milliseconds and CLS up to 0.25. Poor is anything above those values. A group’s status is that of its most poorly performing metric, so open the issue details to see which of LCP, INP or CLS fails and which URL groups are affected.

Fixing the failing metric

Start with the metric the report marks as failing for the largest group of URLs, since the status follows the worst one. For LCP, work through the four parts of load time described in the web.dev guide to LCP. For INP, shorten input delay, event processing and presentation delay (optimize INP). For CLS, reserve space for images, embeds, ads and fonts so that nothing jumps when it loads (optimize CLS).

Start tracking, and what the 28 days mean

When a fix is ready, click Start tracking. That opens a 28-day monitoring session, and the issue counts as fixed only if it appears on no URL during those 28 days. So do not start before every instance is fixed: any URL that still has the issue marks the whole issue as not fixed. Start tracking only monitors; it does not trigger re-indexing and does not ask Google to recrawl.

Because the report uses field data, a fix shows up only after enough real visits have been recorded, and a quick lab test is not the same as the report’s verdict. Fix first, then track, and read the status after the monitoring session, not before.

When the report is empty or a URL is missing

“No data available” means either that the property is new or that the Chrome UX Report has too little data for that device; it can take a few days after you create a property for existing data to appear. A single URL may be missing because a group needs data for both LCP and CLS and a minimum amount of it, for privacy, and otherwise it is omitted. The report is built for the site as a whole, not for finding one URL’s status.

Is it a ranking factor?

Google says that good Core Web Vitals align with what its core ranking systems seek to reward (Core Web Vitals and Google Search). Its page does not say how much weight they carry or how fast a change would show, so treat the 28-day window as the time Google monitors for the issue, not as a promise of a ranking change.

Watching it in SEOKit

The workspace has a Core Web Vitals history report built on the same Chrome UX Report data and an alert type for regressions and recoveries, so you do not have to open Search Console to learn that a group slipped. For the other Search Console reports of this kind, see experience and technical reports.

Go further

Docs: alerts and webhooks: Set up a Core Web Vitals alert. FAQ: Page indexing statuses: The other big technical report.