Why your Lighthouse score disagrees with your users
Your Lighthouse score is good and your site still feels slow to people, or the reverse.
Short answer
Lighthouse is a lab test: one run, one simulated device, one throttled connection, no real user behaviour. Field data is what actual visitors experienced across real devices and networks. They routinely disagree, and where they do, the field data is the one describing your business. Use the lab to debug and the field to decide.
What a lab test actually is
A single load on a simulated mid-range device with throttled network, in a clean profile, with no extensions, no contention, and nobody interacting. It is a controlled experiment, which is why it is repeatable, and controlled conditions are precisely what your users do not have.
Why the numbers diverge
Real devices are older and more varied. Real networks are worse and less stable. Real users have other tabs, extensions and background work competing for the same main thread. And crucially, real users interact, which is how responsiveness problems appear at all: a test that never clicks anything cannot measure the delay after a click.
The metric that shows it most
Responsiveness. A lab run performs no interaction, so its estimate is a model. Field data records the actual gap between a real click and a visible response, on the device that made it, and that is where a comfortable lab score most often turns out to be optimistic.
What the lab is genuinely good for
Debugging. It gives you a waterfall, a main-thread breakdown, and a reproducible baseline you can iterate against in minutes rather than waiting a month for field data to accumulate. That is a real workflow, and it is not the same as a scorecard.
The trap of the score itself
A single number invites optimising the number. Teams chase the last few points with changes that help the simulation and not the person, and a perfect score on a page nobody can use is a widely available outcome.
Where field data comes from
Any real-user monitoring you run, or the public field dataset Google collects from Chrome users, which only covers URLs with enough traffic to be statistically meaningful. Small sites often have no field data at all, which is itself worth knowing before you build a strategy on it.
How to use both
Read the field data to decide what to fix. Use the lab to reproduce it, change something, and confirm the change did what you expected. Then wait for field data to confirm it landed for real users, because the lab cannot tell you that.
Questions
- Which number should I report to stakeholders?
- Field data, with the lab score as supporting detail. A stakeholder acting on a lab score is acting on a simulation of a device none of your customers own.
- Why does my page have no field data?
- Not enough traffic for the public dataset to report on the URL specifically. You may get origin-level data instead, or nothing. Your own real-user monitoring is the only option at that size.
- Does Google rank on lab or field data?
- Field data, from real Chrome users. That alone settles which one to optimise for.
Measured, not asserted
The gap is not small. ihatepdf.cv measured its performance across 132,748 real sessions on the way to 100,542 users, and what those sessions showed, 37.16% of them containing a dead click, is not a thing a lab run performs at all: the test never clicks, so it never finds the failure the users were hitting.
Free tool for this: Crawler View. No account, nothing uploaded.
Where this goes deeper
Every number on this page comes from one complete dataset: one product taken from zero to 100K+ users on search alone, with nothing spent on advertising. The full argument is Chapter 11 and Chapter 19 of the book. Five chapters are free to read.