Core Web Vitals Report (Google Search Console)

TL;DR — The Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. report in Google Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. shows how your pages perform for real visitors on Google’s three speed-and-stability metrics (LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good., INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good., CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good.). It’s real-world data from Chrome users, grouped into buckets of similar pages, and split into Mobile and Desktop tabs. It’s a site-wide triage tool, not a page-by-page speed checker — and if you’re a small or new site, it might show no data at all.

What the Core Web Vitals report is

You’ll find it in Google Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. under the Experience section. Google’s own one-line description: the report “shows how your pages perform, based on real world usage data (sometimes called field dataPerformance metrics captured from real users, not lab tests.).”

The important thing to get straight up front: this is a report, not the metrics themselves. Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. — LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good., INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good., and CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good. — are three measurements of how your page feels to a real visitor (how fast the main content loads, how quickly the page responds to a tap, and how much things jump around while loading). Those metrics are defined in detail elsewhere on this site. This article is about the report — the tool in Search ConsoleGoogle's free tool for monitoring crawling, indexing, and search performance. that shows you those numbers and organizes them.

Where the data comes from

The report doesn’t run a speed test. It pulls field data from the Chrome User Experience Report (CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program.) — anonymized timings from actual Chrome users who visited your pages. That’s different from a lab test like PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking., which loads your page once in a controlled environment. Field data is what really happened to real people, averaged over the last 28 days.

How the report is organized

Three things to know about how it groups your URLs:

• Mobile and Desktop are separate tabs. A page can be “Good” on mobile and “Poor” on desktop at the same time. They’re never averaged together.
• Three status buckets: Poor, Need improvement, and Good. A URL’s status is set by its worst metric — one bad number drags the whole page down.
• URLs are grouped, not scored one by one. Google buckets together pages that are similar (usually the same page template), so you’ll often see one issue affecting a whole batch of URLs at once.

The thing most people get wrong

This report can’t reliably tell you if one specific page is slow. Google says it plainly — it’s “not designed [to] find the status of a specific URL, but rather to see your site’s performance as a whole.” It’s for spotting site-wide, template- level problems. To check one page, use PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking. or the URL InspectionA Google Search Console feature that reports how Google sees one specific URL on a property you own. By default it shows the last-indexed snapshot; a separate \"Test live URL\" mode fetches the current version. tool instead.

Two more things worth knowing early:

• “No data available” is common and usually not a problem with your pages. It means one of two things: your property is brand new in Search Console, or there isn’t enough Chrome traffic for the device you’re viewing (mobile or desktop) to clear Google’s reporting threshold.
• It’s about a month behind. Because it’s a 28-day average, a fix you ship today won’t fully show up here for weeks. Use PageSpeed Insights for faster feedback.

Want the full mechanics — how the URL grouping actually works, why it won’t match PageSpeed Insights, the validation workflow, and what happened to FID? Switch to the Advanced tab.

TL;DR — The Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. report surfaces CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. field dataPerformance metrics captured from real users, not lab tests. (28-day rolling, 75th percentile) for your indexedStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. URLs — it computes nothing new. It groups URLs by device (independent Mobile/Desktop tabs), status (Poor / Need improvement / Good, worst metric wins), and URL group (clusters of similar-templated pages sharing one status). Only indexed URLs appear, and it shows a sample, not every URL. When a URL group is too small to report on privately, Google falls back to a higher-level origin group — and if even that can’t clear the bar, you get “No data available.” It won’t match PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking. (group vs. single-URL; GSCA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. keeps URL parametersThe `?key=value` data tacked onto the end of a URL after a question mark — used for tracking, sessions, filtering, sorting, and search — and one of the biggest sources of duplicate URLs and wasted crawling in SEO. distinct, PSI strips them). It’s for site-wide triage, not single-URL lookups. FIDFirst Input Delay — a retired Core Web Vital that measured the delay before the browser could begin processing a page's first interaction. Good was ≤100 ms. Replaced by INP in March 2024. was removed on March 12, 2024 when INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. became a Core Web Vital — GSC dropped it immediately, unlike PSI/CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program.’s six-month grace period. Fix “Poor” first, validate with Start Tracking, and expect the field data to catch up over roughly a month.

It’s a report, not a redefinition of the metrics

The single most useful frame for this article: the Core Web Vitals reportThe Google Search Console report (under Experience) that shows how your indexed URLs perform on the Core Web Vitals — LCP, INP, and CLS — using real-user field data from CrUX, grouped by device, status, and clusters of similar-performing URLs. is a view into data that already exists, not a new measurement. Google is explicit that “the data for the Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. report comes from the CrUX report. The CrUX report gathers anonymized metrics about performance times from actual users visiting your URL (called field data). The CrUX database gathers information about URLs whether or not the URL is part of a Search ConsoleGoogle's free tool for monitoring crawling, indexing, and search performance. property.”

