Real user data versus lab tests: which numbers to trust
The difference between measurements from real visitors and from testing tools, what each is for, and which to trust.
The short answer
There are two kinds of performance numbers, and confusing them causes most arguments about whether a site is fast. Field data is what real visitors experienced: their browsers measure how long the main content took to appear, how quickly the page responded when they tapped, and how much the layout moved, and report it anonymously in aggregate. Lab data is what a testing tool measured when it loaded a page once under controlled, simulated conditions. Field data answers whether the site is fast for your audience, on their devices and connections, doing what they actually do, and it is what search engines use. Lab data answers why a page is slow and lets you test a fix before it ships. Trust the field for the verdict and the lab for the diagnosis. When they disagree, the field is right about what happened and the lab is missing something. Small sites often lack enough visits for public field reports, and real-user monitoring on the site itself fills that gap.
Field and lab side by side
| Aspect | Field data | Lab data |
|---|---|---|
| Source | Real visitors’ browsers, aggregated | A tool loading the page under simulation |
| Devices and connections | Your actual audience’s | One simulated profile |
| What is measured | Whole visits, including interaction and late-loading content | One load, usually without interaction |
| Repeatability | Statistical; changes as the audience changes | Repeatable, with run-to-run variation |
| Used for ranking | Yes | No |
| Tells you why | No; it tells you what | Yes; it lists causes |
| Available before launch | No | Yes, on previews |
| Available for small sites | Public datasets need volume; own monitoring works at any size | Always |
| Best use | The verdict; tracking real improvement | Diagnosis; testing fixes; preventing regressions in the pipeline |
Using both
- Set the targets in field terms: the thresholds visitors should experience on key pages.
- Read the field data in the search console and in real-user monitoring; find the pages and metrics that miss.
- Reproduce in the lab on those pages, with interaction where the field points at responsiveness.
- Fix, and verify the fix in the lab on a preview before shipping.
- Guard in the pipeline with lab budgets so the fix does not regress.
- Confirm in the field over the following weeks, since field data is assessed over a period.
- Repeat monthly, because audiences, devices and content change.
What to watch as a business owner
Field data on your key pages, over time: whether they pass the thresholds, and whether the share of visitors with a good experience is rising. Real-user monitoring by device and country, to see whether particular audiences are underserved. Lab budgets in the pipeline as the safety net. And a monthly note from your partner that connects the numbers to what changed.
What this means for you
Field data is what your visitors experienced and what search engines use; lab data is how you find out why and test fixes. Judge the site by the field, improve it with the lab, guard it in the pipeline, and confirm in the field again. If your site is too small for public field reports, add real-user monitoring so the verdict exists at all.
Frequently asked questions
Where does field data come from?
From real visitors' browsers, which measure loading, responsiveness and visual stability as pages are used and report them, anonymously and in aggregate, to public datasets and to any real-user monitoring the site runs. The search console shows the aggregate for your site's pages assessed over a recent period. It reflects your actual audience's devices, connections and behaviour.
Why does our lab score look fine while field data is poor?
Because the lab loaded one page once on a simulated device without interacting, and your visitors use many pages on their own devices and do things on them. Common causes: interaction delays from heavy scripts that the lab does not exercise, third-party tags that load late, slower devices than the lab simulates, pages other than the one tested, or layout shifts caused by content that loads after the lab stopped watching. The field is describing something the lab did not see.
Our site is small. Is there enough field data?
Public datasets need a minimum volume of visits per page or origin, and small sites often fall below it, which is why the search console may show nothing. The answer is real-user monitoring on the site itself: a tiny script reports the same metrics from every visitor to your own dashboard, so you have field data at any traffic level, broken down by page, device and country.
Sources
- web.dev: Why lab and field data can be different (and what to do about it) (accessed 2026-09-12)