What is the Chrome UX Report (CrUX), where does its data come from, and what are its limits as a source of field performance data for a site you own?

## What CrUX is The Chrome UX Report is a public dataset of how real people experienced real web pages. It is field data — collected in real browsers during real visits — but you do not have to instrument anything to get it, because the browser itself contributes the measurements. That property makes it unusual and useful. It is the only field data you can read for a site you do not control, which is why competitor comparisons, industry benchmarks and third-party performance reports are almost always built on it, and it is the dataset behind the Core Web Vitals assessments surfaced in PageSpeed Insights and in Search Console's Core Web Vitals report. ## Where the data comes from The population is Chrome users who have opted into usage statistic reporting and meet Chrome's eligibility conditions. Their navigations to publicly reachable pages contribute metric samples, which are aggregated before publication. Three consequences follow directly from that sourcing: - **Browser coverage is partial.** Chrome on desktop and Android contributes; Safari, Firefox and browsers on iOS do not. If a large share of your audience is on iPhones, a substantial part of your traffic is invisible in CrUX. - **It is opt-in, not census.** The contributing users are a subset of Chrome users, so the dataset is a sample, not every visit. - **Only public pages appear.** Pages behind authentication, internal tools and URLs that are not publicly reachable are excluded, so an application whose interesting pages sit behind a login gets little or nothing. ## How it is shaped CrUX publishes aggregates rather than individual page views: - A **rolling 28-day window**, so any single reading blends four weeks of sessions. - **Per origin**, always if the origin qualifies, and **per URL** for pages with enough eligible samples. - A **distribution** across the good / needs-improvement / poor buckets for each metric, plus the 75th percentile value. - Sliced by a small set of dimensions such as **form factor** (phone, desktop, tablet) and connection type. It is exposed through several front doors: an API for current data, a history endpoint for weekly trends, a monthly BigQuery dataset for large-scale analysis, and the reports built on top of them. ## The limits that bite in practice **No attribution.** This is the big one. CrUX tells you the 75th-percentile LCP for phone users on a URL. It does not tell you which element was the LCP candidate, when it was discovered, what blocked it, which script produced the long task behind a bad INP, or which component shifted. Diagnosis needs your own instrumentation or a lab reproduction. **Lag.** With a 28-day rolling window, a fix that lands today is one day out of twenty-eight in tomorrow's reading. Teams routinely panic that a fix "did nothing" a few days after deploying it. The history endpoint's weekly series makes the trend clearer, but the lag is real and you should plan verification around it, not against it. **Coverage thresholds.** A URL needs enough eligible samples to be published on its own. Below that threshold you fall back to origin-level data, which pools every page on the site — so a fast landing page can inherit the reputation of a slow section, and a fix to one template can be invisible in the pooled number. **Coarse dimensions.** You cannot slice by page template, logged-in state, A/B variant, deploy, or your own customer segments. Those are exactly the cuts that turn a number into an action, and they are only available in RUM you collect yourself. **Population skew.** Because the sample is Chrome-only and opt-in, comparing CrUX against your own RUM will show differences that are sourcing artefacts, not regressions. Expect the two to disagree in level while agreeing in direction. ## How to use it well Treat CrUX as the external scorecard and the sanity check. It answers "do real users pass, per the same yardstick everyone else is judged by, and how do we compare with peers?" — and it costs nothing to obtain. Then run your own RUM as the operational instrument: same metrics, but sliced by template, release, cohort and whatever else your product needs, with enough attached context to start a diagnosis. Use lab runs to explain what either one reports. A team that only watches CrUX will know it has a problem about three weeks late and will not know why.