The Chrome User Experience Report (CrUX) is a public resource from Google that provides real user measurements (RUM) for millions of sites. This data is referenced throughout many of their other products such as Page Speed Insights (and PSI API), Big Query and Google's Search Console. While the metrics from both LUX and CrUX are collected by the same methods, there are a few reasons why they *may not* match up exactly with one another.
CrUX data is only collected from Chrome Browsers
Your sample sizes are likely different
There are a number of reasons why your sample sizes may not match between LUX and CrUX. This doesn't necessarily point to issues with the data reported, but it's important to know that in order for Chrome to collect data from their end users, they must have:
- Opted-in to syncing their browsing history
- Have not set up a Sync passphrase
- Have usage statistic reporting enabled
On the LUX side, if you've set your sample rate too low this may also create some variance in the numbers reported. Here are some best practices for setting your LUX sample rate.
Depending on where you are comparing the data from, you may be looking at different data aggregation methods. Google is standardizing on the 75th percentile for Core Web Vitals. Our charts default to the median (50th percentile) and we encourage users to look at the 75th when setting performance budgets. Here is a great summary of data aggregation in SpeedCurve if you want to understand more about percentiles.
CrUX data available through Big Query is rolled up monthly (to the previous month). Page Speed Insights is based on the last 28 days. LUX time periods are configurable and may span as little as day up to the last 90 days.
There are a number of different dimensions provided by both CrUX and LUX. I won't list them all here (as they are likely to change and grow over time), but the thing to take into account is that you may be comparing substantially different cohorts.
CrUX does not segment by URL/path/page label*
When querying the public BigQuery data set, CrUX will segment a site by origin (i.e. https://www.speedcurve.com). LUX allows for further segmentation by page label, which provides a great deal of granularity, but may vary dramatically when compared to the entire set of urls from the origin.
(*note that the Page Speed Insights API *does* segment by url)
Cummulative Layout Shift (CLS) scores may be different
While metrics collected are based on the same browser APIs or pattern (i.e. FID), CLS is a cummulative measurement that changes during the page lifecycle. For LUX, the calculation of CLS stops when the beacon is fired. However, for CrUX the measurement continues until the visibility state changes to "hidden". This may lead to very different CLS numbers reported, especially if your application continues to see layout shift occur after the load event.
Summary & Recommendations
CrUX and LUX are a solid representation of reality. We love CrUX and the awesome data it provides site owners who are interested in improving UX. We are also very supportive of Google providing guidelines around metrics such as Core Web Vitals and encourage you to take those into consideration when setting performance budgets.
If you see numbers with a large amount of variance: Make sure you are segmenting your LUX data appropriately using the dimensions and data aggregation available to you.
If you see numbers that vary slightly: Relax. Don't over-think it. Focus on improving the UX and the number over time, just as you would with Lighthouse scoring or other metrics that may not "match" in other areas such as synthetic.