The PageSpeed score comes from a single simulated load in the lab. The Search Console report comes from field data: real Chrome users over a rolling 28-day window, judged at the 75th percentile. A page can be fast on the test device and slow for a quarter of real visitors on slower phones or networks, and the report reflects the second group.
Key takeaways
- Lab data is one run on one simulated device. It is repeatable, which makes it good for debugging, but it is not what visitors experienced.
- Field data comes from the Chrome User Experience Report. Google documents it as real-user data collected over 28 days.
- A page passes when the 75th percentile is good. Google's thresholds are LCP at 2.5 seconds or less, INP at 200 milliseconds or less, and CLS at 0.1 or less.
- Network and device change the result enormously. On one test page here, the hero image's LCP measured 36 ms unthrottled and 2,904 ms on a slow network.
- Search Console groups URLs and needs enough data. A page with little traffic may have no field data of its own and inherit a group verdict.
Why the two disagree
| Lab (the score) | Field (Search Console) | |
|---|---|---|
| Source | Lighthouse, one simulated load | Chrome User Experience Report |
| Who | A synthetic device and network | Real Chrome users on their own devices |
| Window | A few seconds | Rolling 28 days |
| Verdict | A 0 to 100 score | Good, needs improvement or poor at the 75th percentile |
| Status | Documented | Documented |
Sources: About PageSpeed Insights and web.dev on Core Web Vitals. PageSpeed Insights shows both: the field data block at the top when enough real-user data exists, and the lab score below it. If the top block is red and the score below is green, the page is failing for real visitors.
A measured example
In the lazy-loading test the same page produced an LCP of 36 ms in an unthrottled Chromium run and 2,904 ms when the network was throttled. In the LCP sub-part test for the slow LCP element guide, a 600 px hero image measured 2,932 ms on the same slow profile, almost all of it download time. Nothing about the page changed. Only the visitor did, and that is why a score from a fast office laptop and a quarter of your visitors on mid-range phones can disagree.
How to read both together
- Start with the field block in PageSpeed Insights for the URL, or the origin if the URL has too little data.
- Find which metric fails in Search Console (LCP, INP or CLS) and on which device group.
- Use the lab run to reproduce it, then throttle: slow 4G and a mid-range phone profile are closer to the 75th percentile than your laptop.
- Treat the lab score as a debugging aid, not a target. A 100 with a failing field LCP is still a failing page.
What to do
- For LCP, break the time into parts and fix the largest one: find the slow LCP element.
- For INP, the cause is often rendering and hosting more than script size: INP is not just JavaScript.
- For CLS, reserve space for images: images cause layout shift.
- After a fix, wait. The report is a 28-day window, so it improves gradually as old data ages out; Google also offers a validation process in Search Console.