So the report has zero lab data — no LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. scores, no synthetic tests. It’s 100% field data: real Chrome users, 28-day rolling window, judged at the 75th percentile, split by device. The metric definitions, thresholds, and ranking-signal weight live in the Core Web VitalsWeb Vitals is Google's initiative (launched May 2020) for unified page-experience quality signals. Core Web Vitals — LCP, INP, and CLS — are the subset used in ranking; the rest (TTFB, FCP, TBT, Speed Index) are diagnostic, not ranking factors. glossary and the web-vitals topic — I won’t re-derive them here. This is about the tool.

Only indexed URLs, and only a sample

Three scoping rules people miss. First, and most fundamental: a URL group only appears once it clears a data threshold for both LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. and CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good. — if a group doesn’t have enough reporting data for both, it’s omitted from the report entirely, not marked as passing. Second: “Only indexed URLs can appear in this report. This report isn’t a comprehensive list of all indexed URLs. It shows a sample of pages to help you assess your site’s performance based on Core Web Vitals.” So don’t read it as an exhaustive audit. Third, a subtle one that trips up anyone used to other GSC reports: “Data is assigned to the actual URL, not the canonical URL, as it is in most other reports.” Most Search Console reporting rolls up to the canonical; this one doesn’t.

Mobile and Desktop are independent datasets

The report breaks everything down by device, and the two tabs are fully separate — never averaged. A URL group can be Good on mobile and Need improvement on desktop simultaneously, because they’re different CrUX datasets reflecting different devices, networks, and CPU classes. Always check both tabs; a “Good” summary on one can hide a “Poor” bucket on the other.

Status: worst metric wins

Each URL group lands in one of three buckets — Poor, Need improvement, or Good — and the group’s status is that of its worst-performing metric. A group with good LCP and good INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. but poor CLS is a “Poor” group. This “worst metric wins” rule is why a single unstable layout element can tank an otherwise-fast template.

The underlying thresholds (LCP ≤ 2.5s / INP ≤ 200ms / CLS ≤ 0.1 for “Good”, each at p75) are the metric definitions, covered in the Core Web Vitals glossary — and worth noting: as of my research, the live Search Central docs still list those original numbers. If you’ve seen a claim floating around that Google quietly lowered the “Good” LCP threshold to 2.0 seconds, or that some late-2025 core update made Core Web Vitals a much bigger ranking factor — I couldn’t verify either against any Google-owned source, and the docs contradict them. Treat those as rumor.

URL groups — the core mechanic

This is the report’s defining feature and the biggest mental-model shift for anyone coming from PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking.’ single-URL habit. Google: “URLs in the report are grouped into pages that have a similar user experience. The LCP, INP, and CLS status applies to the entire group. Some outlier URLs might have better or worse values on some visits, but 75% of visits to all URLs in the group experienced the group status shown.”

John Mueller described the machinery back in 2021: “We do that with the Chrome User Experience Report data, the field real-world data, essentially, where we try to recognize when there are pages that are similar enough that we could group them together.” And critically, the group’s data can stand in for a URL that has none of its own: “If we find a new URL that is also a part of this group, we don’t have to have data for that new URL. We can rely on the data for the group overall.”

That’s also why the report can look alarming for what’s really one bug. Mueller again: “We might have one group, essentially, for a site. But that could contain thousands of URLs. So, in the report in Search Console, I think we would report that as thousands of URLs have this problem.” One template flaw, thousands of URLs flagged.

Which is exactly why the grouping is useful rather than annoying. As I put it in Ahrefs’ Core Web Vitals guide, “This grouping of pages makes a lot of sense. This is because most of the changes to improve Core Web Vitals are done for a particular page template that impacts many pages.” And in the PageSpeed Insights guide: “The benefit of GSC is that it buckets similar URLs. For the bucketed pages, you will likely be working in one system or template.” Fix the template once, fix it for the whole group. Or, as I framed it in an interview with Outside Communications: “Basically, here are groups with issues that probably share the exact same theme. You fix it once, you fix that issue for all those pages.”

The privacy threshold and origin-group fallback

Grouping isn’t just a convenience — it’s a privacy requirement. Google: “In order to respect user privacy, a URL group must have a minimum amount of data to be shown in the report. If a URL group doesn’t have enough information to display in the report, Search Console creates a higher-level origin group that should contain enough URLs and data to show in the report.” So the cascade is: URL group → origin group → nothing. When even the origin can’t clear the bar, you get “No data available.” This is the mechanical reason low-traffic sites see broad, coarse groupings or no data at all.

Why a “Poor” group can still contain fast pages

Because the status applies to the whole group at the 75th percentile, an individual fast URL can get swept into a slow group. Being in a Poor group doesn’t prove that URL is slow — it means the cluster, taken together, has a problem. Don’t assume every member is guilty; the group is the unit of analysis.

Reading the report: chart vs. table

A genuinely confusing detail that most third-party guides skip. The landing chart and the issue table count differently: “The chart counts each URL only once, for the slowest issue affecting that URL. The table, in contrast, counts every issue associated with a URL.” So a URL with one Poor and one Need-improvement issue shows up once (as Poor) in the chart, but appears in both rows in the table. That’s why the totals don’t reconcile — it’s by design, not a bug. Clicking into an issue, as I describe it, “gives you a breakdown of page groups that are impacted”, with example URLs ordered by impressions.

