You run your site through Google PageSpeed Insights. The score says 45. You open the site on your laptop and it loads in under two seconds. Everything feels fast. The score must be wrong.
It is not wrong. It is measuring something different from what you experienced. And understanding that difference is the key to knowing where to spend your optimization time.
Two types of data, two different stories
PageSpeed Insights shows two distinct sets of data, and most people conflate them.
Lab data is the performance score at the bottom of the report. It is generated by Lighthouse, which runs a synthetic test on a simulated mid-tier mobile device (a Moto G Power) with a throttled 4G connection. It is a snapshot of how your page would perform under those specific, controlled conditions.
Field data is the section at the top, labeled "Discover what your real users are experiencing." It pulls from the Chrome User Experience Report (CrUX), which aggregates real performance data from Chrome users who visit your site over a 28-day rolling window. This is how your actual visitors experience your site.
These two data sets frequently disagree, and the disagreement confuses people into optimizing for the wrong one.
Why they disagree
Lab and field data measure the same metrics (LCP, INP, CLS) but under completely different conditions.
Device differences. Lab tests simulate a mid-tier mobile device. If most of your visitors use modern iPhones or desktop computers, their devices are 3-5x faster than the simulated phone. Your field LCP might be 1.5 seconds while the lab reports 4 seconds.
Connection differences. Lab tests throttle the connection to simulate 4G. If your visitors are on broadband or WiFi, they download resources much faster than the lab simulation. This particularly affects image-heavy pages.
Geographic differences. Lab tests run from a single location (usually US-based). If your server is in the US and your visitors are too, field data reflects fast server responses. If your visitors are in Europe or Asia, field data might be worse than the lab due to latency.
Interaction differences. INP (Interaction to Next Paint) requires user interaction to measure. Lab data simulates specific interactions. Field data captures every real interaction your visitors make, including ones the lab does not test.
Third-party script behavior. Some third-party scripts (chat widgets, analytics, consent banners) load differently in lab versus production. Cookie consent can block certain scripts until the user accepts, which affects timing. A/B testing tools can delay rendering. These variations show up in field data but may not appear in the lab.
Want a website that turns visitors into customers, not just compliments?
Book a 15-min introWhich one Google uses for rankings
Google uses field data for ranking assessments. Specifically, it uses the CrUX data to determine whether your pages pass Core Web Vitals thresholds. The lab score, the big number at the top of the Lighthouse report, has no direct impact on rankings.
This matters because you can have a lab score of 45 and still pass Core Web Vitals in Google's eyes if your field data shows good LCP, INP, and CLS. Conversely, you can have a lab score of 95 and fail if your real users on real devices in real conditions experience poor performance.
The Search Console Core Web Vitals report shows your field data grouped by status: good, needs improvement, or poor. This is the authoritative source for understanding how Google views your site's performance.
When lab data is useful
Lab data is not useless. It is a diagnostic tool. It excels at:
Identifying specific issues. The Lighthouse diagnostics section tells you exactly which elements, scripts, and resources are causing problems. This specificity is invaluable for fixing things. Field data tells you there is a problem but not always where.
Testing before and after. When you make a speed optimization, run a lab test before and after to confirm the change had the expected effect. Lab conditions are consistent, so the comparison is valid.
Testing before you have field data. New pages and new sites do not have CrUX data until they accumulate enough traffic over 28 days. Lab data is all you have during this period.
Catching regressions. Integrate Lighthouse into your CI/CD pipeline to catch performance regressions before they reach production. Lab tests are automated and repeatable.
When field data is the truth
For ranking decisions. If your field data passes Core Web Vitals, your performance is fine from a Google ranking perspective, regardless of the lab score.
For user experience reality. Field data tells you what your actual visitors experience. If 90% of your visitors have good LCP, your users are happy. A lab score that simulates a slow phone does not change that.
For prioritization. If your field LCP is good but field INP is poor, optimize INP. The lab score might show a different priority because it simulates different interaction patterns. Trust the field data for deciding where to invest time.
How to read both effectively
Here is the approach I use:
Check field data first. Open PageSpeed Insights and look at the top section. If all three Core Web Vitals (LCP, INP, CLS) are green, your performance is good for ranking purposes. Note any yellow or red metrics.
Use lab data to diagnose. For any field metric that is yellow or red, scroll to the lab diagnostics to understand why. The lab will identify specific elements, scripts, or loading patterns that contribute to the problem.
Fix based on lab insights, measure with field data. Make the changes the lab suggests, then wait 28 days for the field data to reflect the improvement. The field data is the final word.
Check Search Console monthly. The Core Web Vitals report in Search Console shows your site-wide field data trends. This is where you confirm that fixes are working at scale across all pages.
The score is not the goal
The single-number performance score (0-100) that Lighthouse generates is a weighted composite of several metrics. It is useful as a quick health check but misleading as a target.
A score of 90 does not mean your site is fast. A score of 50 does not mean it is slow. The score depends on the simulated device, connection, and test conditions. What matters is whether your real users have a good experience, and that is measured by field data.
Stop chasing a number. Start tracking the three Core Web Vitals in field data: LCP under 2.5 seconds, INP under 200 milliseconds, and CLS under 0.1. If your real users hit those thresholds, your site is performing well regardless of what the lab says.
If your PageSpeed report is confusing and you are not sure which problems to prioritize, that is exactly what a focused performance review clarifies. I look at both data sets and tell you what actually needs fixing and what you can safely ignore.