Two field-data sources with the same goal, different answers

The Chrome User Experience Report (CrUX) and Real User Monitoring (RUM) both measure how real users experience a site. CrUX is collected automatically from opted-in Chrome users and published publicly for sites that meet its eligibility criteria. RUM requires embedding code on your pages to send data back to your own analytics or monitoring tool.

Because both measure the same Core Web Vitals in the field, it’s tempting to expect identical numbers. They won’t always match, and the reason isn’t necessarily a bug. This article explains why the two datasets diverge and how to handle the differences.

Why use both?

CrUX offers a consistent, public baseline across millions of sites, making it useful for competitive benchmarking. It’s the dataset behind the Core Web Vitals program, so you’ll want to watch what it reports.

But CrUX deliberately keeps its data coarse to remain publicly queryable. When you need to know why a metric looks bad, a RUM solution provides the additional detail required for investigation. RUM isn’t a replacement — it’s a supplement that can help explain CrUX numbers and guide your fixes.

Drill down to diagnose issues

CrUX can flag that a problem exists but often can’t tell you where it is or why. RUM tools, whether built in-house with the web-vitals library or purchased commercially, give you fine-grained visibility across all your pages and all browsers.

With RUM you can segment data by user cohort or action, and inspect exactly when a regression began. These are questions CrUX alone can’t answer, because it lacks the granularity needed for deep investigation.

Connect performance to business outcomes

RUM lets you correlate performance metrics with your own business data, which can demonstrate the value of performance investment and help decide what to prioritize. Case studies from sites like Farfetch and The Economic Times show how this correlation plays out in practice.

Track site-specific custom metrics

Beyond Core Web Vitals, a RUM implementation allows custom metrics tailored to your product. Twitter’s “Time to first Tweet” metric is a well-known example. These can be tracked alongside vital improvements to see the full impact of your changes.

Why Two Sets of Field Data Rarely Agree

Comparing your own Real User Monitoring (RUM) data against the Chrome User Experience Report (CrUX) often surfaces discrepancies that are easy to misread as bugs. In a perfect world, two sources measuring the same field performance would return identical numbers. In practice, the differences come down to who is measured, what is measured, and how the numbers are aggregated.

Know Which Population Is in the Sample

The most fundamental gap is the population of page views each system captures. CrUX is, by name, limited to Chrome. It excludes Chromium-based browsers such as Edge and Opera, excludes Chrome on iOS (which runs on WebKit), and excludes Android WebViews—though Chrome Custom Tabs are included. RUM tools typically capture all browsers, which matters when a site's audience skews toward Safari or Firefox.

Browser coverage is not just a question of volume. It affects the distribution of device capability and network quality. iOS users tend to be on more performant hardware and better networks; excluding them, as CrUX does, can tilt results toward the slower end of your visitor base. Meanwhile, non-Chromium browsers may not support the same metrics at all—CLS is only available in Chromium-based engines, and paint-based metrics like LCP, INP, and FCP are implemented differently in Safari and Firefox.

Beyond the browser itself, CrUX only reports on Chrome users who have opted into data sharing. RUM providers have their own opt-in friction: cookie banners and tracking blockers. When consent is granted only after the first page load, the slower initial visit may be omitted entirely, making RUM numbers look rosier than the true experience.

CrUX also applies eligibility criteria at the site and URL level. A site must be public and sufficiently popular to reach a minimum sample size; specific pages may be excluded if they are not indexable. RUM, by contrast, typically reports on whatever URLs you instrument.

Finally, consider sampling. RUM products often let you tune the sampling rate to control cost and volume. If that sample is too small or skewed, the resulting metrics will drift from CrUX, which draws from a much larger opted-in population.

Aggregation Methods Change the Answer

Even with identical inputs, two systems can report different values simply by aggregating differently. CrUX always reports a 28-day sliding window—the timeframe cannot be changed, though the CrUX BigQuery and History API data can show historical months built from that same window. RUM tools usually offer finer granularity so you can see the impact of a deploy within days, but short windows are noisy.

The statistical summary matters just as much. CrUX reports metrics at the 75th percentile—the value that 75% of page views fell at or under. Some RUM products default to the median or offer a range of percentiles. Comparing a CrUX p75 number to a RUM median will always show a gap. Make sure both sources are set to the same percentile over the same 28-day period before drawing conclusions.

