Where to find it
In Search Console, open Experience > Core Web Vitals. The overview shows two charts: Mobile and Desktop. Click Open report next to Mobile first. Most sites get most of their Google traffic on phones, and mobile pages are usually slower.
The three metrics and their thresholds
| Metric | What it measures | Good | Poor |
|---|---|---|---|
| LCP (Largest Contentful Paint) | How fast the main content shows | 2.5 s or less | over 4 s |
| INP (Interaction to Next Paint) | How fast the page responds to taps, clicks and typing | 200 ms or less | over 500 ms |
| CLS (Cumulative Layout Shift) | How much the layout jumps while loading | 0.1 or less | over 0.25 |
Between Good and Poor is Need improvement. Each number is the 75th percentile: 3 out of 4 visits must be at or under the Good line (web.dev).
FID is gone. INP replaced First Input Delay as a Core Web Vital on March 12, 2024 (web.dev). If a guide or plugin still talks about FID, it is out of date.
How the report works
- Field data, not a lab test. The report uses real visits from Chrome users (the CrUX data set), over the last 28 days. A fast PageSpeed Insights lab score does not change it.
- URL groups. Google groups pages that look alike, such as all product pages built on the same template. Each example URL in the table stands for a group. Fix the template and the whole group moves.
- Worst metric wins. A group's status is its worst metric. Good LCP and Poor CLS means Poor.
- Only indexed URLs, and only a sample. The report is not a list of every page on your site.
- Chart total vs table total. The chart counts each URL once, at its worst status. The table counts a URL once per issue. So the table total can be higher. That is not a bug (Google).
- Not enough data. Small sites often see "not enough usage data". That is not a penalty. Use PageSpeed Insights or Lighthouse to test key pages instead.
What to fix first
Google's own advice: fix everything marked Poor first, then Need improvement. Within a status, start with the issue that hits the most URLs or your most important URLs. Inside a group, URLs are sorted by impressions, so the top ones matter most (Google).
Common causes and fixes:
| Issue in the report | Usual cause | Fix |
|---|---|---|
| LCP issue: longer than 2.5s | Large hero image or video, slow server, render-blocking CSS or fonts | Resize and compress the hero image, do not lazy-load it, preload it, add caching or a CDN |
| INP issue: longer than 200ms | Heavy JavaScript: page builders, chat widgets, tag managers, sliders | Remove unused scripts, load third-party tags later, split long tasks |
| CLS issue: more than 0.1 | Images or ads without set sizes, late banners, web fonts swapping | Set width and height on images and embeds, reserve space for ads and banners |
Worked example (fictional site). northwind-outdoors.com opened Experience > Core Web Vitals > Mobile and saw "LCP issue: longer than 2.5s (mobile)" on 1,840 URLs. Every example URL was a product page. The group LCP was 4.1 s. The cause: the product template loaded a 2,400 px wide photo, lazy-loaded, as the first image. The team served a 900 px version on phones, turned off lazy loading for the first image and preloaded it. A PageSpeed Insights lab test on three product pages showed LCP under 2 s. They then clicked Start Tracking. Because the report uses 28 days of real-user data, the group moved to Good near the end of the 28-day window, not the next day.
How validation works (Start Tracking)
When you think an issue is fixed on all its URLs, open the issue and click Start Tracking. Search Console then watches 28 days of real-user data. If no URL on the site shows that issue during the 28 days, it is marked fixed. If any URL still has it, validation fails, and you can click Start new validation after more work. Start Tracking does not make Google recrawl or reindex anything. It only starts the clock (Google).
"My status changed but I changed nothing"
Groups near the line can flip from small changes: a traffic spike, a slower image server, a new ad or chat script added by someone else. Check what changed on those dates, and add an annotation to your Performance chart (right-click > Add annotation) so you remember next time.
How much do Core Web Vitals matter for rankings?
They are part of Google's page experience signals, but relevance and content quality matter more. A Poor status will not sink a great page, and a Good status will not lift a weak one. Fix Poor groups because slow pages lose visitors and sales, and because it is often a small template fix.
How to use this with an AI assistant
Connect SEOmatic at https://seomatic.ai/mcp and ask: "Run site_audit on mysite.com and list the slow pages, then run site_pages analyze on my top 3 product or service pages and tell me what slows them down." SEOmatic does not read the Core Web Vitals report itself, so open Experience > Core Web Vitals for the field data.