Validating fixes: the Start Tracking workflow

The report has a built-in validation loop that’s easy to overlook. Google: “When you think a particular issue is fixed, click Start Tracking on the issue details page in the Search Console Core Web Vitals report.” That starts a 28-day monitoring session for the issue — Google watches the group’s field data accumulate over that window rather than re-checking it instantly. Three things worth knowing about how it resolves: any single affected URL still failing during the window can keep the whole issue from passing; the statuses you’ll see are Not started / Started / Looking good / Passed / N/A / Failed at the issue level, and Pending / Passed / Failed per URL; and clicking Start Tracking doesn’t trigger reindexing or any other active crawl behavior — it’s purely a monitoring flag on data Google already collects. This is the proper way to confirm a fix landed in the field — not just eyeballing the aggregate chart and hoping.

Core Web Vitals report vs. PageSpeed Insights

These two tools draw from the same CrUX well but present it differently, and they’ll regularly disagree for a URL. Two documented reasons:

• Group vs. individual. Google: “Core Web Vitals combines data and status into URL groups; PageSpeed Insights generally shows data for individual URLs.” A single URL can be an outlier in its group, so the group status and the PSI number for that exact URL won’t match.
• URL parametersThe `?key=value` data tacked onto the end of a URL after a question mark — used for tracking, sessions, filtering, sorting, and search — and one of the biggest sources of duplicate URLs and wasted crawling in SEO.. “Core Web Vitals URLs include URL parameters when distinguishing the page; PageSpeed Insights strips all parameter data from the URL, and then assigns all results to the bare URL.” This alone explains a lot of “why don’t these two tools agree” complaints.

There’s also a data-breadth difference worth keeping straight, because “field data” and “lab data” get used loosely. The GSC report is CrUX field data only, grouped — nothing else. PageSpeed Insights blends three separate things: URL-level CrUX field data, a fallback to origin-level CrUX field data when the URL itself doesn’t have enough, and a live Lighthouse lab run. As I note in the PSI guide, “PageSpeed Insights also pulls in the page level data, as well as origin data and lab test data which comes from Lighthouse.” The GSC report has none of that lab layer — it’s field data, full stop.

My actual workflow, and the practical tip most competitor articles miss: diagnose and validate fast in PSI’s lab data, confirm slow-but-real in GSC. From the PSI guide: “The CWV data will take longer to show the impact of any changes because it is a 28-day average, so use PSI or the PSI data in Ahrefs to check if the changes you made improved the lab test metrics.” You get instant lab feedback that a change helped; then you wait for the field data in GSC to catch up over the following weeks.

”No data available” and low-traffic sites

Google’s own explanation: “If you see a ‘No data available’ screen, it means either that your property is new in Search Console, or that there is not enough data available in the CrUX report to provide meaningful information for the chosen device type (desktop or mobile).” CrUX has an eligibility threshold — a URL or origin needs enough Chrome traffic before any field data appears at all.

How common is that? Very. In my January 2022 study matching CrUX against 43.66M unique Site Audit pages, “We found only 5.21M (~11.9%) had at least one Core Web Vitals metric, and 93% of those (or ~4.85M total) had all three metrics.” That study looked at the raw CrUX dataset (the same source the GSC report draws on), not GSC itself, and the number is from January 2022 — so treat it as a scale-setter, not a current percentage. The point stands: most pages on the web simply don’t get enough Chrome traffic to generate field data, which is exactly why the report leans on origin-level grouping and why so many sites see nothing. If you’re one of them, that’s not a clean bill of health — test individual URLs in PageSpeed Insights or Lighthouse instead.

TIP Separate no field data from a passing Core Web Vitals result

No CrUX sample means the field verdict is unavailable, not good. A lab run can help debug, but it cannot manufacture real-user evidence.

Check the field-data boundary with my free Page Speed Test Free

1. Test the affected URL and compare URL-level with origin-level field availability.
2. If field data is unavailable, use a fresh lab audit only to generate debugging hypotheses.
3. Wait for sufficient real-user data or evaluate a representative higher-traffic group; do not record missing data as a pass.

Tap to enlarge

The result says Chrome does not have enough field data for the page, no stable CrUX sample is available at URL or origin level, and both mobile and desktop are not evaluated. It offers a separate fresh lab audit and a saved baseline for later comparison.

FID is gone — what changed in March 2024

Get this one exactly right, because stale tutorials still show it wrong. Interaction to Next Paint (INP) replaced First Input Delay (FID) as a Core Web Vital on March 12, 2024. The Search-Console-specific detail almost nobody covers: per the Chrome team’s web.dev announcement, “FID will be removed from Google Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. as soon as INP becomes a Core Web Vital on March 12. All other tools—such as PageSpeed Insights and CrUX—will offer a six-month deprecation period to give developers a chance to update their code.” So GSC dropped FID immediately, with no grace period, while PSI and CrUX kept showing it for six more months. If you see FID in a Search Console screenshot, it’s from before March 2024.

Whatever happened to the Page Experience report?

