Skip to content

Field vs Lab: CrUX, RUM and Lighthouse

Field versus lab performance measurement is the distinction between synthetic tests, such as Lighthouse, and real-user datasets, such as CrUX and RUM. Lighthouse measures a controlled page load under selected conditions; CrUX aggregates Chrome users’ real experiences; RUM records your own users through instrumentation you ship with the site.

The problem is that web performance is not a single property of a page. It changes with device capability, network quality, location, cache state, browser behaviour, consent flows, ads, personalisation and user interaction. A lab run can make a page look worse or better than production, while field data can hide the exact cause. Engineers need both: one view for repeatable diagnosis, another for what users actually experienced.

Lighthouse works by loading a page in a controlled environment and applying a fixed set of audits and scoring rules. You can rerun it against the same URL while changing code and see whether a specific intervention helped. CrUX is collected from eligible Chrome users and aggregated by URL or origin over time. RUM is similar field measurement, but the site owner adds client-side instrumentation and sends measurements to their own analytics pipeline.

The trade-off is control versus representativeness. Lighthouse is reproducible and debuggable, but it is only a model of a visit. CrUX reflects real Chrome traffic, but it is aggregated, delayed and limited in the dimensions it exposes. RUM can segment by release, route, experiment, country, device class or logged-in state, but only if the instrumentation is correct and the measured traffic is representative.

In practice, engineers meet this split when a Lighthouse score and a CrUX report disagree. That does not usually mean one is broken. Use Lighthouse to reproduce a specific issue and validate an implementation change on a page. Use CrUX for external evidence of how Chrome users experienced a site over time, especially around Core Web Vitals. Use RUM when the decision depends on your own traffic segments or business-critical journeys.

Common questions

Why does Lighthouse fail when CrUX looks healthy?
Lighthouse may be testing a stricter scenario than most real visits: a slower simulated device, a cold cache, particular network settings or a clean browser profile. CrUX may look healthy because many users arrive with faster hardware, cached assets or different interaction patterns. The tools are sampling different conditions, not necessarily contradicting each other.
Why can CrUX fail when Lighthouse passes?
A clean Lighthouse run may miss production complexity. Real users can encounter consent banners, ads, third-party tags, personalisation, long-lived sessions, weaker devices or routes that the lab test did not exercise. CrUX captures those visits in aggregate, so it can reveal problems that are not visible in a single controlled page load.
Which source should I trust for an SEO performance decision?
It depends on the decision. For debugging and verifying a code change, trust Lighthouse because it is controlled and repeatable. For search-related page experience questions, CrUX is usually the closer match because it reflects real Chrome user experience over time. For release, segment or funnel decisions, prefer well-instrumented RUM.
Is RUM just a better version of CrUX?
No. RUM can be more detailed and faster for your own site because you control the instrumentation and dimensions. But it can also be biased by missing traffic, broken beacons, sampling choices or consent constraints. CrUX is less custom, but it is an external field dataset rather than your private analytics view.