Chrome UX Report (CrUX)
38 established claims - 2 refused by the grounding gate
Verdict
Chrome UX Report data is a 28-day rolling average of real-user metrics from Chrome users who have enabled usage statistic reporting, synced their browser history without a passphrase, and used a supported platform, and it is used by Google Search for page experience ranking. The CrUX API updates daily around 04:00 UTC with an approximate two-day lag, so a fix's impact begins to appear quickly rather than after 28 days; the reported metric values are 75th percentile, not averages. As of mid-2026, CrUX tracked 18.56 million origins with a 55.8% Core Web Vitals pass rate, but the dataset excludes Chrome on iOS, Android WebView, and other Chromium browsers, and it applies eligibility thresholds, random noise, and URL normalization that practitioners should understand when interpreting results.
Written from the 38 established claims below, then checked against them. How that works.
Documented position29
What the operator of the system says in its own documentation.
The CrUX History API documentation states that…
- each collection period contains the previous 28 days of aggregated data.
- the collection periods are per week.
- the collection periods overlap.
1 quote from 1 source
As each collection period contains the previous 28-days aggregated data, and the collection periods are per week, this means the collection periods will overlap. They are similar to a moving average of data, with three weeks worth of data being included in each subsequent period, and one week being different.
The CrUX API documentation states that the data in the Chrome UX Report is a 28-day rolling average of aggregated metrics.
1 quote from 1 source
The data in the Chrome UX Report is a 28-day rolling average of aggregated metrics. This means that the data presented in the Chrome UX Report at any given time is actually data for the past 28 days aggregated together.
The CrUX API documentation states that the CrUX API is approximately two days behind today's date because it waits for completed data for the day.
1 quote from 1 source
The CrUX API is approximately two days behind today's date since it waits for completed data for the day, and there is some processing time involved before it is available in the API.
The CrUX on BigQuery documentation states that the CrUX data on BigQuery is structured by monthly release.
1 quote from 1 source
The data is structured by monthly release, as well as a number of summary tables to provide quicker access for querying the data.
The CrUX API documentation states that the percentile values returned by the CrUX API…
- are synthetically derived.
- do not imply that any user actually experienced the value indicated.
1 quote from 1 source
Note: 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.
The CrUX API documentation states that…
- CrUX data is updated daily around 04:00 UTC.
- CrUX data is updated on a best-effort basis.
- there is no service level agreement for update times.
1 quote from 1 source
Data is updated daily around 04:00 UTC. There is no service level agreement for update times; it is run on a best-effort basis every day.
The CrUX methodology documentation states that Chrome on iOS, Android apps using WebView, and other Chromium browsers such as Microsoft Edge do not provide data to the CrUX dataset.
1 quote from 1 source
There are a few notable exceptions that don't provide data to the CrUX dataset: Chrome on iOS. Android apps using WebView. Other Chromium browsers (for example Microsoft Edge).
The CrUX methodology documentation states that Chrome does not publish data about the proportions of users that meet the CrUX user eligibility criteria.
1 quote from 1 source
Chrome does not publish data about the proportions of users that meet these criteria.
For a user's experiences to be aggregated in the CrUX dataset, the user must…
- enable usage statistic reporting.
- sync their browser history.
- not have a Sync passphrase set.
- use a supported platform.
1 quote from 1 source
For a user to have their experiences aggregated in the CrUX dataset, they must meet the following criteria: Enable usage statistic reporting. Sync their browser history. Not have a Sync passphrase set. Use a supported platform.
The CrUX methodology documentation states that the exact minimum number of visitors required for a page or origin to be considered sufficiently popular is not disclosed.
1 quote from 1 source
An exact number is not disclosed, but it has been chosen to ensure that we have enough samples to be confident in the statistical distributions for included pages. The minimum number is the same for pages and origins.
The CrUX methodology documentation states that…
- a page must be publicly discoverable to be considered for inclusion in the CrUX dataset.
- the same indexability criteria as search engines are used for public discoverability.
1 quote from 1 source
A page must be publicly discoverable to be considered for inclusion in the CrUX dataset. A page is determined to be publicly discoverable using the same indexability criteria as search engines.
The CrUX methodology documentation states that a small amount of randomness is applied to the dataset to prevent reverse-engineering of sensitive data such as total traffic volumes.
1 quote from 1 source
A small amount of randomness is applied to the dataset to prevent reverse-engineering of sensitive data, such as total traffic volumes. This does not affect the accuracy of aggregate statistics.
The CrUX methodology documentation states that…
- query string parameters and fragments are stripped from the URL in the CrUX dataset.
- the stripping of query string parameters and fragments from the URL in the CrUX dataset is done so that all user experiences on the page are aggregated together.
1 quote from 1 source
Pages commonly have additional identifiers in their URL including query string parameters like ?utm_medium=email and fragments like #main. These identifiers are stripped from the URL in the CrUX dataset so that all user experiences on the page are aggregated together.
The CrUX methodology documentation states that pages included as iframes…
- are not reported on separately in CrUX.
- contribute to the metrics of the top-level page.
1 quote from 1 source
Pages in CrUX are measured based on the top-level page. Pages included as iframes are not reported on separately in CrUX, but do contribute to the metrics of the top-level page.
The CrUX methodology documentation states that route transitions appear as new page views to the user.
1 quote from 1 source
These transitions appear as new page views to the user, but to Chrome and the underlying platform APIs the entire experience is attributed to the initial page view. This is a limitation of the web platform APIs on which CrUX is built
The CrUX methodology documentation states that origins or pages having more than 20% of their total traffic excluded due to ineligible combinations of dimensions are excluded entirely from the dataset.
1 quote from 1 source
Origins or pages having more than 20% of their total traffic excluded due to ineligible combinations of dimensions are excluded entirely from the dataset.
The Chrome for Developers "Overview of CrUX" page states that the Chrome User Experience Report is a dataset that reflects how real-world Chrome users experience popular destinations on the web.
1 quote from 1 source
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.
The Chrome for Developers 'Overview of CrUX' page states that data collected by CrUX is used by Google Search to inform the page experience ranking factor.
1 quote from 1 source
The data collected by CrUX is available publicly through a number of Google tools and third-party tools and is used by Google Search to inform the page experience ranking factor.
Practical effect3
What is observed to happen in practice, as distinct from what is documented.
- CrUX API and PageSpeed Insights are updated daily with roughly a two-day lag.
- CrUX History API is updated weekly on Mondays.
- CrUX BigQuery is updated monthly.
1 quote from 1 source
CrUX API and PageSpeed Insights: updated daily (~2-day lag). This is what most people use. CrUX History API: updated weekly on Mondays, with data through the previous Saturday. Powers the CrUX History tool and trend charts. CrUX BigQuery: updated monthly, on the second Tuesday after the collection period ends.
Echoed without a primary source6
Widely repeated in the field, but traceable only to other repetitions. Listed because knowing something is merely echoed is worth as much as knowing it is documented.
- A corewebvitals.io article states, regarding Chrome UX Report (CrUX), that the belief that a site must wait 28 days after deploying a fix to see whether it worked is wrong.
- A corewebvitals.io article states that Chrome UX Report (CrUX) data is about two days old rather than 28 days old.
2 quotes from 1 source
The CrUX data is two days old, not 28. Here is what the 28-day rolling window actually means.
I hear it all the time: "We deployed the fix, now we have to wait 28 days to see if it worked." This is wrong. The data is not 28 days old. It is about two days old.
A corewebvitals.io article states that…
- several popular guides, including Vercel's, incorrectly describe the CrUX figure as an average.
- the CrUX figure is a 75th percentile.
1 quote from 1 source
One thing many people get wrong: this is a 75th percentile, not an average. Several popular guides (including Vercel's) incorrectly call it an average.
A corewebvitals.io article states that CrUX…
- currently tracks 18.56 million origins.
- has a 55.8% Core Web Vitals pass rate.
1 quote from 1 source
CrUX currently tracks 18.56 million origins with a 55.8% Core Web Vitals pass rate.
Refused2
Claims the research produced that the grounding gate would not accept, with its reason. They are here because a site that only shows what passed gives you no way to judge whether the gate does anything.
Show what was refused
Chrome UX Report (CrUX) is described in Google's page-experience documentation as having no single page experience signal that Google Search uses for ranking.
Refused: The quote says there is no single page experience signal, but it does not mention or describe Chrome UX Report (CrUX) at all.
Unsupported: Chrome UX Report (CrUX)
What it rested on
Is there a single "page experience signal" that Google Search uses for ranking? There is no single signal. Our core ranking systems look at a variety of signals that align with overall page experience.
The CrUX methodology documentation states that for single page apps, the entire experience is attributed to the initial page view by Chrome and the underlying platform APIs.
Refused: The quote states the experience is attributed to the initial page view but does not specify it is for single page apps.
Unsupported: for single page apps
What it rested on
These transitions appear as new page views to the user, but to Chrome and the underlying platform APIs the entire experience is attributed to the initial page view. This is a limitation of the web platform APIs on which CrUX is built