A real, still-searched confusion point. Google removed the standalone Page Experience report — the old rollup dashboard that combined Core Web Vitals with HTTPSHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.' and other UX signals — from Search Console on April 19, 2023. What survived: the Core Web Vitals report and the HTTPS reportA Google Search Console report showing how many of your indexed URLs are served over HTTPS vs HTTP — and, for the HTTP ones, why the secure version isn't being used. It's a diagnostic sample, not a full crawl inventory. both continue to exist as their own standalone reports. Only the combined summary went away. So if you’re hunting for a “Page Experience” dashboard and can’t find it, that’s why — the two reports underneath it are still there. (Sibling reports like the Performance reportThe Google Search Console report that shows how your site actually performed in Google Search, built from real impressions and clicks. It reports four metrics — clicks, impressions, average CTR, and average position — and keeps the most recent 16 months of data. and the Page IndexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. report cover the rest of your Search Console footprint.)

Prioritizing and fixing what the report finds

Google splits its own guidance into non-technical and developer tracks — a nice tell that this report is read by very different audiences. The prioritization rule for everyone: fix “Poor” first, then “Need improvement.” For developers, the URLs inside a group are sorted by impressions descending, so the ones at the top move the group status the most.

The common page-level fixes Google calls out are blunt but real: “Reduce your page size: best practice is less than 500KB for a page and all its resources.” Beyond that, the actual how-to of improving LCP, INP, and CLS belongs to the individual metric topics — I won’t duplicate it here. The report’s job is to tell you which templates to go fix, not to fix them for you.

Why did my status change when I didn’t touch anything?

Extremely common, and usually not a bug. Google’s own troubleshooting: “If you didn’t make any changes in your site, but you see a big change in status for a lot of pages, it’s possible that you had a borderline status for many pages, and some site-wide event pushed your pages over the edge.” Traffic-mix shifts, a CDN or image-host latency change, a widely-adopted browser update — any of these can nudge a batch of already-borderline URLs across a threshold at once, because the report is a 28-day p75 aggregate.

And sometimes the count of eligible URLs just fluctuates. During a July 2025 episode where the number of URLs showing eligible data dipped (mobile especially), John Mueller characterized this kind of movement as normal sample-size variation, not a problem — that these reports are based on samples of what Google knows about a site, that sample sizes change, and that isn’t indicative of a problem. Google’s Barry Pollard, who works on the Core Web Vitals project, acknowledged the dip and said a fix was rolling out. The teaching point: the eligible-URL count and the underlying metric quality are two different things — a shifting sample doesn’t mean your pages got slower.

Does the report affect rankings?

The report reflects the same field data Google’s ranking systems can factor in, but reps have consistently framed Core Web Vitals as a minor, tie-breaker-level signal next to content relevance — the fuller ranking-weight discussion lives in the Core Web Vitals glossary, so I’ll keep it to one line here. My honest take: I don’t think hitting these thresholds moves the needle much today, though Google could lean on the signal harder over time the way it eventually did with mobile-friendliness and HTTPS. There’s also a non-ranking reason to care that gets overlooked: faster pages capture more recorded data (CrUX and your own analytics), because fewer users bounce before the page finishes loading. Improving these metrics mostly helps because it’s a proxy for a genuinely better experience.

A quick note on Bing

There’s no direct Bing equivalent — a dedicated, CrUX-style Core Web Vitals report with URL grouping — inside Bing Webmaster ToolsMicrosoft's free portal for monitoring and improving how a site appears in Bing search — the peer to Google Search Console, plus IndexNow instant indexing, richer backlink data, and keyword volumes. Because Bing's index also feeds Microsoft Copilot, it doubles as a window into AI-search visibility.. Bing centers its reporting on a Performance Report (clicks/impressions) and a Site Scan technical audit rather than a field-data Core Web Vitals breakdown. Bing references Core Web Vitals-style metrics in its guidance, but hasn’t shipped a grouped field-data report comparable to Google’s. Bing’s tooling changes fairly often, so verify against current Bing Webmaster Tools docs if this matters to you.

Where this fits

This report is one of several in Google Search Console. The Performance report covers how you actually did in search (clicks, impressions, position); the Page Indexing reportThe Google Search Console report (formerly Index Coverage) showing how many of your URLs are indexed vs. not indexed, and grouping the not-indexed ones by reason. covers the coverage/indexing side. The metrics this report surfaces — Core Web Vitals, CrUX, and PageSpeed Insights as the lab-data companion — are their own deep dives in the web performance cluster.

AI summary

A condensed take on the Advanced version:

