1 Dec 25 
You run Lighthouse and get a great score, then Google says your Core Web Vitals are failing. Both are right. Here is the difference between lab data and field data, and which one actually counts.
Here is a confusion that trips up almost everyone working on site speed. You open Lighthouse, run a test, and get a lovely green score. Reassured, you check Google Search Console, and it tells you your Core Web Vitals are failing for real users. One tool says you are fast, the other says you are slow, and both are telling the truth. The reason is that they measure two completely different things, and understanding the difference is the difference between chasing a number that does not matter and fixing the one that does.
Lab Data: One Clean Test in a Controlled Room
Lab data is what Lighthouse gives you. It loads your page once, in a controlled environment, on a simulated device and connection that the tool defines, and measures how that single load went. It is a laboratory test: same conditions every time, repeatable, clean. That control is exactly what makes it useful for debugging, because when you change something and re-run it, any difference in the result came from your change and not from the noise of the real world. Lab data answers the question “under these specific standard conditions, how does this page perform?” and it answers it consistently.
The limitation is right there in the strength. The conditions are standard, which means they are not your actual users. Your real audience is on a spread of devices from the newest phone to a four-year-old budget handset, on connections from fast fibre to patchy mobile, with your scripts already warm in cache or cold on first visit. A lab test picks one point in that vast space and measures it. Useful, but partial.
Field Data: What Real Users Actually Experienced
Field data is the other kind, and it is what Google uses to judge you. It comes from the Chrome User Experience Report, CrUX, which collects real performance measurements from real Chrome users actually visiting your site. Not a simulation, not one clean load, but the aggregated experience of everyone who came, across all their devices and connections and conditions, over a rolling window. When Search Console says your Core Web Vitals are failing, it is reporting what your visitors genuinely felt, which is why it is the data that affects whether Core Web Vitals influence your rankings. Google cares about real experience, so field data is the scoreboard that counts.
Field data is usually reported at the 75th percentile, meaning the experience of your slower quarter of visits, not the average. This matters, because an average can look fine while a meaningful chunk of your audience has a genuinely bad time, and Google grades you on that slower slice, not the comfortable middle.
Why They Disagree, and Which One Wins
The two disagree because a lab test is one favourable load and field data is everyone’s real load, including the slow phones and the cold caches and the flaky connections your clean test never saw. A page can ace Lighthouse and still fail in the field because your actual users are having a harder time than the lab’s standard device. It can also happen the other way: field data can look better than a harsh lab test if most of your real traffic is on good devices. When they conflict, field data wins, always, because it is what your users actually experienced and what Google actually measures.
So the practical rule is simple. Use lab data for what it is good at, diagnosing and debugging, because its repeatability lets you test fixes cleanly. A tool like Lighthouse is perfect for isolating why an LCP is failing and confirming a change helped. But judge your real standing by field data, because that is the truth about your users and the number that moves rankings. Fix in the lab, measure success in the field.
The Trap to Avoid
The mistake this confusion causes is optimising for the lab score because it is the one you can see instantly, while the field data that actually matters stays broken. It is satisfying to watch a Lighthouse number climb, and easy to forget it is a proxy, not the goal. A green lab score with red field data means real users are still suffering no matter how good the simulation looks. The same trap catches teams on INP, which often feels fine in a quick lab load but hits real users during genuine interaction.
Watch both, understand what each is telling you, and never let a pretty lab score convince you the job is done when the field data says otherwise. The lab is your workshop. The field is the real world, and the real world is the one you are actually optimising for.
If you want your Core Web Vitals fixed for real users rather than just for the lab, that is a conversation away.