Lab data vs field data: why your speed scores disagree

Lab data is one simulated test run on a fixed device and a throttled connection; field data is what your real visitors actually experienced, aggregated from their own browsers. They disagree because your real visitors are not all on the test device - and the part that matters for ranking is the field data, because that is what Google ranks on.

This is the single most common reason two speed reports of the same page give you two different numbers. Once you know which is which, the disagreement stops being confusing and starts being useful: one tells you where the problem is, the other tells you whether real people feel it.

What lab data is

Lab data is a single test run in a controlled, simulated environment. A tool like Lighthouse loads your page once, on a fixed pretend device with a deliberately throttled connection, and measures what happened. Every run uses the same simulated phone and the same simulated network, so the conditions never change between tests.

That control is the whole point. Because the environment is held still, lab data is repeatable - run it twice and you get nearly the same answer, which is exactly what you need when you are changing one thing at a time and want to know whether the change helped. It is the diagnostic instrument: it isolates the page from the noise of the real world so you can see the page itself.

What it is not is real. Nobody actually visits your site on Lighthouse's standardised mid-range phone over its standardised slow-4G connection. The lab is a fair, fixed test bench - and like any test bench, the number it produces describes the bench, not the street. That is why a page can score well in the lab and still feel slow to half the people who load it, or score poorly in the lab and feel fine to most. The lab is a hypothesis about performance, not a measurement of it.

What field data is

Field data is the opposite trade. Instead of one controlled run, it is measurements collected from actual visitors' browsers as they load your page in real life, then aggregated. This is also called RUM - Real User Monitoring - because the monitoring happens on real users, not a test rig.

Google's public source for this is the Chrome User Experience Report, usually shortened to CrUX. Every Chrome user who has opted in quietly contributes timing data from the pages they visit, and Google aggregates it per site. When a tool shows you field data, it is almost always reading from CrUX. The window is the last 28 days of real visits, so the number moves as your actual traffic and your actual pages change - a fix you ship today shows up gradually as the 28-day window rolls forward, not instantly.

This is the data Google ranks on. The Core Web Vitals that feed the page-experience signals are measured from the field, from CrUX, from your real visitors - never from a lab run. If you want the short version of the mechanics, our short notes on lab data vs field data and what the Chrome UX Report is cover them in a paragraph each. The longer point stands: when you are asking "does my speed affect my ranking", the only data that answers it is the field data.

Why the two disagree

The gap between your lab score and your field score is not a bug in either tool. It is the two tools answering different questions, and four things drive most of the difference.

One device versus many. The lab uses a single fixed phone and a single fixed connection. Your real visitors are on flagship phones and five-year-old budget ones, on fibre and on patchy mobile coverage in a regional carpark. Field data is the blend of all of them. The lab's one device is a point; the field is the whole spread.

Cache. The lab loads your page cold, as a first-time visitor with nothing stored. Plenty of your real visitors arrive with your site already partly cached from a previous visit, so their load is faster than any cold lab run. Returning-visitor speed is invisible to the lab and baked into the field.

Geography and the rest of real life. The lab runs from one place. Your visitors load the page from wherever they are, on whatever else their phone is doing at the time - other tabs, a weak signal, a cheap CPU under load. All of that lands in the field number and none of it lands in the lab number.

The 75th percentile. This is the one that surprises people. Field metrics are not reported as an average - Google judges each Core Web Vital at the 75th percentile, meaning the experience is only counted as "good" if it was good for at least 75% of visits. So your field score is effectively the experience of your slower quarter of visitors, not your typical one. A page can have a fast median and still fail, because the bottom 25% - older phones, worse connections - drag the reported number down. The lab, testing one device, has no percentile at all.

Put those together and a lab score that looks healthy can sit next to a field score that does not, with neither tool wrong. They are measuring different populations on different terms.

Which one to trust for which job

The rule of thumb is short: diagnose with lab, judge with field.

Use lab data when you are working on the page. It is repeatable, it runs on demand, it does not need 28 days of traffic to produce a number, and it points straight at the slow resource - the oversized image, the render-blocking script, the slow server response. When you are testing whether a change helped, lab data gives you a clean before-and-after in minutes. This is the data you read line by line when you sit down to fix something; our guide to how to read a PageSpeed Insights report walks through the lab section in detail.

Use field data when you are deciding whether there is a problem worth fixing at all, and whether you have actually solved it for real people. It is the data that reflects your real audience, it is the data behind how page speed affects Google ranking, and it is the only one that tells you what Google sees. If the field numbers are green, the page is fine for ranking purposes even if a lab run looks imperfect. If the field numbers are red, you have a real problem regardless of how clean the lab looks.

The mistake to avoid is judging with the lab. A great Lighthouse score is a good sign your page can be fast; it is not proof that it is fast for the people loading it. Treat the lab as the workshop and the field as the verdict.

When this isn't enough

Knowing which number to trust does not, on its own, tell you whether speed is even your problem. It often isn't. Page speed is one input among many, and for a lot of small-business sites it is not the input holding the rankings back - content, links and basic indexability usually move the needle further. Whether the Core Web Vitals are worth your time at all depends on where you actually stand, which is the question our guide to whether Core Web Vitals affect your ranking is built to answer.

There is also a practical floor under the field data: a small site with low traffic may not have enough visits in CrUX to report a field score at all. When the field is blank, the lab is all you have - useful for diagnosis, but no longer a stand-in for what real users feel, because there is no field number to check it against yet. The technical detail of how the two data types differ is documented well by Chrome's CrUX overview and web.dev's lab and field data explainer if you want to go deeper.

The fastest way to find out where speed sits on your own list is to look at your whole posture at once rather than one metric in isolation. Run your domain through our scan and you will see how your site stacks up - speed included, alongside the security and email signals that more often turn out to be the thing actually costing you - against the Australian small-business baseline, so you can spend your time on the problem that matters instead of chasing a lab number nobody experiences.