• It’s a report, not the metrics. The Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. report (GSCA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. → Experience) surfaces CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. field dataPerformance metrics captured from real users, not lab tests. (28-day rolling, 75th percentile) for your indexedStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. URLs. It computes nothing new and contains no lab data.
• Three groupings: device (independent Mobile/Desktop tabs, never averaged), status (Poor / Need improvement / Good, worst metric wins), and URL group (clusters of similar-templated pages sharing one status).
• URL groups are the atomic unit — not individual URLs. One template fix can clear thousands of flagged URLs (Mueller). A “Poor” group can still contain fast pages.
• Privacy cascade: URL group → origin group → “No data available.” New/low- traffic sites often see nothing; only ~12% of pages had any CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. data in Patrick’s 2022 study.
• Won’t match PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking.: group vs. single-URL data, and GSC keeps URL parameters distinct while PSI strips them to the bare URL.
• Eligibility gate: a URL group needs threshold data for both LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. and CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good. before it appears at all — short on either, it’s omitted, not marked passing. Only indexed URLs, and only a sample; data is assigned to the actual URL, not the canonical.
• Chart vs. table count differently (chart = each URL once by worst issue; table = every issue), so totals don’t reconcile.
• FID removed March 12, 2024 when INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. became a Core Web Vital — GSC dropped it immediately, vs. PSI/CrUX’s six-month grace period.
• Page Experience report removed April 2023; Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. + HTTPS reportsA Google Search Console report showing how many of your indexed URLs are served over HTTPS vs HTTP — and, for the HTTP ones, why the secure version isn't being used. It's a diagnostic sample, not a full crawl inventory. remain.
• Workflow: fix Poor first, validate with Start Tracking — a 28-day monitoring session where any still-failing URL blocks a pass and nothing gets reindexed — diagnose fast in PSI, and wait ~a month for the field data to catch up. Status changes with no site changes are usually borderline URLs tipping over a threshold, or sample-size noise.

Official documentation

Primary-source documentation from Google.

Google

• Core Web Vitals report — the canonical Help page: data source (CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program.), device/status/URL-group organization, “No data available”, the origin-group fallback, chart-vs-table counting, PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking. differences, and the Start Tracking validation workflow.
• Interaction to Next Paint becomes a Core Web Vital on March 12 — the Chrome team’s announcement, including the Search-Console-specific line that FIDFirst Input Delay — a retired Core Web Vital that measured the delay before the browser could begin processing a page's first interaction. Good was ≤100 ms. Replaced by INP in March 2024. was removed from GSCA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. immediately (vs. the six-month grace period in PSI/CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program.).
• Introducing INP to Core Web Vitals — Google Search Central’s May 2023 announcement of the FID → INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. transition.
• Understanding Core Web Vitals and Google Search results — the Search Central overview with the current thresholds (still 2.5s / 200ms / 0.1 at research time).

Quotes from the source

On-the-record statements from Google. Each link is a deep link that jumps to the quoted passage on the source page.

Google — what the report is and where the data comes from

• “The Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. report shows how your pages perform, based on real world usage data (sometimes called field dataPerformance metrics captured from real users, not lab tests.).” — Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. Help. Jump to quote
• “The data for the Core Web Vitals reportThe Google Search Console report (under Experience) that shows how your indexed URLs perform on the Core Web Vitals — LCP, INP, and CLS — using real-user field data from CrUX, grouped by device, status, and clusters of similar-performing URLs. comes from the CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. report… The CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. database gathers information about URLs whether or not the URL is part of a Search ConsoleGoogle's free tool for monitoring crawling, indexing, and search performance. property.” Jump to quote
• “Only indexedStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. URLs can appear in this report. This report isn’t a comprehensive list of all indexed URLs. It shows a sample of pages to help you assess your site’s performance based on Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data..” Jump to quote
• “Data is assigned to the actual URL, not the canonical URLHow search engines pick one canonical URL among duplicates and consolidate signals onto it., as it is in most other reports.” Jump to quote

Google — URL groups and the privacy fallback

• “URLs in the report are grouped into pages that have a similar user experience. The LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good., INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good., and CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good. status applies to the entire group. Some outlier URLs might have better or worse values on some visits, but 75% of visits to all URLs in the group experienced the group status shown.” Jump to quote
• “In order to respect user privacy, a URL group must have a minimum amount of data to be shown in the report. If a URL group doesn’t have enough information to display in the report, Search Console creates a higher-level origin group that should contain enough URLs and data to show in the report.” Jump to quote

Google — reading the report and validating fixes

• “The chart counts each URL only once, for the slowest issue affecting that URL. The table, in contrast, counts every issue associated with a URL.” Jump to quote
• “The report is not designed find the status of a specific URL, but rather to see your site’s performance as a whole, and troubleshoot issues affecting multiple pages on your site.” Jump to quote
• “When you think a particular issue is fixed, click Start Tracking on the issue details page in the Search Console Core Web VitalsWeb Vitals is Google's initiative (launched May 2020) for unified page-experience quality signals. Core Web Vitals — LCP, INP, and CLS — are the subset used in ranking; the rest (TTFB, FCP, TBT, Speed Index) are diagnostic, not ranking factors. report.” Jump to quote

Google — vs. PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking., and “No data available”

• “Core Web Vitals combines data and status into URL groups; PageSpeed Insights generally shows data for individual URLs.” Jump to quote
• “Core Web Vitals URLs include URL parametersThe `?key=value` data tacked onto the end of a URL after a question mark — used for tracking, sessions, filtering, sorting, and search — and one of the biggest sources of duplicate URLs and wasted crawling in SEO. when distinguishing the page; PageSpeed Insights strips all parameter data from the URL, and then assigns all results to the bare URL.” Jump to quote
• “If you see a ‘No data available’ screen, it means either that your property is new in Search Console, or that there is not enough data available in the CrUX report to provide meaningful information for the chosen device type (desktop or mobile).” Jump to quote

