A lab test loads your page once, on one simulated device and connection, in a controlled environment. Field data is a record of what real visitors on real devices actually experienced over the preceding weeks. They frequently disagree, and when they do, the field data is the one describing your customers.
Two different questions
The confusion comes from treating both as answers to "is my site fast", when they answer different questions entirely.
A lab test answers: under these specific conditions, how does this page behave? It is repeatable, controlled, and diagnostic. Run it twice and you get roughly the same result, which is exactly what makes it useful for comparing a change against the version before it.
Field data answers: what did people actually get? It is messy, aggregated over weeks, and reflects every device, connection, and location your real audience has. It is not repeatable and it is not diagnostic, because it tells you what happened without telling you why.
Neither is more correct. They are measuring different things, and the mistake is expecting them to match.
What a lab test actually does
It loads the page on a simulated mid-range device over a throttled connection, from a specific location, with an empty cache, once. That combination is deliberately chosen to be representative, and being representative is not the same as being real.
- One device profile. Your audience spans everything from a three-year-old phone to a current desktop.
- One connection profile. Real connections vary constantly, including within a single page load.
- One location. Distance to your server affects every request, and the test point is rarely where your customers are.
- Always a first visit. A meaningful share of your real traffic is returning and has much of the page already stored.
- One page. Usually the homepage, which for most service businesses is not the page most people land on.
What field data is
An aggregate of real page loads by real people, reported as a distribution rather than a single figure. The convention is to report the experience at the seventy-fifth percentile, meaning three quarters of visits were at least this good.
That percentile choice matters. It deliberately ignores the fastest quarter, because a site that is excellent for people on new phones and poor for everyone else is not a fast site. It is a site that works for the people who need it least.
Why they disagree
| Situation | Usual explanation |
|---|---|
| Good score, poor field data | Your real audience is on slower devices or connections than the test profile, or lands on pages other than the one tested |
| Poor score, good field data | A large share of your traffic is returning visitors with much of the page cached, or the test profile is harsher than your actual audience |
| Score moves, field data does not | You changed something the test measures and visitors do not notice, or the field window has not caught up yet |
| Field data changed, score did not | Your audience mix shifted, or a change affected pages the test does not cover |
Why a perfect score is not a fast site
Scores are a weighted composite, and composites can be optimised toward without improving the underlying experience. It is entirely possible to reach a high score by deferring things the test measures while the page still feels sluggish to a person using it.
The reverse is also true and more common: a site with a mediocre score can be perfectly pleasant to use. The number is a summary, and summaries lose information by design.
The practical consequence is that chasing a score is the wrong objective. Chasing the experience is the right one, and the score is a rough indicator of whether you are moving in the right direction.
The problem small sites hit
Field data requires enough visits to aggregate meaningfully. A local business with modest traffic frequently has no field data reported at all, or has it for the site as a whole and not for individual pages.
That is not a failure on your part and it does have a consequence: you are working from lab tests alone, which makes it more important that they are run in a way that resembles your audience rather than accepting the defaults. It also raises the value of simply checking the site on a real phone, for the reasons set out in why your site is fast for you and slow for your customers.
How to use each properly
- Use field data to decide whether there is a problem. It is the only source describing your actual visitors.
- Use lab tests to find out what the problem is. They break the load down into components in a way field data cannot.
- Use lab tests to compare before and after. Controlled conditions are what make a comparison valid.
- Wait for field data to confirm. It updates on a rolling window, so a real improvement takes weeks to appear.
- Test the pages people actually land on, not only the homepage.
The order matters. Field data tells you whether to act, lab tests tell you what to do, and field data confirms whether it worked. Skipping the first step is how businesses spend a fortnight optimising a page that was never the problem.
Frequently asked questions
What is the difference between lab and field data?
Lab data is one simulated page load under controlled conditions, useful for diagnosis and comparison. Field data is an aggregate of what real visitors experienced over recent weeks, useful for deciding whether a problem exists at all.
Why is my PageSpeed score good but the site feels slow?
The test profile may not resemble your audience, or the tested page may not be the one people land on. A score is a weighted composite and can be improved in ways visitors do not notice.
Should I aim for a perfect speed score?
Aim for the experience rather than the number. A high score can coexist with a sluggish page, and a mediocre score can coexist with a site that is pleasant to use.
Why does my site have no field data?
Field data needs enough visits to aggregate meaningfully, and many local business sites do not reach that threshold. It means relying on lab tests configured to resemble your audience, plus checking on a real device.
Why has my field data not improved after I fixed something?
It reports on a rolling window of recent visits, so an improvement takes weeks to work through. A lab test will show the change immediately and the field figures follow.
Which should I act on when they disagree?
Field data decides whether there is a problem, since it describes your actual visitors. Lab tests then tell you what is causing it, because they break the load into components.
West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.
Not sure whether your speed problem is real?
We read the field data first to establish whether visitors are actually affected, then use lab testing to find the cause rather than chasing a score.
Start a Conversation