Lab data and field data
🎯You'll be able to
Tell lab data from field data and choose which one answers a given question.
🏠The everyday picture
A car's mileage in a test lab differs from what you get in Pune traffic with the AC on. Both are useful: the lab for comparing changes, the road for knowing what really happens.
📘What it really is
-
Lab data: a test in controlled conditions, such as Lighthouse in Chrome DevTools or the lab section of PageSpeed Insights. Repeatable; good for testing a change before release. INP can't be measured fully in a lab without real interactions; lab tools show related measures such as Total Blocking Time.
-
Field data: measurements from real visits.
- Chrome UX Report (CrUX), shown in PageSpeed Insights and Search Console, gives 28-day field data for sites with enough traffic.
- Real user monitoring (RUM): your own collection, for example with the
web-vitalsJavaScript library sending values to your analytics, so you can split results by page, device or network. -
They often disagree: your test device and network differ from your users'. Trust field data for "how are we doing?" and lab data for "did this change help?".
-
Test like your users: throttle the CPU (4× slowdown) and network (slow 4G) in DevTools, or use a real mid-range Android phone.
📝A worked example
Kirana's lab and field results for the product page:
| Source | LCP | Notes |
|---|---|---|
| Lighthouse on the developer's laptop, no throttling | 1.2 s | Fast laptop, office Wi-Fi |
| Lighthouse with mobile throttling | 3.4 s | Closer to reality |
| CrUX field data (75th percentile) | 3.9 s | Real customers |
| RUM, split by device | 2.1 s on high-end phones, 4.6 s on low-end | Low-end phones are the problem |
The RUM split showed the fix must work on low-end phones, where most orders come from in the outer suburbs.
🌍Where it's used
- Before release: lab tests in the build pipeline catch regressions.
- After release: field data confirms real improvement.
- Prioritising: RUM splits show which pages and devices need attention.
📝Case scenario
A developer reports "LCP is 1.1 s, all good", but customers say pages are slow. The test was unthrottled on a laptop. Rerunning with mobile CPU and network throttling gives 3.6 s, and field data agrees. The team adds a throttled Lighthouse check to every pull request and a RUM dashboard split by device.
🖱️Try it
Add the web-vitals library to your Kirana app and log LCP, INP and CLS to the console (or a simple endpoint). Compare an unthrottled
and a throttled run, and note the difference.
⚠️Common mistakes
- Testing only on a fast laptop. Sign: everything looks quick to you but not to users on mid-range phones. Fix: throttle CPU and network in the lab, as the starter kit's performance test does.
- Expecting field data for a page with no visitors. Sign: an empty field report for a new page. Fix: use lab data until real visits build up, and say which one you used.
🛠️For your project
The starter kit's e2e/performance.spec.ts is lab data with fixed throttling; write down its settings in your Project 3 report.
✅Quick check
When should you trust field data over lab data?
Show the answer
For knowing how real users experience the site; lab data is better for testing whether a specific change helped.
Why throttle CPU and network when testing?
Show the answer
To get closer to the phones and networks real users have.