Google — FID → INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. in Search Console (Chrome team, web.dev)

• “FID will be removed from Google Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. as soon as INP becomes a Core Web Vital on March 12. All other tools—such as PageSpeed Insights and CrUX—will offer a six-month deprecation period to give developers a chance to update their code.” Jump to quote

John Mueller, Google — why the report groups URLs (2021)

• “We do that with the Chrome User Experience Report data, the field real-world data, essentially, where we try to recognize when there are pages that are similar enough that we could group them together.”
• “We might have one group, essentially, for a site. But that could contain thousands of URLs. So, in the report in Search Console, I think we would report that as thousands of URLs have this problem.” Read the coverage

Which tool (or path) should I take?

“I want to check one specific page’s Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data..” → Not this report. Use PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking. (field + lab for that URL) or the URL Inspection toolA Google Search Console feature that reports how Google sees one specific URL on a property you own. By default it shows the last-indexed snapshot; a separate \"Test live URL\" mode fetches the current version.. The Core Web Vitals reportThe Google Search Console report (under Experience) that shows how your indexed URLs perform on the Core Web Vitals — LCP, INP, and CLS — using real-user field data from CrUX, grouped by device, status, and clusters of similar-performing URLs. is “not designed [to] find the status of a specific URL.”

“The report says ‘No data available.’” → Is the property brand new? Give CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. a few days to populate. → Otherwise it’s almost certainly insufficient traffic — even the origin group can’t clear the privacy threshold. Test individual URLs in PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking. / LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. instead. “No data” is not a clean bill of health.

“A group is ‘Poor’ — what do I fix first?” → Fix everything labeled Poor before anything labeled Need improvement. → Within a group, the URLs are sorted by impressions descending — the ones at the top move the group status the most. → The status is set by the group’s worst metric — find which of LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. / INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. / CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good. is failing and fix that one.

“My GSC status and PageSpeed Insights disagree for the same URL.” → Expected. GSC reports the group; PSI reports the individual URL (which may be an outlier). And GSC keeps URL parametersThe `?key=value` data tacked onto the end of a URL after a question mark — used for tracking, sessions, filtering, sorting, and search — and one of the biggest sources of duplicate URLs and wasted crawling in SEO. distinct while PSI strips them to the bare URL. Neither is wrong — they’re measuring different things.

“I shipped a fix — how do I confirm it worked?” → Check the lab result in PageSpeed Insights immediately for fast feedback. → Click Start Tracking on the issue in GSC to validate in the field. → Then wait — the 28-day rolling window means the report takes roughly a month to fully reflect the change.

“My status changed but I didn’t touch the site.” → Usually borderline URLs tipping over a threshold from an external shift (traffic mix, CDN/image latency, a browser update) — or plain sample-size fluctuation. Check whether it’s the eligible-URL count moving or the underlying metric quality; they’re different things.

Reading the Core Web Vitals report — a sanity checklist

A quick pass before you draw conclusions or hand a developer a punch list:

• You checked both the Mobile and Desktop tabs — they’re independent and can disagree.
• You’re treating URL groups, not individual URLs, as the unit — one fix likely clears the whole group.
• You understand a “Poor” group can contain fast pages (group status is p75 across the cluster).
• You know the chart and table won’t reconcile (chart counts each URL once by worst issue; table counts every issue).
• You’re fixing “Poor” before “Need improvement”, and prioritizing by the URLs with the most impressions.
• You identified which metric (LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. / INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. / CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good.) sets each group’s status before touching code.
• For single-URL checks you switched to PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking. / URL InspectionA Google Search Console feature that reports how Google sees one specific URL on a property you own. By default it shows the last-indexed snapshot; a separate \"Test live URL\" mode fetches the current version., not this report.
• You’re not expecting GSCA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. to match PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking. (group vs. URL; params kept vs. stripped).
• If you see “No data available”, you checked traffic/eligibility rather than assuming your pages are fine.
• After a fix, you clicked Start Tracking and are giving the field dataPerformance metrics captured from real users, not lab tests. ~a month to catch up.
• You’re not chasing a status change that’s really borderline-threshold or sample-size noise.

The mental models

1. It’s a report, not a meter. Every number is CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. field dataPerformance metrics captured from real users, not lab tests. — real Chrome users, 28-day rolling window, 75th percentile. The report surfaces that data; it doesn’t compute anything new and has no lab layer. So it always describes the recent past, never “right now.”

2. The URL group is the atomAn RSS or Atom feed is an XML file listing a site's most recently published or updated URLs. Search engines accept it as a sitemap-style discovery signal for fresh content — not a replacement for a full XML sitemap.. Stop thinking in single URLs. Google groups similar-templated pages, assigns one status to the whole cluster, and can flag thousands of URLs from one template flaw. Fix the template once, fix the group. A fast URL can still sit inside a “Poor” group.

