Lesson 4 of 30

Lab Data vs. Field Data

Q: Your Lighthouse score in CI is consistently 95+, but you're getting reports that the site feels slow for real users, and Search Console shows the page failing its Core Web Vitals assessment. How do you explain this to your team, and what would you do next?

A strong answer covers: Clearly distinguishes lab data (synthetic, single simulated condition, reproducible) from field data (real user devices/networks/geography, what CrUX/RUM capture); States that Google's Core Web Vitals ranking signal is based on field data, not lab scores, which is why the two can disagree; Proposes a concrete next step — checking PageSpeed Insights' field data section, or setting up RUM, to see the real distribution of user experience rather than trusting the lab number alone; Can articulate at least one realistic reason lab and field would diverge (e.g. a third-party script or device/network variance that the lab's single simulated condition doesn't capture).

A page that lab-tests fast can still be genuinely slow for real users. Knowing which kind of data you're looking at, and what each one is actually for, is what keeps you from chasing the wrong number.

12 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

Question 1 of 3

A page scores 100 on Lighthouse but fails Google's Core Web Vitals ranking signal in Search Console. What's the most likely explanation?

The ranking signal is based on field data (CrUX), and real users' varied conditions can differ meaningfully from Lighthouse's single simulated runLighthouse scores are unrelated to Core Web Vitals and measure something else entirelyA score of 100 always guarantees the ranking signal passes; something else in the account must be misconfigured

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on Lab Data vs. Field Data

What interviewers actually ask about this, and what a strong answer has to cover.

Your Lighthouse score in CI is consistently 95+, but you're getting reports that the site feels slow for real users, and Search Console shows the page failing its Core Web Vitals assessment. How do you explain this to your team, and what would you do next?

A strong answer covers

Clearly distinguishes lab data (synthetic, single simulated condition, reproducible) from field data (real user devices/networks/geography, what CrUX/RUM capture)
States that Google's Core Web Vitals ranking signal is based on field data, not lab scores, which is why the two can disagree
Proposes a concrete next step — checking PageSpeed Insights' field data section, or setting up RUM, to see the real distribution of user experience rather than trusting the lab number alone
Can articulate at least one realistic reason lab and field would diverge (e.g. a third-party script or device/network variance that the lab's single simulated condition doesn't capture)

Likely follow-ups

If a page has too little traffic to appear in CrUX, what data would you rely on instead to understand real-user experience?
Is it ever correct to treat a lab regression in CI as a blocking failure even if you don't yet have field data confirming it matters? Why or why not?

The plain-language idea

Performance numbers come from two fundamentally different sources, and mixing them up leads to real mistakes:

Lab data — a synthetic measurement: one simulated device, one simulated network condition, run once, fully reproducible. Lighthouse, WebPageTest, and a local Chrome DevTools run are all lab data. Its strength is reproducibility: run it twice under the same conditions and you get the same answer, which makes it excellent for catching a regression in a pull request before it ships.
Field data — real users' actual measured experience: real device diversity (a five-year-old Android phone next to a new iPhone), real network conditions (a train tunnel next to fiber), real geographic spread. The Chrome UX Report (CrUX) aggregates this from real Chrome users across the web, and any Real User Monitoring (RUM) you set up yourself collects the same kind of data specifically for your own site.

The core diagnostic principle: lab data is for catching regressions before they ship. Field data is for knowing what real users are actually experiencing right now. They answer different questions, and a page can score well on one while scoring poorly on the other.

See it in a real thing: a third-party script that only misbehaves in the field

Imagine a page with a third-party chat widget script. In Lighthouse, run on a fast lab machine with a fast simulated connection, the widget loads and settles well within the layout before the test finishes measuring — CLS comes back clean. In the field, a meaningful share of real visitors are on slower phones and slower connections, where the same script takes long enough to load that it inserts itself into the page after users have already started reading — causing a real, measured layout shift that never showed up in the lab.

This is not a hypothetical edge case — it's the single most common reason "Lighthouse says 100 but CrUX says this page fails Core Web Vitals" happens in practice. The lab run's one simulated condition simply didn't reproduce the range of real conditions the field data captures.

What people usually miss

Watch out

Google's search ranking signal uses field data (CrUX), not lab scores. A page can have a perfect Lighthouse performance score and still fail the Core Web Vitals ranking signal if real users' field experience is worse than the lab run suggests.
A URL needs enough real Chrome traffic to appear in CrUX at all — a brand-new page or a low-traffic page may simply have no field data yet, in which case lab data (or your own RUM, if you have it configured) is the only signal available.
Lab data's reproducibility is a feature for one job and a limitation for another. It's exactly what you want for a CI regression check ("did this PR make LCP worse under identical conditions"), but it's the wrong tool for answering "what are our real users actually experiencing," since it only ever tests one condition.
RUM and CrUX aren't the same thing. CrUX is Google's own aggregate, covering only Chrome users and a limited set of metrics; RUM is data you collect yourself, which can cover every browser your real users actually use and any metric you choose to instrument.

Why this matters in interviews

"Our Lighthouse score is 95 but users are complaining the site feels slow — what's going on?" is a direct test of whether a candidate understands lab and field data are different things measuring different conditions, not two versions of the same number.