Metric Definitions and Timing Subtleties

Core Web Vitals are named the same across tools, but the measurement boundaries drift. LCP is a page-load metric, but the browser API can report a candidate element before the page finishes loading or the user interacts. In field data, the LCP element itself can change depending on how the page is opened—a deep link or an anchor further down the document can yield a different largest element than a top-of-page load.

CLS and INP are measured across the full life of the page, including after user interaction. Many RUM products capture these values at page load or stop measuring at some other arbitrary point, which produces lower (better-looking) numbers than CrUX, which follows the full lifetime of the page per the Core Web Vitals documentation. Ask your RUM vendor exactly when each metric is finalized; the answer explains many unexplained variances.

Single-Page Applications Create a Blind Spot

SPAs update content in place rather than triggering browser-level navigations. The standard Core Web Vitals APIs do not account for these "soft navigations," so CrUX does not report on them either. If your RUM provider fabricates its own soft navigation events and attributes Core Web Vitals metrics to them, those numbers simply will not align with CrUX, which relies on the underlying browser APIs.

Technical Gaps Between CrUX and Web APIs

Beyond sampling and definitions, there are hard technical limits to what JavaScript-based RUM can observe. CrUX, measured inside the Chrome browser, has access to data that web APIs deliberately hide.

Back/forward cache. CrUX counts bfcache restores as page navigations. The Web APIs do not fire a page load for them, so RUM tools must take extra steps to capture these much faster visits. If they do not, the RUM data will look worse than CrUX because the quick restores are missing.

Iframes. Top-level pages cannot read performance data from iframes—even same-origin ones. When an iframe contains the LCP element or contributes to CLS or INP, standard RUM JavaScript cannot see it. CrUX can, because it reads the browser's internal data. A common example is embedded <video> from a streaming service: the first painted frame of an autoplaying video can be the LCP candidate, but if that video lives in an iframe, only CrUX will see it.

Cross-origin resources. The PerformanceObserver API may not report the render time for LCP media served from another origin unless the Timing-Allow-Origin header is present. Without TAO, the API falls back to the resource's load time, which can be earlier than the actual paint—occasionally producing the seemingly impossible result of LCP appearing before FCP. A fix went into Chrome 133 that provides a coarsened render time even without TAO. CrUX has always reported the corrected render time data.

Background tabs. Pages in background tabs still emit Web API metrics, but those timing values do not reflect the user experience. CrUX excludes them; RUM products should either discard them or document how they are handled.

When you see a gap between your RUM dashboard and CrUX, work through each of these layers: audience, consent, sampling, aggregation window, percentile, metric timing, and API limits. The answer is rarely a single bug—it is usually a combination of these structural differences.

Making sense of the gap

Methodology and audience differences explain why CrUX and RUM rarely report identical numbers. In most cases both datasets remain valid, and a slight discrepancy—say a 2.0-second LCP in one tool versus 2.2 seconds in the other—means the two are effectively in sync and both are useful.

When the gap is large enough to cast doubt on accuracy, the first step is to investigate. Try filtering your RUM data to mirror CrUX's scope: Chrome-only users, a single device class, 75th percentile values, and a 28-day window. If the numbers then converge, the remaining question is what the original divergence tells you. Do non-Chrome users pull your metrics up or down? Does that signal a performance problem you had not prioritized?

Turning differences into insights

A meaningful distinction between Chrome and non-Chrome experiences is itself a finding. RUM can surface where certain APIs are unsupported in other browsers, prompting you to ship fallbacks or a lighter, alternative experience for users on constrained devices or networks. CrUX is limited to Chrome traffic, but your optimization priorities should reflect every visitor. RUM fills that coverage gap.

Once the sources of divergence are understood, the two tools complement each other. CrUX offers a high-level view of your site's performance over a rolling month; RUM lets you segment that view to identify whether specific pages, devices, or user groups need attention. Tracking trends over time is generally more valuable than forcing both datasets to match exactly. RUM's flexibility with shorter reporting windows can also give an early signal of what the next 28-day CrUX scores will show—though too short a window introduces noise, which is why CrUX uses a month in the first place.

Neither metric set is inherently "right" or "wrong." They are different lenses on the same user experience. Understanding why they diverge, and using that understanding to drive decisions, matters more than reconciling the numbers precisely.