RUM vs. CrUX: Using Field Data Right for Speed

Web performance can be measured from three fundamentally different angles, and each answers a different question. Lab data (synthetic tests like Lighthouse) loads a page in a controlled environment with a fixed device, fixed network connection and fixed location (Source: web.dev). Field data from CrUX reflects how real Chrome users actually experience a website - with the full range of devices, networks and behaviors (Source: web.dev). Your own real-user monitoring (RUM) collects the same kind of field data via a script on your own website, but across all browsers and with far more detail (Source: DebugBear).

The decisive point for ranking: Google uses CrUX field data to evaluate Core Web Vitals, not the lab score. A synthetic test like Lighthouse can explain why a page is slow but does not measure the Core Web Vitals that feed into ranking (Source: DebugBear). This implies a clear division of labour: CrUX shows whether a problem exists and whether Google sees it. RUM shows what causes it and which elements or scripts are responsible. Lab tests serve fast diagnosis and regression hunting in the build before changes even go live.

This separation explains why isolated Lighthouse optimization can come to nothing. Developers typically work with first-class internet connections on modern devices, while real users are often on older smartphones with fluctuating mobile connections (Source: web.dev). Anyone who optimizes only the lab optimizes for a scenario that barely appears in the ranking-relevant field data. A well-considered Core Web Vitals optimization therefore starts from the field and uses the lab as a tool, not as a goal.

Two properties of the CrUX dataset are especially important in practice because they govern whether a page passes the Core Web Vitals. The first is the 75th percentile. Google does not evaluate a page on the average but on the value that 75 percent of user experiences reach or beat (Source: Google web.dev). Put concretely: if 100 people visit your page, the LCP must be 2.5 seconds or below for 75 of them for the value to count as good. The percentile is deliberately strict - it protects the evaluation against a few very fast visits masking a slow majority.

The second property is the rolling 28-day window. CrUX aggregates the values over the past 28 days and moves the window forward by one day each day: the oldest day drops out, the newest is added (Source: Chrome UX Report). This window smooths noise and daily fluctuation but has a direct consequence for the work - improvements become fully visible only after a few weeks, because they have to work their way through the entire window. A fix that goes live today typically shows its full effect in the field only four weeks later.

From this delay follows an important way of working: while waiting for field confirmation, you check the effect in your own RUM, which delivers in real time (Source: DebugBear). This keeps you able to act without waiting 28 days blindly. Your own RUM thereby becomes an early indicator for the CrUX movement that follows later. This combination of fast RUM feedback and slow but ranking-relevant CrUX confirmation is the core of a professional measurement strategy.

A performance budget defines an upper limit a metric must not exceed - and the decisive step for data-driven speed is to set this budget at the 75th percentile of field data, not at the lab value. Concretely, this means: the budget is held when the LCP stays under 2.5 seconds for 75 percent of real users, the INP under 200 milliseconds and the CLS under 0.1. These thresholds correspond to the values Google defines as good and are therefore directly ranking-relevant.

The advantage of a field-based budget is its honesty. A budget at the lab value can show green while a quarter of real users experience a markedly slower page - and it is exactly this quarter that decides the evaluation. The example shown in the mockup illustrates this: an LCP of 1.9 seconds in the lab looks clean, yet the field percentile of 3.1 seconds breaks the budget. Only a budget that checks at the 75th percentile catches this discrepancy.

What matters is the distribution of roles in the budget process: the field defines the target, the lab watches over regressions. A lab test in the build cannot predict the exact 75th-percentile field result, but it reliably detects when a new script bloats the bundle or a delayed hero image worsens the LCP. How to build JavaScript budgets into the build concretely is explored in our article on JavaScript and performance budgets.

The economic lever lies in clarity about the right data source. Anyone who pours budget into optimizations that only lift the lab score invests in the wrong goal - the field data, and thus the ranking, barely move. Conversely, an optimization that improves the 75th percentile in the field delivers both better Core Web Vitals and a noticeably faster experience for real users on real devices. Data-driven speed means recognizing and prioritizing exactly these effective measures.

In practice this means: CrUX as the truth for ranking, your own RUM as a fast diagnostic and early-warning system, lab tests as a regression guard in the build - and above all a performance budget at the 75th percentile that applies to every change. This turns diffuse gut feeling into a provable strategy that backs every improvement with numbers from the field. This exact approach forms the core of our web performance services that measures and prioritizes first instead of blindly turning knobs.