Chrome UX Report (CrUX)

TL;DR — 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. is Google’s collection of real-world speed data from actual Chrome users. It’s the data Google uses to judge your 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 the lab score a tool like 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. generates on a single test machine. That’s why your 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. score can be green while 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. says you need work: they measure different things.

What CrUX is

The Chrome User Experience Report — CrUX for short — is a free dataset Google publishes that shows how real people, on real devices and real networks, experience websites. Instead of testing a page once in a lab, CrUX gathers measurements from large numbers of actual Chrome users and reports the result.

This is called field dataPerformance metrics captured from real users, not lab tests. (sometimes “real-user” data). It’s the opposite of lab data, which is what a tool like Lighthouse produces by loading your page once on a controlled test machine. Both are useful, but only one of them is what Google looks at to assess your site.

Why it matters

CrUX is the official dataset behind 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. program. Google’s ranking systems use 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. measured from real-user field data, not a Lighthouse lab score. So if you only ever look at your Lighthouse number, you might be looking at the wrong thing entirely.

You’ve already seen CrUX even if you didn’t know it. The “Discover what your real users are experiencing” section at the top of 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 CrUX. The Search ConsoleGoogle's free tool for monitoring crawling, indexing, and search performance. 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 CrUX. Those are the numbers that count.

The thing most people get wrong

A good Lighthouse score does not mean your Core Web Vitals are good. Lighthouse runs once, on one simulated device, with a throttled network and an empty cache. Your real visitors are on a mix of phones, laptops, fast and slow connections, near and far. CrUX captures that mess; Lighthouse doesn’t. A page can score 95 in Lighthouse and still show “Poor” in CrUX if most of your real users are on slow mobile.

One more thing that surprises people: not every page is in CrUX. A URL needs enough real visits to be included. Lots of low-traffic pages have no CrUX data at all, so tools fall back to showing your whole-site (“origin”) data instead, or just say there’s no field data yet.

Want the methodology — the 28-day window, the 75th percentile, origin vs URL data, and every way to pull CrUX data? Switch to the Advanced tab.

TL;DR — 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. is the official Chrome User Experience Report: real-world field UX data aggregated from eligible Chrome users — those who meet Google’s opt-in, sync, and supported-platform criteria — and the dataset behind 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. program. It’s reported at the 75th percentile over a trailing 28-day aggregation window, at both origin and URL level. Coverage is partial — never every Chrome user and never every visitor, only eligible Chrome users on supported platforms (no Chrome on iOS, no Edge/Safari/Firefox), and a page needs enough samples to be included, so many low-traffic URLs have no CrUX data and tools fall back to origin-level or “no data.” Six surfaces currently expose it: 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., 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., the CrUX API (daily), the History API (weekly), BigQuery (monthly), and CrUX Vis — check current docs, since cadence and quotas can change. CrUX is field; 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. is lab — that’s why the two disagree.

CrUX is the field-data layer of Core Web Vitals

Google describes it plainly: “The Chrome User Experience Report … is a dataset that reflects how real-world Chrome users experience popular destinations on the web.” And it’s not a side project — “CrUX is the Google dataset of the Web Vitals program. All user-centric 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. metrics are represented.” The data is “used by Google Search to inform the page experience ranking factor.”

So the mental model is: 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. are the metrics; CrUX is the dataset they live in. When Search assesses your CWV, it reads CrUX. That single fact resolves most of the confusion on this page.

How CrUX collects data

CrUX is built from real Chrome users — but a specific, eligible subset of them, not every Chrome user and not every visitor to your site. A user’s experiences are only aggregated if they meet all four criteria: “Enable usage statistic reporting. Sync their browser history. Not have a Sync passphrase set. Use a supported platform.”

“Supported platform” is doing a lot of work. Included: desktop Chrome on Windows, macOS, ChromeOS, and Linux, plus Android Chrome (including Custom Tabs and WebAPKs). Excluded: Chrome on iOS, Android WebViews, and “other Chromium browsers.” In practice that means Microsoft Edge, Samsung Internet, Safari, and Firefox are not in CrUX at all — and neither is any iOS browser, because they all run on WebKit.