3. Worst metric wins. A group’s status is set by its weakest of LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. / INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. / CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good.. Before you optimize anything, find which metric is failing — you don’t fix “the group,” you fix the metric dragging it down.

4. The privacy cascade explains the gaps. URL group → origin group → “No data available.” Not enough traffic to report privately means coarse groupings or nothing at all. “No data” means insufficient CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. data, not a clean site.

5. Two tools, two jobs — diagnose fast, confirm slow. PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking. = single-URL, field + lab, instant feedback. The GSCA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. report = grouped, field-only, ~month-lagged. Diagnose and validate a fix in PSI’s lab data; wait for the GSC field data to confirm it in the real world.

Core Web Vitals report — cheat sheet

How it’s organized

GSCA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. report vs. PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking.

Fast facts

• Data source: CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. field dataPerformance metrics captured from real users, not lab tests., 28-day rolling, p75, per device.
• Only indexedStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. URLs; a sample, not all of them; assigned to the actual URL, not the canonical.
• “No data available” = new property or insufficient CrUX traffic (URL group → origin group → nothing).
• Chart counts each URL once (worst issue); table counts every issue — totals won’t match.
• FIDFirst Input Delay — a retired Core Web Vital that measured the delay before the browser could begin processing a page's first interaction. Good was ≤100 ms. Replaced by INP in March 2024. removed from GSC March 12, 2024 (immediately; PSI/CrUX kept it 6 more months).
• Page Experience report removed April 19, 2023; Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. + HTTPS reportsA Google Search Console report showing how many of your indexed URLs are served over HTTPS vs HTTP — and, for the HTTP ones, why the secure version isn't being used. It's a diagnostic sample, not a full crawl inventory. remain.
• Fix Poor first, validate with Start Tracking, expect ~28 days for the report to reflect it.
• Page-weight rule of thumb (Google): under 500KB for a page and all its resources.

Core Web Vitals report mistakes

Treating every URL in a Poor group as individually slow. The status belongs to the group at the 75th percentile, so an individual member can be faster or slower. Diagnose representative URLs, then fix the shared template or component.

Checking only Mobile or only Desktop. The datasets are separate and can disagree. Triage both tabs independently instead of averaging them into one story.

Calling “No data available” a pass. It usually means the URL or origin lacks enough eligible CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. traffic to report. Use lab testing and other field-data sources; do not claim the page is Good.

Expecting GSCA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. to match PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking. for one URL. GSC reports groups and preserves URL parametersThe `?key=value` data tacked onto the end of a URL after a question mark — used for tracking, sessions, filtering, sorting, and search — and one of the biggest sources of duplicate URLs and wasted crawling in SEO.; PSI generally reports a single bare URL. Understand the unit and URL handling before treating a difference as a bug.

Optimizing the metric that is already Good. The group’s weakest metric sets its status. Identify whether LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good., INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good., or CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good. is responsible before handing work to a developer.

Calling Start Tracking immediately after a lab-only fix. First verify the change is deployed on all affected templates. Then start field validation once, and allow the rolling CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. window to collect real-user evidence.

Using the chart and table totals as a reconciliation check. The chart counts each URL once by its worst issue; the table counts every issue attached to a URL. Different totals are expected.

Validate a Core Web Vitals fix

Use three layers of proof. No single layer is enough by itself.

1. Deployment proof

• Reproduce the slow interaction, unstable element, or late-loading largest element on a representative affected URL.
• Confirm the changed code is present in production—not just a preview—and on every template represented by the URL group.
• Run LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. or another lab trace before and after under the same test conditions. The targeted metric should improve without another Core Web Vital regressing.

2. Report-workflow proof

• Open the exact issue row and record its device, status, metric, URL group, and example URLs.
• Spot-check examples in PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking., remembering that an individual URL can differ from its GSCA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. group.
• Click Start Tracking only after the production rollout is complete. Watch the issue’s validation state rather than repeatedly restarting it.

3. Field-result proof

• Wait for the 28-day rolling CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. window to absorb the post-release visits.
• Confirm the affected group improves on the same device and metric that originally failed.
• Check both Mobile and Desktop, and distinguish a genuine metric improvement from a change in which URLs had enough data to be eligible.
• If GSC remains unchanged, compare the group’s example URLs with URL-level and origin- level PSI data before deciding the deployment failed.

The pass condition is not “LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. turned green once.” It is: the production fix is present across the group, controlled lab evidence improves, and the relevant GSC field issue clears after enough real-user data arrives.

Measure progress without inventing a performance score

Track these separately by device, metric, URL group, and release date:

Use Google’s published Good thresholds—LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. at or below 2.5 seconds, INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. at or below 200 milliseconds, and CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good. at or below 0.1, measured at the 75th percentile—as the quality bar. Do not invent a universal deadline or percentage-improvement target. The useful trend is fewer eligible URLs in failing groups, cleared issue validations, and stable gains across successive 28-day windows without trading one metric for another.

Resources worth your time

My related writing

