Reference guide · search-console · Published 2026-08-16 · 4 min read
Using the Search Console Core Web Vitals report
Search Console Core Web Vitals report: what the good / not-good grouping means, CrUX field data, and how to prioritise fixes.
- ·The good and bad grouping
- ·Reading the numbers
- ·Act on the report
What the report is and is not
The Core Web Vitals report in Search Console summarises field data, the real-user measurements Google collects through the Chrome User Experience Report (CrUX), grouped per URL. It answers one question: "does this page deliver a good LCP, INP and CLS for the visitors Google sees?" It does not debug your own machine from dev tools, and it does not replace the lab audit you run in Lighthouse.
It is a page-level status board:
- Good: the page meets the good threshold for all three metrics in the field.
- Not good: at least one metric falls in the poor threshold.
- Needs improvement: at least one metric is in between good and poor.
Only pages with enough eligible visits to compute a stable distribution appear. A new page with little traffic shows "Insufficient data", which the report also tells you.
The three metrics and their thresholds
The report groups by the Core Web Vitals that have an official threshold:
| Metric | Good | Poor |
|---|---|---|
| LCP: largest contentful paint | <= 2.5 s | > 4.0 s |
| INP: interaction to next paint | <= 200 ms | > 500 ms |
| CLS: cumulative layout shift | <= 0.1 | > 0.25 |
Everything between the good and poor cutoffs is "needs improvement". Field data is noisy, so Search Console reports the 75th percentile of the distribution per page, which is why a page can flip status across the month as real visitors succeed or hit a slow-CPU moment.
How to read the report
Open Performance > Core Web Vitals (the page experience category):
- The overview page lists URLs by status, with a breadcrumb of the metric that pushed each page down.
- Click into a group to see the page list and which metric is the offender, with the good/needs/poor breakdown for that metric.
- A URL can appear in more than one group because each metric is judged independently.
The report is the third-party source of truth for "is our optimisation working", layered on the lab audit and the performance report that shows the clicks side.
Turn findings into fixes
The status alone tells you the page needs work, not why. Map each failing metric to its usual cause:
- LCP poor: the hero image or its resource is slow, or the server response is slow (TTFB). Fix the LCP optimisation targets: preload the hero, serve it responsive, and check the TTFB and render chain.
- INP poor: the page has long main-thread tasks from JavaScript. Reduce the JS bundle and defer, and revisit INP optimisation.
- CLS poor: layout shifts from missing dimensions or late inserts. Apply the CLS fixes (dimension attributes, aspect-ratio CSS, font swapping).
Then, the loop is a score of the field data: search the report, pick the page group with the most sessions, fix the shared cause, re-run the audit, and wait a month for the field sample to catch up before assuming the change did not work.
The traps
- Registering the wrong stream: a page with a separate AMP or app version has its own URL; fix the URL the report is about.
- Following field data for lab decisions: the report is a monthly sample, not a profiler. Do the lab work first, use the field to confirm.
- Chasing zero: a "Not Good" page with one bad median, five sites of good medians, is still your whole fix backlog. Work the pages where the poor bucket is materially large, not the smallest.
Where it fits
The Core Web Vitals report is the scoreboard of the performance family of articles. Pair it with the Search Console setup for verification, the URL inspection to re-request when you think you fixed a page, and the LCP, INP, CLS audit for the manual steps the report cannot give you.