This is the blind spot worth internalizing. If you run an e-commerce or media site where most traffic is iPhone/Safari, CrUX may be measuring a minority of your real audience. The data isn’t wrong — it just isn’t everyone.

Why some pages have no CrUX data

CrUX doesn’t cover every page, and this trips up a lot of people. From Google: “Not all origins or pages are represented in the dataset. There are separate eligibility criteria for origins and pages, primarily that they must be publicly discoverable and there must be a large enough number of visitors in order to create a statistically significant dataset.” The exact popularity threshold is deliberately undisclosed — treat any specific visitor number you see quoted as an unofficial estimate, not a documented rule.

Page and origin eligibility are evaluated separately. An origin can have enough eligible traffic to be reported even when many of its individual pages don’t — which is exactly why a domain can show origin-level data while a specific URL on it has none. And a missing result isn’t a score: it just means Google doesn’t have a large-enough eligible sample to report anything for that scope. Missing is not a zero, not a pass, and not a fail.

There are mechanical requirements too: the page has to return 200 (after redirectsA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't.) and must not be noindex’d (header or meta tag). And there’s a 20% rule — “origins or pages having more than 20% of their total traffic excluded due to ineligible combinations of dimensions are excluded entirely from the dataset.”

I’ve measured how thin this coverage gets. In my Core Web Vitals data study I combined CrUX with an Ahrefs crawl of 43.66 million pages. Only 5.21 million of them — roughly 11.9% — had at least one Core Web Vitals metric in the January 2022 CrUX dataset. The rest had too little traffic to qualify. That’s the normal state of the web, not an error.

When a specific URL has no data, tools cascade. 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.: URL-level CrUX → if insufficient, fall back to origin-level CrUX → if that’s also missing, you get no field dataPerformance metrics captured from real users, not lab tests. and only the 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. lab section remains. Google’s note on why fine-grained lookups fail more often: “The more fine-grained the request is, for example a specific combination of URL and form factor, the fewer user experiences it will include. This may lead to more frequent ‘not 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.’ errors.”

How CrUX aggregates: 28 days and p75

Two numbers define how CrUX reports everything.

The 28-day rolling window. “The data in the Chrome UX Report is a 28-day rolling average of aggregated metrics.” Every reading you see is a trailing 28-day aggregate. One consequence Google flags: “the collectionPeriod will always show 28-days, even if the data is not for the full 28 days (for example if a page was launched less than 28 days ago).”

The practical upshot — and I’ve made this point for years — is that fixes take a while to show up. CrUX runs about two days behind real time, and every reading is an aggregation over the trailing window, not a live number — so a change doesn’t fully replace the old data until enough new eligible sessions have accumulated and the old ones have aged out. On the order of a month is a reasonable rule of thumb, but it isn’t a fixed countdown: how fast a fix shows up depends on how much eligible traffic the page or origin gets, the metric’s own lifetime, and the collection period reported for that record. As I put it in my CLS guide, “it takes a while to see the impact of changes.” Useful for setting stakeholder expectations: don’t promise day-one movement, and don’t promise an exact date either.

The 75th percentile (p75). CWV are assessed at p75, not the median. Google’s definition: “75% of page loads experienced the given metric at or less than this value.” So to pass, three of four loads need to be at or under the “good” threshold. Important caveat from Google: the percentile values “are synthetically derived, it does not imply that any user actually experienced the value indicated.” p75 of “good” doesn’t mean “75% of users are happy” in any literal sense — it means 75% of page loads came in at or below the threshold, and the top quartile isn’t penalized as long as that holds.

Origin-level vs URL-level

CrUX reports at two granularities, and the difference is one of the most important things for an SEO to understand.

• Origin-level aggregates “all data present for all pages in that origin … together” — essentially your whole domain averaged.
• URL-level returns “only data for that specific URL.”

These can diverge sharply. A site can show “Good” origin-level CrUX while a specific high-value landing page is “Poor”, because faster pages elsewhere offset it in the origin average. Since PSI falls back to origin data when a URL doesn’t have enough of its own, you can be looking at your domain average while thinking you’re looking at the page in front of you.

My data study surfaced this gap at scale: in that January 2022 sample, ~33% of websites passed CWV at the origin level, but only ~21.2% of individual pages passed. Domain-level numbers ran higher partly because they fold in repeat/cached visits across the whole site. Treat those specific figures as a dated large-sample snapshot, not a current universal rate — but the underlying lesson still holds: check URL-level data for your key pages whenever it’s available, and don’t assume a passing origin means every page passes.

CrUX also splits by form factor — PHONE, TABLET, and DESKTOP — and Google assesses using form-factor-appropriate data, which is why your mobile and desktop numbers differ.

TIP Check the scope label before acting on a Core Web Vitals result

The checker tries URL-level CrUX first, then clearly labels an origin fallback or Lighthouse lab fallback. A poor metric is only interpretable when you retain that scope and source.

Check the current result with my free Page Speed Test & Core Web Vitals Checker Free

1. Enter the exact page and note the URL/origin and field/lab label before reading the score.
2. Compare mobile and desktop, then run a fresh lab audit only to diagnose the field failure.
3. Use Core Web Vitals History & Competitor Comparison when you need weekly history or a side-by-side origin or URL comparison.

Tap to enlarge

The Largest Contentful Paint scale marks 5.2 seconds in the poor red range.

Field vs lab: why your Lighthouse score doesn’t match

This is the core tension and worth being precise about. Field data is “determined by monitoring all users who visit a page and measuring … each one of those users’ individual experiences” — that general category is also called RUM (real-user monitoring), and CrUX is one specific, public implementation of it. Lab data (Lighthouse) is “determined by loading a web page in a controlled environment with a predefined set of network and device conditions.”

They differ because field data “includes a wide variety of network and device conditions as well as a myriad of different types of user behavior,” while a lab test “intentionally limits the number of variables” — one device, one network, one location, and typically a cold cache. PageSpeed Insights literally shows both: the CrUX field section up top (what Google rates you on) and the Lighthouse lab section below (a debugging approximation). As the CrUX docs put it: “CrUX is a collection of real-user experiences from the field, while Lighthouse is a controlled test in the lab.”

So when your local Lighthouse run says 95 but Search ConsoleGoogle's free tool for monitoring crawling, indexing, and search performance. says “Needs Improvement,” nothing is broken — you’re comparing a single clean lab load against the messy reality of your actual users.

CrUX isn’t the same thing as your own RUM. A private, first-party RUM tool (instrumented with something like the web-vitals JS library) and CrUX can report different numbers for the same page, because their populations, consent states, sampling, and metric lifetimes aren’t identical. Think of the three options as different jobs:

• CrUX — the free, public benchmark of eligible Chrome experiences. Use it to see what Google sees, and to check a competitor’s field performance.
• Private RUM — your own instrumented monitoring. Use it when you need every browser (not just eligible Chrome), per-user or per-segment detail, or real-time alerting that CrUX’s rolling window can’t give you.
• Synthetic monitoring (Lighthouse, WebPageTestWebPageTest is a free, open-source, lab-based website performance testing tool — created by Patrick Meenan in 2008 and acquired by Catchpoint in 2020 — that runs pages on real browsers from distributed locations and produces deep diagnostics (waterfalls, filmstrips, connection views, Core Web Vitals). It's a diagnostic tool, not a Google ranking input., and similar) — a controlled, repeatable test. Use it for pre-release regression checks and to diagnose why a field metric is bad, not to declare the field metric fixed.

For general field-vs-lab theory beyond CrUX specifically — RUM tooling options, synthetic monitoring setups, and the broader decision framework — see the Field vs. Lab Data deep dive.

What’s in CrUX (and what isn’t)

The three Core Web Vitals are all present — Largest Contentful PaintLargest 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. (loading), Interaction to Next Paint (responsiveness), and Cumulative Layout Shift (visual stability) — assessed at p75 against these thresholds:

Beyond the three, CrUX also carries supporting metrics like FCPFirst Contentful Paint — the time from when a page starts loading to when any part of its content (text, image, SVG, or non-white canvas) first renders. Good is ≤1.8 s at the 75th percentile. It's a diagnostic metric, not a Core Web Vital. (First Contentful Paint), experimental TTFBTime to First Byte — the time from the start of a request to when the first byte of the response arrives. It's a diagnostic metric (not a Core Web Vital) and a major input to FCP and LCP; ≤0.8 s is good., and RTT (Round Trip Time, which replaced the retired ECT dimension in January 2025), plus LCP image subparts and navigation types.

What CrUX doesn’t have are lab-only diagnostics: Total Blocking Time, Speed Index, and Time to Interactive don’t exist in CrUX — you only get those from Lighthouse. And note the historical shift: INP replaced FID as a Core Web Vital in March 2024, and FID was removed from CrUX in August 2024 (and from BigQuery in September 2024). A lot of older guides still reference FID — they’re out of date.

Six ways to access CrUX

Cadence, quotas, and history depth below are current as of this writing — Google has changed them before (the CrUX Dashboard’s deprecation is a recent example), so treat this as a snapshot and check the linked official docs for the current numbers before you build anything that depends on them.

A few specifics worth knowing:

• PageSpeed Insights is the fastest per-URL look. Field data on top, lab below; free, no API key.
• Search Console’s 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. groups your indexed URLs by status (Good / Needs Improvement / Poor) with separate Mobile and Desktop views. Because it groups pages by pattern, a “page group” can mix fast and slow URLs — which is why a page can look fine in PSI but be flagged in GSC.
• The CrUX API (POST …/v1/records:queryRecord) returns the current 28-day window with p75s and histogram bins; query by origin or url (mutually exclusive). It’s free, needs a Google API key, and is “limited to 150 queries per minute per Google Cloud project.”
• The CrUX History API gives up to 40 weeks of weekly snapshots — trend data without touching BigQuery.
• BigQuery is the at-scale option (history to 2017, country-level data the APIs don’t expose) but it’s origin-level only — no per-URL data in the standard tables.
• CrUX Vis (cruxvis.withgoogle.com) is the visual tool. Note: the old CrUX Dashboard in Looker Studio was deprecated in November 2025 — its connector stopped updating. If a guide still points you at the Dashboard, it’s stale; use CrUX Vis instead.

Does CrUX move rankings?

CrUX is the field-data source for the page-experience signal, so yes, it feeds a ranking input — but I’d temper expectations on how much that’s worth. My standing view, from my Core Web Vitals guide: “I don’t expect much, if any, improvement in rankings from improving Core Web Vitals,” and “unless you are extremely slow, I generally won’t prioritize fixing them.” The stronger case for caring about your CrUX numbers is user experience, not a ranking bump. Understand the data; don’t panic about it.

Where this fits

CrUX is the field-data engine under the Core Web Vitals hub. The metrics it reports each have their own deep dives — Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift — and the two main tools that surface CrUX are PageSpeed Insights (field + lab) and Google Lighthouse (lab only). If you only remember one thing: the field/lab split is why a green lab score and a failing CWV assessment can both be true at once.

AI summary

A condensed take on the Advanced version:

• 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., and it’s the dataset behind 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.. When Google assesses your CWV for Search, it reads CrUX — not a 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. lab score.
• Collection is limited to eligible Chrome experiences — users who meet four documented criteria (opt in, sync history, no Sync passphrase, supported platform), never every Chrome user and never every visitor. No Chrome on iOS, no Android WebViews, no Edge/Safari/Firefox. For Safari-heavy audiences, CrUX measures a minority of real users.
• Coverage is partial, and page/origin eligibility are evaluated separately — an origin can qualify even when many of its pages don’t. A missing result means “not enough eligible sample to report,” not a zero or a pass. In my January 2022 sample of 43.66M unique Site Audit pages, only ~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 in CrUX. Tools fall back: URL → origin → “no data” (lab only).
• Aggregation = a trailing 28-day window at p75, not a literal average and not a live number. p75 means 75% of loads were at or below the value; the values are synthetically derived. Fixes generally take on the order of a month to register, but there’s no fixed 30-day guarantee — it depends on eligible traffic volume, metric lifetime, and the window’s own lag.
• Origin vs URL matters. Origin = whole-domain aggregate; URL = that page. They diverge — my study 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. ~33% of sites passed at origin level but only ~21.2% of individual pages. Check URL-level for key pages.
• Field vs lab is why 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. (single clean lab load) disagrees with CrUX (messy real users). 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. shows both. CrUX itself is one specific, public form of RUM — a private, first-party RUM tool and CrUX can still disagree.
• Six access surfaces (cadence/quotas current as of this writing, verify before relying on them): PSI (daily, per-URL), 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. (weekly), CrUX API (daily), History API (weekly, 40 weeks), BigQuery (monthly, origin-only, to 2017), CrUX Vis (weekly visual). The CrUX Dashboard was deprecated Nov 2025 — use CrUX Vis.
• Ranking impact is small; the real case for caring about CrUX is user experience.

Official documentation

Primary-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. documentation from the Chrome team on developer.chrome.com.

• CrUX overview — what CrUX is, its role in the 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. program, and how Search uses it.
• CrUX methodology — the four user eligibility criteria, supported/excluded platforms, the 20% rule, URL stripping, and SPA/iframeHTML element that displays one webpage inside another — how embeds work. handling.
• CrUX API — the 28-day window, p75 definition, the queryRecord endpoint, the 150 req/min rate limit, and daily update cadence.
• CrUX History API — weekly snapshots, up to 40 weeks of history.
• CrUX on BigQuery — monthly release (second Tuesday), origin-level only, history back to 2017, country-level data.
• CrUX Vis — the visual tool that replaced the deprecated CrUX Dashboard.
• PageSpeed Insights + CrUX guide — the URL → origin → no-data fallback cascade, and the field-vs-lab framing.
• CrUX release notes — 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.→INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. transition, FID removal, and Dashboard deprecation timeline.

Related background (web.dev)

• Lab and field data differences — why a lab score and CrUX disagree.
• CrUX and RUM differences — the Chrome-only / iOS-excluded / SPA / iframe details.

Quotes from the source

On-the-record statements from the Chrome team’s 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. documentation. Each link is a deep link that jumps to the quoted passage.

What CrUX is

• “The Chrome User Experience Report (also known as the Chrome UX Report, or CrUX for short) is a dataset that reflects how real-world Chrome users experience popular destinations on the web.” [Jump to quote](https://developer.chrome.com/docs/crux#:~:text=The%20Chrome%20User%20Experience%20Report%20(also%20known%20as%20the%20Chrome%20UX%20Report)
• “CrUX is the Google dataset of the 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. program. All user-centric 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. metrics are represented.” Jump to quote

Eligibility and coverage

• “Not all origins or pages are represented in the dataset. There are separate eligibility criteria for origins and pages, primarily that they must be publicly discoverable and there must be a large enough number of visitors in order to create a statistically significant dataset.” Jump to quote
• The four user criteria: “Enable usage statistic reporting. Sync their browser history. Not have a Sync passphrase set. Use a supported platform.” Jump to quote

Aggregation

• “The data in the Chrome UX Report is a 28-day rolling average of aggregated metrics.” Jump to quote
• “75% of page loads experienced the given metric at or less than this value.” Jump to quote
• “The values for each percentile are synthetically derived, it does not imply that any user actually experienced the value indicated, only that some percentage of page loads experienced a metric value that was less than the value given.” Jump to quote

Origin vs URL

• “When the identifier is an origin all data present for all pages in that origin are aggregated together.” / “When the identifier is a URL, only data for that specific URL will be returned.” Jump to quote

Field vs lab (web.dev)

• “Field dataPerformance metrics captured from real users, not lab tests. is determined by monitoring all users who visit a page and measuring a given set of performance metrics for each one of those users’ individual experiences.” Jump to quote
• “The Chrome User Experience Report, as its name suggests, is Chrome-only.” Jump to quote

CrUX access surfaces — cheat sheet

Where to get 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, and what each is good for — cadence and quotas below are current as of this writing; check the official docs before relying on them.

Fast facts

• Window: trailing 28 days, always — even for newly launched pages.
• Assessed at: p75 (75% of loads at/under the value), not an average.
• Lag: CrUX runs ~2 days behind; fixes generally register on the order of a month, but there’s no fixed 30-day guarantee — it depends on eligible traffic and the metric involved.
• Coverage: eligible Chrome experiences only (opt-in, synced, supported platform) — never every Chrome user, never every visitor. No iOS Chrome, no WebViews, no Edge / Safari / Firefox.
• No data? Cascade is URL-level → origin-level → lab-only (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.). A missing result means “not enough eligible sample,” not a zero or a pass. Page and origin eligibility are evaluated separately.
• Field vs lab: CrUX = field (real users, what Google rates). 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. = lab (one simulated load, for debugging).

CWV thresholds (at p75)

Tools for working with CrUX

• 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. (pagespeed.web.dev) — fastest per-URL field check; 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. on top, 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. lab below. Free, no key.
• 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. — 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. — site-wide CrUX assessment grouped by status, split Mobile/Desktop. The best view of where your real CWVGoogle'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. stand.
• CrUX Vis (cruxvis.withgoogle.com) — free visual trend tool over the History API; origin and URL level; up to 40 weeks. The replacement for the deprecated CrUX Dashboard.
• CrUX API (chromeuxreport.googleapis.com/v1/records:queryRecord) — current 28-day data programmatically; daily; needs a free Google Cloud API key for the “Chrome UX Report API.”
• CrUX History API (…:queryHistoryRecord) — weekly snapshots, up to 40 weeks, same auth and rate limits as the CrUX API.
• CrUX on BigQuery (chrome-ux-report dataset) — for at-scale research: origin-level, monthly (second Tuesday), country-level data, history to 2017; free tier.
• Chrome DevTools — Performance panelThe Performance panel is Chrome DevTools' built-in, local profiler for recording and analyzing how a page loads and runs — CPU, main-thread work, rendering, network, and live Core Web Vitals. The recorded trace is local, lab data from your own browser — not what Googlebot sees — though the panel can optionally show real-user CrUX field data alongside it. — surfaces CrUX field dataPerformance metrics captured from real users, not lab tests. alongside your local trace (added March 2025), so you can compare lab and field side by side.

Which CrUX surface should I use?

CrUX mistakes that lead to bad decisions

Treating an origin fallback as page-level evidence

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. can fall back from a URL to its origin when samples are thin. Read the displayed scope before claiming a specific page passes; use URL-level data when available and label origin data honestly when it is not.

Expecting a launch-day fix to rewrite a 28-day window

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. is a rolling field dataset, not a live deployment test. Use lab data or RUM for early diagnostics, then wait for new experiences to replace the old field window.

Calling Lighthouse a CrUX measurement

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. is one controlled lab run. CrUX aggregates eligible real Chrome visits. Use 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. to diagnose a likely cause, not to declare Google’s field assessment fixed.

Assuming CrUX represents every user

CrUX excludes Safari, Firefox, Edge, Chrome on iOS, WebViews, and Chrome users who do not meet eligibility rules. Compare it with first-party RUM when audience mix could make the Chrome sample unrepresentative.

PageSpeed Insights says there is no field data

Symptom: the field section is missing. Likely cause: neither the URL nor its origin meets 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. eligibility or sample requirements. Fix: confirm the public page returns 200 and is indexable, then use lab data or first-party RUM; traffic cannot be manufactured for CrUX. Recheck later if real usage grows.

The page looks good but the origin looks poor

Symptom: URL-level and origin-level results disagree. Likely cause: the origin aggregates many page types with different performance. Fix: preserve the scope in your report, inspect representative URLs from the slow templates, and avoid averaging the two records together.

Lighthouse passes while Search Console fails

Symptom: a controlled test is green but the CWVGoogle'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 not. Likely cause: real users have slower devices, networks, cache states, or interactions than the lab run. Fix: segment CrUX by device, compare field and lab metric by metric, and use the lab trace to reproduce the field bottleneck.

An API query returns not found

Symptom: a URL/form-factor query has no record. Likely cause: the narrower combination has too few eligible experiences. Fix: remove optional dimensions, try origin scope, and report the fallback explicitly rather than treating missing data as a passing result.

CrUX analysis checklist

• Record whether each value is URL-level or origin-level.
• Keep mobile and desktop/form-factor results separate.
• Confirm the window is the trailing 28 days and note the collection dates.
• Read p75 as a percentile of page loads, not an individual user’s score.
• Check whether 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. fell back from URL to origin.
• Treat missing data as insufficient coverage, never as a pass.
• Compare 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. separately; one passing metric does not make all pass.
• Use 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 DevTools for diagnosis, not as a substitute for field dataPerformance metrics captured from real users, not lab tests..
• Compare 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. with first-party RUM when non-Chrome users matter heavily.
• Allow the rolling window to turn over before judging a production fix in CrUX.

Scope, window, percentile, population

Every 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. number becomes easier to interpret when I label four things first:

1. Scope: is this the exact URL or the whole origin?
2. Window: which trailing 28-day period produced it?
3. Percentile: this is p75, not an average or one user’s visit.
4. Population: eligible Chrome users on supported platforms, not all traffic.

If a report omits any of those, the number is easy to overstate.

Verdict first, diagnosis second

CrUX answers what real eligible users experienced. A lab trace answers why a controlled load behaved that way. Start with the field verdict, choose the affected metric and scope, then use lab tooling to investigate. After shipping a fix, use the lab to confirm the mechanism immediately and CrUX to confirm the population-level outcome after the rolling window changes.

Ongoing CrUX KPIs

p75 LCP, INP, and CLS

Metric: each Core Web Vital at p75. What it tells you: the field experience Google uses for its CWVGoogle'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. assessment. How to pull it: 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. API, History API, CrUX Vis, or 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., with scope and form factor recorded. Benchmark / realistic range: use the published Good thresholds in this article; keep all three metrics separate. Cadence: weekly trends, with daily checks during a rollout.

Good-status coverage by template

Metric: share of important URL groups assessed Good in 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.. What it tells you: how broadly field performance is healthy across the site. How to pull it: mobile and desktop Core Web Vitals reportsThe 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. plus a template inventory. Benchmark / realistic range: establish a site baseline and prioritize valuable, high-traffic templates; sparse URLs may have no individual CrUX record. Cadence: weekly.

URL-level data availability

Metric: monitored priority URLs with their own CrUX record instead of an origin fallback. What it tells you: how much page-specific evidence your reporting can support. How to pull it: log API query success and PSI scope for the fixed URL set. Benchmark / realistic range: depends on eligible Chrome traffic; do not turn coverage into a target that encourages artificial traffic. Cadence: monthly.

Test yourself: Chrome UX Report

Five quick questions on 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. scope, coverage, and interpretation. Pick an answer for each, then check.

Resources worth your time

My related writing

• Core Web Vitals Data Study w/ CrUX & 5.2M Pages — my first-party study combining 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. with a 43.66M-page crawl; source of the ~11.9% coverage and origin-vs-page pass-rate figures.
• What Are Core Web Vitals — where CrUX fits, and my take on how much CWVGoogle'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. actually move rankings.
• Largest Contentful Paint (LCP) — the field-data framing for 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..
• Cumulative Layout Shift (CLS) — including why the 28-day window slows down visible improvement.
• PageSpeed Insights guide — the tool that surfaces CrUX field dataPerformance metrics captured from real users, not lab tests. per URL.

Official

• CrUX documentation (Chrome team) — the canonical reference for everything above.
• HTTP Archive CrUX report — ongoing public dashboards built on CrUX/BigQuery.

From others

• DebugBear — Chrome User Experience Report guide — thorough, developer-focused tool comparison.
• Lumar — SEO’s guide to site speed, CWV, Lighthouse & CrUX — strong SEO framing.
• SpeedCurve — When to use CrUX, RUM, and Synthetic monitoring — honest three-way comparison; calls out the Chrome-only / iOS blind spot clearly.
• GTmetrix — What is CrUX and Why Should I Care? — detailed eligibility breakdown and coverage limitations.

Stats worth citing

• Only ~11.9% of the 43.66M unique Site Audit pages in my January 2022 sample had at least one 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. 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. That was 5.21M pages; the rest had too little traffic to qualify. Source
• Origin pass rates outran page pass rates in that same Jan 2022 sample: ~33% vs ~21.2%. Domains passing CWV at the origin level ran well above the share of individual pages passing — origin averages fold in faster pages and cached repeat visits. A dated snapshot, not a current universal rate. Source
• Almost no sites on 3G or slower passed CWV, per that study. “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. threshold seems almost impossible to pass on slower connections.” Source
• Geography skewed results in that sample. The U.S. ranked 38th globally with a ~41% passing rate; device and network norms by country drove most of the spread. Source
• On the order of a month to see a fix fully register — the 28-day window plus CrUX’s ~2-day lag, though the exact timeline isn’t fixed and depends on eligible traffic and the metric involved. Source
• More than half of origins now pass 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.. As of the August 2024 CrUX milestone, Google reported that over 50% of origins in the dataset passed all three 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. — up significantly from the ~33% origin pass rate measured in earlier studies. Source
• CrUX covers over 15 million origins. As of 2024–2025, the dataset includes data from more than 15 million distinct origins, per the Chrome team’s methodology documentation. Source

CrUX

Chrome 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.

Related: Core Web Vitals, PageSpeed Insights, Lighthouse

CrUX

The Chrome UX Report (CrUX) is Google’s public dataset that reflects how real Chrome users experience popular sites. It’s the official source of field (real-world) data behind 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. program — the data Google uses to assess your 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. for Search, as opposed to the lab data a synthetic tool like 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. produces.

CrUX only collects from eligible Chrome users on supported platforms — those who enable usage-statistic reporting, sync their browser history, don’t have a Sync passphrase set, and use a supported platform (desktop and Android Chrome) — never every Chrome user, and never every visitor to a site. Chrome on iOS, Android WebViews, and other browsers like Edge, Safari, and Firefox are excluded. Page and origin eligibility are evaluated separately, and both also need enough samples — publicly discoverable and popular enough — to be included, so many low-traffic pages have no CrUX data at all; a missing result means there wasn’t enough eligible sample to report, not a zero or a pass.

Data is aggregated into a trailing 28-day window and reported at the 75th percentile (p75), available at both the origin (whole-domain) level and the individual URL level. You can access it through 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., the Search Console Core Web VitalsThe 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. report, the CrUX API (daily), the CrUX History API (weekly), and the BigQuery dataset (monthly) — check current docs, since cadence and quotas can change. The legacy CrUX Dashboard in Looker Studio was deprecated in November 2025; CrUX Vis is its replacement.

Related: Core Web Vitals, PageSpeed Insights, Lighthouse

Changelog