• What Are Core Web Vitals (CWVs) & How To Improve Them — my guide to the metrics themselves and how the GSCA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. report groups impacted pages by template.
• Google PageSpeed Insights For SEOs & Developers — the lab-data companion, and my “diagnose in PSIPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking., monitor in GSC” workflow (the 28-day-lag tip lives here).
• Core Web Vitals Data Study w/ CrUX & 5.2M Pages — my large-scale look at how few pages have any CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. data at all (the ~12% figure), which explains most “No data available” screens.

My speaking / interviews

• Google’s Core Web Vitals for SMBs: A Conversation with Patrick Stox (Outside Communications) — a short, non-technical explanation of what the report is for: “you fix it once, you fix that issue for all those pages.”

Official

• Core Web Vitals report — Search Console Help — the canonical reference for everything in this article.
• INP becomes a Core Web Vital on March 12 — web.dev — the FIDFirst Input Delay — a retired Core Web Vital that measured the delay before the browser could begin processing a page's first interaction. Good was ≤100 ms. Replaced by INP in March 2024.-removed-from-GSC-immediately detail.

From around the industry

• Google Discusses Grouping URLs for Core Web Vitals Scores (Search Engine Journal) — the John Mueller Office Hours transcript on why one group can flag thousands of URLs.
• Google Search Console: How To Use The Core Web Vitals Report (DebugBear) — a practical setup-to-fix walkthrough, and a good explanation of why fast pages can land in slow groups.
• Core Web Vitals in Google Search Console: Fix & Optimize (Quattr) — a structured optimize workflow (sort → prioritize → test → resolve → validate).
• Google Search Console page experience report going away (Search Engine Land) — coverage of the April 2023 removal of the Page ExperienceGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. rollup.
• Core Web Vitals report within Google Search Console updated (Search Engine Land) — the March 2023 addition of the origin-group fallback layer.
• Google Core Web Vitals Search Console Update (Search Engine Roundtable) — the July 2025 eligible-URL dip, with Mueller and Pollard on sample-size fluctuation.

Stats worth citing

• Only ~12% of the 43.66M unique Site Audit pages in the January 2022 sample had any CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. metric. In my study, “We foundA 302 (\"Found\") is a temporary redirect: it forwards users to a new URL while telling search engines the original URL should stay in the index. It's a weak canonicalization signal, not the zero-equity dead end of SEO folklore. only 5.21M (~11.9%) had at least one Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. metric, and 93% of those (or ~4.85M total) had all three metrics.” That’s the underlying CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. dataset the report draws on — the scale-setter for why so many sites see “No data available.”
• FIDFirst Input Delay — a retired Core Web Vital that measured the delay before the browser could begin processing a page's first interaction. Good was ≤100 ms. Replaced by INP in March 2024. removed from GSCA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. on March 12, 2024 — immediately, with no grace period, while PSIPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking. and CrUX offered a six-month deprecation window. Source
• Page-weight rule of thumb: under 500KB for a page and all its resources, per Google’s own guidance in the report’s “Fix issues” section. Source
• Page Experience report removed April 19, 2023 — the Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. and HTTPS reportsA Google Search Console report showing how many of your indexed URLs are served over HTTPS vs HTTP — and, for the HTTP ones, why the secure version isn't being used. It's a diagnostic sample, not a full crawl inventory. are what remain of that old rollup. Coverage

Test yourself: the Core Web Vitals report

Five quick questions on how Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results.’s Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. report works. Pick an answer for each, then check.

Core Web Vitals report

The Google Search Console report (under Experience) that shows how your indexed URLs perform on the Core Web Vitals — LCP, INP, and CLS — using real-user field data from CrUX, grouped by device, status, and clusters of similar-performing URLs.

Related: Core Web Vitals, CrUX, PageSpeed Insights, Performance report

Core Web Vitals report

The Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. report is the Google Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. report (foundA 302 (\"Found\") is a temporary redirect: it forwards users to a new URL while telling search engines the original URL should stay in the index. It's a weak canonicalization signal, not the zero-equity dead end of SEO folklore. under the Experience section) that shows how your indexedStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. URLs perform on Google’s three Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. — LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good., INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good., and CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good.. Google’s own one-liner: it “shows how your pages perform, based on real world usage data (sometimes called field dataPerformance metrics captured from real users, not lab tests.).”

The key thing to understand is that this is a report inside GSC, not the metrics themselves. It surfaces field data from the Chrome UX ReportChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. (CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program.) — the same 28-day, 75th-percentile data Google’s ranking systems can use elsewhere — it doesn’t compute anything new. It groups URLs three ways: by device (separate Mobile and Desktop tabs), by status (Poor, Need improvement, Good), and by URL group (clusters of similar pages that share a status).

That grouping is the report’s defining mechanic. Rather than scoring every URL individually, Google buckets similar-templated pages together, so one fix to a shared template can resolve an issue across thousands of URLs at once. The status of a group is set by its worst-performing metric.

The report needs enough CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. traffic to populate, so new or low-traffic properties often see “No data available.” For single-URL debugging and lab data, PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking. is the companion tool; this report is built for site-wide, template-level triage. FID was removed from it on March 12, 2024, when INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. became a Core Web Vital.

Related: Core Web Vitals, CrUX, PageSpeed Insights, Performance report

Changelog