Frontend Beauty
ESC

Type to search the knowledge base.

Lab vs Field Data

Lighthouse lab vs CrUX/RUM field: what each is for, how they diverge, and how to use both.

intermediate3 min read
  • performance
  • lab
  • field
  • rum
  • core-web-vitals

Lab data is a controlled test (Lighthouse, WebPageTest, local Performance panel). Field data is real users (CrUX, your RUM). Shipping only for green Lighthouse while field INP burns is a classic failure mode.

Docs: web.dev lab vs field, CrUX, Core Web Vitals.

Comparison

Lab Field
Environment Fixed device/network simulation Real devices, networks, locales
Interactions Scripted or none Actual clicks/scrolls
Variance Low High (use percentiles)
Debug depth Excellent Attribution limited
SEO / CWV reporting Indirect CrUX feeds Search signals

Field is the source of truth for CWV

Google uses field metrics (CrUX) for experience signals. Good: p75 LCP ≤ 2.5s, INP ≤ 200ms, CLS ≤ 0.1. Lab helps you find why field is bad.

import { onLCP, onINP, onCLS } from 'web-vitals';
onLCP(send); onINP(send); onCLS(send);

Why they disagree

  1. Lab doesn’t perform the slow interaction INP cares about.
  2. Throttling models ≠ every 4G user.
  3. Auth, A/B, personalization change HTML in field.
  4. Third parties behave differently by geo.
  5. Sample bias (CrUX Chrome users only).
  6. Cached vs cold navigations mix in field.

How to use both

Field: which templates fail p75?
  → Lab: reproduce with throttle + Performance panel
    → Fix
      → Field: verify p75 moves over days/weeks

Don’t declare victory from one Lighthouse run on desktop.

Tooling map

Need Tool
Origin-level CWV CrUX / PSI field section
Page-level RUM web-vitals + analytics
Debug load Lighthouse, WPT
Debug interaction DevTools Performance + field attribution
Synthetic monitors Lab in CI for regressions

See RUM, Lighthouse interpretation.

Interview out-loud

“Field CWV is what users and Search see; lab is for debugging under controlled conditions. They diverge because of real devices, interactions, and third parties. I locate failures in RUM, reproduce in lab, confirm back in field.”

How this shows up in interviews

Be ready to define the metric or technique in one sentence, name one measurement approach (DevTools panel, web-vitals, or headers), and cite a concrete fix you would try first. Walk through a before/after: what the waterfall or flame chart showed, what you changed, and which percentile moved. Mention a tradeoff (complexity, caching correctness, or third-party business constraints) so the answer doesn’t sound like a blog checklist.

Production guardrails

Ship behind a flag when the change is risky, watch field p75 for the affected template for at least a few days, and keep a rollback path. Pair lab verification (throttled Performance/Network) with RUM so you don’t celebrate a Lighthouse-only win. Document the owner of any ongoing budget or third-party exception.

Further depth

Teams often under-invest in this topic until an incident or CWV regression. Schedule a one-hour drill: reproduce the failure mode in DevTools, list the top three mitigations for your stack, and file tickets with owners. Revisit after the next major feature that touches networking, rendering, auth, or third parties — those are the moments regressions land. Keep primary documentation links in the runbook so on-call is not searching chat history at 2am.

Concrete artifacts to leave behind: a short architecture note, a CI assertion or header snapshot, and a dashboard panel (lab or field) that would have caught the last bug. Teaching the rest of the team the mental model matters as much as the one-line fix.

Further reading

Related guides