Core Web Vitals Report in Search Console Explained
The Core Web Vitals report is the one Search Console report that measures what real people experienced on your client's site, not what a test tool guessed in a lab. It pulls anonymised timings from actual Chrome visits and grades every URL it has enough data for as Good, Needs improvement or Poor.
It is useful and confusing in equal measure. Fix a page today and the report may not move for a month, half your client's URLs may not appear at all, and the metric everyone learned in 2020 has since been replaced.
This guide covers what the report measures, the LCP, INP and CLS thresholds, why URLs go missing, what happened to the page experience report, and how to explain all of it to a client who just wants to know whether their site is fast enough. If you also report on clicks and impressions, our breakdown of Search Console metrics explained for clients is the companion piece.
Last updated: September 2026
Key takeaways
- The Core Web Vitals report grades URLs on three metrics: Largest Contentful Paint (LCP), Interaction to Next Paint (INP) and Cumulative Layout Shift (CLS).
- A URL is rated Good when 75% of visits hit LCP of 2.5 seconds or less, INP of 200 milliseconds or less, and CLS of 0.1 or less. The worst of the three metrics decides the URL's status.
- The data is field data from the Chrome User Experience Report, aggregated over a rolling 28-day window, so fixes take weeks to show up.
- INP replaced First Input Delay as a Core Web Vital in March 2024, so any client report or template still showing FID is out of date.
- URLs with too few Chrome visits are excluded from the report entirely, which is why small client sites often show almost no data.
In this guide
- What is the Core Web Vitals report in Search Console?
- INP, LCP and CLS explained in plain English
- What are the Core Web Vitals thresholds?
- Why do most of your client's URLs not appear in the report?
- What happened to the page experience report?
- How do you fix a Poor or Needs improvement status?
- How to present Core Web Vitals for clients
- Frequently asked questions
The three metrics at a glance
| Metric | What it measures | Good | Needs improvement | Poor |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | How long until the biggest visible element finishes loading | 2.5s or less | 2.5s to 4.0s | Over 4.0s |
| INP (Interaction to Next Paint) | How long the page takes to visibly respond after a tap or click | 200ms or less | 200ms to 500ms | Over 500ms |
| CLS (Cumulative Layout Shift) | How much the layout jumps around while loading | 0.1 or less | 0.1 to 0.25 | Over 0.25 |
Thresholds are published by Google in its Core Web Vitals documentation on web.dev and mirrored in Search Console Help. Each is assessed at the 75th percentile of page visits, split separately for mobile and desktop.
What is the Core Web Vitals report in Search Console?
The Core Web Vitals report is a Search Console report that groups your indexed URLs by the loading, responsiveness and visual stability their real visitors experienced, and labels each group Good, Needs improvement or Poor.
Two details change how you read it. The data is field data from the Chrome User Experience Report (CrUX), which collects anonymised performance measurements from opted-in Chrome users on public URLs, so it is not a synthetic test run on a spare server. And it is aggregated over a rolling 28-day window, so what you see today is a month of history averaged together.
The mobile and desktop tabs routinely disagree. A site can sit comfortably in Good on desktop and fail on mobile, because mid-range phones on mobile networks do far more work to render the same page. When a client asks "is our site fast", the honest answer is usually "on desktop, yes; on the phones most of your traffic uses, not quite".
We built ReportsMate after years around agency reporting, and the pattern we kept seeing was that performance data lives in a tool nobody outside the agency logs into. Across the client accounts on ReportsMate today, Search Console is connected on only about one in four, while Google Analytics 4 sits on roughly two in three. Search visibility is already the least-connected side of the report; page experience sits a level deeper again.
INP, LCP and CLS explained in plain English
Each Core Web Vital answers a different question a visitor asks without realising it.
LCP answers "has this page loaded yet?" It marks the moment the largest image, video poster or block of text inside the viewport finishes rendering. On most client sites that element is the hero image or headline block. Slow LCP is usually a slow server response, an oversized hero image, or render-blocking CSS and fonts.
INP answers "did that button do anything?" It measures the delay between a tap or click and the browser painting the next frame, reporting close to the worst interaction across the visit rather than the first one. Slow INP is nearly always JavaScript blocking the main thread: tag managers, chat widgets, consent banners and heavy third-party scripts.
CLS answers "why did the page move while I was reading?" It scores unexpected layout shifts, the ones that push a button down as you go to press it. The usual culprits are images without width and height attributes, injected banners and late-loading web fonts.
INP replaced First Input Delay as an official Core Web Vital in March 2024. FID only measured the delay before the browser started processing the very first interaction, which flattered almost every site. INP is a harder test, and plenty of sites that passed under FID do not pass now. If a client report template still lists FID, it is measuring a metric Google retired.
What are the Core Web Vitals thresholds?
A URL is rated Good when at least 75% of visits in the 28-day window meet the Good threshold for all three metrics: LCP of 2.5 seconds or less, INP of 200 milliseconds or less, and CLS of 0.1 or less.
The 75th percentile is the part agencies most often get wrong in front of clients. Google does not use an average. It looks at the slowest quarter of your visitors and asks whether even they had a reasonable time, which is why a site with a fast median can still fail.
The other rule worth memorising: the worst metric wins. A URL group scoring Good on LCP and CLS but Poor on INP is a Poor URL group. No averaging, no partial credit.
Why do most of your client's URLs not appear in the report?
URLs are missing from the Core Web Vitals report when they have too few real Chrome visits for Google to report an anonymised measurement.
This catches almost every small business site. CrUX only covers public, indexed URLs visited by opted-in Chrome users, and needs a meaningful sample before a URL is eligible. Low-traffic service pages, new blog posts and anything behind a login do not exist as far as the report is concerned.
Search Console handles this by bundling URLs into groups of similar pages that share a status. A single slow template can drag down a whole group, and a fix to one URL may move the entire group at once. The example URLs listed are representative, not exhaustive.
Pages behind a login, noindexed pages and staging URLs are excluded too. If the report shows nothing at all, the site is below the traffic floor rather than perfect, and missing data is neither a pass nor a fail: it means unmeasured. Reach for lab data instead: PageSpeed Insights runs a Lighthouse test on demand for any URL, regardless of traffic. It tells you what to fix; only field data tells you whether the fix reached real users.
What happened to the page experience report?
Search Console's page experience section is now an overview that links to the Core Web Vitals and HTTPS reports rather than a standalone graded report.
Google has trimmed this area steadily: the mobile usability report was retired in December 2023, and the page experience report was reworked into a summary surface. Google Search Central has also been clear for years that there is no single "page experience" ranking signal to chase. Page experience is a set of signals, Core Web Vitals is the measurable part, and content relevance still does the heavy lifting.
For agency reporting the consequence is simple. Report Core Web Vitals, HTTPS coverage and indexing health as separate, concrete items, and do not promise a client a page experience score, because there is no longer a number to point at. Indexing is the one most often skipped, and our guide to the Search Console page indexing report covers what to check there.
How do you fix a Poor or Needs improvement status?
Fix the metric that is failing, then use the report's Validate Fix button and expect to wait.
Work through it in this order:
- Open the failing group and read the issue label, for example "CLS issue: more than 0.25 (mobile)". It names both the metric and the device.
- Run the example URLs through PageSpeed Insights for the lab diagnostics behind the failure. Field data tells you what is broken; lab data tells you which resource is breaking it.
- Fix the usual suspects. For LCP: compress and correctly size the hero image, preload it, cut render-blocking CSS. For INP: defer or remove third-party scripts and break up long JavaScript tasks. For CLS: set explicit width and height on images and embeds, and reserve space for anything injected after load.
- Click Validate Fix. Search Console re-checks the group over a 28-day window, and validation commonly takes weeks because it is waiting on real visits, not a crawl.
- Set the timeline with the client first. A fix shipped in week one will not show as Good in week two, and an agency that has not said so upfront looks slow when it was actually fast.
That lag is the biggest source of avoidable friction in performance reporting: a rolling 28-day window means the report is always describing a month that includes the problem you already fixed.
How to present Core Web Vitals for clients
Report Core Web Vitals as three plain-English questions with a pass or fail against each, not as three acronyms with decimal places. The translation that works in practice:
| What the report says | What to write in the client report |
|---|---|
| LCP 4.1s, Poor, mobile | Pages take too long to show their main content on mobile |
| INP 480ms, Needs improvement | Buttons and menus feel sluggish when tapped |
| CLS 0.28, Poor | The layout jumps while pages load, which causes mis-taps |
| No data available | Not enough Chrome traffic yet for Google to grade these pages |
Two habits make this land. Pair every status with the business consequence rather than the metric definition, and sit it next to a behavioural metric the client already recognises, such as the engagement and bounce figures covered in our GA4 engagement rate versus bounce rate guide. "Mobile pages are slow and mobile bounce is well behind desktop" is a sentence a client acts on. "LCP is 4.1s" is one they forward to someone else.
Define the jargon once, in the report itself. Field data means measurements from real visits. Lab data means a simulated test. The 75th percentile means your slowest quarter of visitors. Three sentences, and the client reads the next eleven reports without asking.
Then get the report in front of them. Across roughly 2,900 tracked report emails sent through ReportsMate, about three in ten were opened, the median open landed inside six hours of delivery, and around three in four opens happened within a day. A dashboard login gets none of that, because the client has to remember it exists. That is the argument for email-first delivery, and the mechanics are on our how it works page.
Frequently asked questions
Q: How often does the Core Web Vitals report update?
A: The report updates roughly daily, but each update reflects a rolling 28-day window of Chrome User Experience Report data. That means a genuine improvement shows up gradually as slow days age out of the window rather than appearing overnight. Expect a meaningful shift three to four weeks after a fix ships, and a completed Validate Fix pass on a similar timeline. Quote a client a month, not a week, and do not bother comparing this week's report to last week's.
Q: Is the Core Web Vitals report a ranking factor?
A: Core Web Vitals are part of Google's page experience signals, which are one input among many, not a switch that lifts rankings on their own. Google Search Central has consistently framed it as a tiebreaker between pages of comparable relevance rather than a substitute for useful content. The honest positioning for a client is that fixing Core Web Vitals removes a handicap and improves conversion on mobile, but it will not rank a thin page against a better one.
Q: Why does PageSpeed Insights show a different score to Search Console?
A: They measure different things. PageSpeed Insights returns a Lighthouse lab score from a single simulated load on a throttled connection, while the Core Web Vitals report shows field data from real Chrome visits over 28 days. A page can score 95 in the lab and still fail in the field if real visitors are on slower devices. Use lab data to diagnose and field data to judge. PageSpeed Insights shows both: the CrUX field panel at the top is the same source Search Console uses.
Q: What replaced First Input Delay?
A: Interaction to Next Paint (INP) replaced First Input Delay (FID) as an official Core Web Vital in March 2024. FID measured only the browser's delay before it began processing the first interaction on a page, which most sites passed easily. INP measures the full time from an interaction to the next visual update, close to the worst interaction across the visit, so it exposes sluggish menus, filters and forms that FID never caught. If a client's template or a legacy dashboard still lists FID, it is showing a retired metric.
Q: Can I pull Core Web Vitals through the Search Console API?
A: Not from the Search Analytics API. That endpoint returns search performance data: clicks, impressions, CTR, average position, and breakdowns by query, page, device and country. Core Web Vitals field data comes from the CrUX API or the PageSpeed Insights API, both reading the same Chrome User Experience Report dataset behind the Search Console report. Any reporting tool showing search performance and page speed side by side is combining at least two APIs, which is worth knowing before a client asks you to explain a discrepancy.
Q: How do I put Core Web Vitals in a recurring client report?
A: Keep it to one block: a Good, Needs improvement or Poor status for mobile and desktop, the count of URLs in each state, the metric currently failing, and one sentence on what is being done about it. Trend the URL counts month over month rather than raw metric values, which swing with traffic mix. Our guide to automated Search Console reporting for agencies covers how to stop rebuilding the surrounding search section by hand every month.
Getting this into the client report
The Core Web Vitals report is worth reading properly because it is the only place Google tells you what real visitors experienced on your client's site. It is also slow, patchy on small sites and written in acronyms. Read it as three questions, report the mobile tab first, translate every status into a consequence, and warn the client about the 28-day lag before you ship the fix rather than after.
The other half of the job is delivery. Performance data sitting in a dashboard the client never opens has no effect on retention, and reporting cadence is what most agencies get judged on when a retainer comes up for renewal. Automate the search and analytics side, add a short Core Web Vitals block, and send it. Plans and client limits are listed on our pricing page.
Stop losing your Sundays to client reports. Start your free 14-day trial - no credit card, no setup, cancel anytime. Your clients get branded reports in their inbox automatically.