Chrome UX Report (CrUX)

TL;DR — CrUX is Google’s collection of real-world speed data from actual Chrome users. It’s the data Google uses to judge your Core Web Vitals — not the lab score a tool like Lighthouse generates on a single test machine. That’s why your Lighthouse score can be green while Search Console 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 data (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 Vitals program. Google’s ranking systems use the Core Web Vitals 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 Insights is CrUX. The Search Console Core Web Vitals report 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 — CrUX 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 Vitals 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 Insights, Search Console, 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; Lighthouse 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 Vitals metrics are represented.” The data is “used by Google Search to inform the page experience ranking factor.”

So the mental model is: Core Web Vitals 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 redirects) 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 Insights: URL-level CrUX → if insufficient, fall back to origin-level CrUX → if that’s also missing, you get no field data and only the Lighthouse 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 found’ 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.

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 Console 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, WebPageTest, 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 Paint (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 FCP (First Contentful Paint), experimental TTFB, 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 report 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:

• CrUX = field data, and it’s the dataset behind Core Web Vitals. When Google assesses your CWV for Search, it reads CrUX — not a Lighthouse 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 Vitals 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 found ~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 Lighthouse (single clean lab load) disagrees with CrUX (messy real users). PSI 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 Console (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 CrUX documentation from the Chrome team on developer.chrome.com.

• CrUX overview — what CrUX is, its role in the Web Vitals program, and how Search uses it.
• CrUX methodology — the four user eligibility criteria, supported/excluded platforms, the 20% rule, URL stripping, and SPA/iframe 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 FID→INP 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 CrUX 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 Vitals program. All user-centric Core Web Vitals 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 data 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 CrUX 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 (Lighthouse). 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). Lighthouse = lab (one simulated load, for debugging).

CWV thresholds (at p75)

Tools for working with CrUX

• PageSpeed Insights (pagespeed.web.dev) — fastest per-URL field check; CrUX on top, Lighthouse lab below. Free, no key.
• Search Console — Core Web Vitals report — site-wide CrUX assessment grouped by status, split Mobile/Desktop. The best view of where your real CWV 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 panel — surfaces CrUX field data 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 Insights 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

CrUX 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

Lighthouse is one controlled lab run. CrUX aggregates eligible real Chrome visits. Use Lighthouse 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 CrUX 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 CWV 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 Insights fell back from URL to origin.
• Treat missing data as insufficient coverage, never as a pass.
• Compare LCP, INP, and CLS separately; one passing metric does not make all pass.
• Use Lighthouse or DevTools for diagnosis, not as a substitute for field data.
• Compare CrUX 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 CrUX 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 CWV assessment. How to pull it: CrUX API, History API, CrUX Vis, or PageSpeed Insights, 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 Console. What it tells you: how broadly field performance is healthy across the site. How to pull it: mobile and desktop Core Web Vitals reports 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 CrUX 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 CrUX 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 CWV actually move rankings.
• Largest Contentful Paint (LCP) — the field-data framing for LCP.
• Cumulative Layout Shift (CLS) — including why the 28-day window slows down visible improvement.
• PageSpeed Insights guide — the tool that surfaces CrUX field data 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 CrUX Core Web Vitals 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 LCP 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 Vitals. As of the August 2024 CrUX milestone, Google reported that over 50% of origins in the dataset passed all three Core Web Vitals — 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 Vitals program — the data Google uses to assess your Core Web Vitals for Search, as opposed to the lab data a synthetic tool like Lighthouse 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 Insights, the Search Console Core Web Vitals 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