A Google PageSpeed Insights score is the most screenshotted number in technical SEO and one of the most misunderstood. Clients ask why it dropped several points overnight. Developers are asked to “get it to 100”. Most of that effort is aimed at the wrong number. Google’s own documentation, About PageSpeed Insights, is clear that the report contains two different kinds of data, and only one of them reflects what your visitors experienced.
Two reports on one page
PageSpeed Insights shows field data and lab data together. The field data is real users’ First Contentful Paint, Interaction to Next Paint, Largest Contentful Paint and Cumulative Layout Shift “over the previous 28-day collection period”, assessed at the “75th percentile”. It comes from the Chrome UX Report, and it is only there if your page or origin has enough eligible traffic.
The lab data comes from Lighthouse, run “in a simulated environment for the Performance, Accessibility, Best Practices, and SEO categories”. The headline performance score, the coloured circle with a number in it, belongs to this half. It is one test, on one simulated device and connection, at one moment.
The verdict that matters sits in the field section. Google states a page “passes the Core Web Vitals assessment if the 75th percentiles of all three metrics are Good”. The three are LCP, INP and CLS. If that assessment passes, a middling lab score is a curiosity. If it fails, a perfect lab score is no comfort.
What a Google PageSpeed Insights score means
The performance score is banded. These are Google’s thresholds, quoted from the PageSpeed Insights documentation.
| Performance score | Google’s label | How to treat it |
|---|---|---|
| 90 or above | “considered good” | Stop optimising the score; check the field data instead |
| 50 to 89 | “needs improvement” | Read the diagnostics for real bottlenecks, not points |
| Below 50 | “considered poor” | Likely a real problem worth reproducing and fixing |
The score is a weighted summary of several lab metrics, so it is a convenient shorthand for “how did this page load in the simulation”. It is not a measure of how your audience experienced the page, and it is not a pass or fail for anything Google assesses.
Is Google PageSpeed Insights accurate?
It is accurate about what it measures, which is narrower than people assume. The lab score is a faithful record of one simulated run. The reason people doubt it is that the number changes when you run it again without changing anything.
Google explains why. “Several common sources of metric variability are local network availability, client hardware availability, and client resource contention.” In plain terms: the test machine’s network, the hardware it ran on and whatever else was competing for that hardware all affect the result. Third-party scripts that load differently each time, such as ads or tag managers, add more variation from your side.
There is also a structural reason the lab and field halves disagree. The simulation loads the page once, cold, on a single device profile. Your real visitors arrive on a spread of devices and connections, many with cached assets, and they scroll and click. A page can load slowly in the simulation and still pass in the field, or load quickly in the simulation and fail for users on older phones. Our post on lab data vs field data covers each source of that gap.
That is why PageSpeed Insights gives different results for the same URL a few minutes apart. A swing of a few points is noise. Run the test several times and look at the spread before reacting, and never compare a single run before a change with a single run after it.
Why the score does not decide rankings
John Mueller put it directly in a 2021 exchange: “Google doesn’t use the X/100 lighthouse score for search, we use the core web vitals separately.” He added that “Google uses the values as users see them, which requires a certain amount of traffic first.” In other words, the field data counts and the lab score does not.
Even the field data is a modest factor. As our post on page speed and SEO sets out, Core Web Vitals sit inside page experience, and relevance still does most of the work. A slow page that answers the query well will usually beat a fast page that does not.
How to use the report well
Read it top down. First, check whether field data exists and whether the Core Web Vitals assessment passes. If it fails, our guide to a failed Core Web Vitals assessment covers which metric to tackle first and how to confirm it.
Second, use the lab diagnostics as a list of suspects, not a list of chores. The opportunities section often points to the real causes of a slow LCP: assets that block rendering, which our post on render-blocking resources covers, or a slow server response, covered in our guide to Time to First Byte. Fix the items that touch a failing field metric. Leave the cosmetic ones.
Third, report the right number. If you send clients or managers a PageSpeed Insights screenshot, send the field section, not the lab circle. It is what Google assesses, it moves less from run to run, and it reflects real visitors.
Check which level the field data describes, too. When a URL lacks enough traffic of its own, the report may fall back to data for the whole origin. That figure blends every template on the site, so a passing origin can hide one slow section, and a failing origin does not prove the page you tested is the culprit. Treat origin data as a pointer to go looking, then test the templates that carry most of your traffic.
The received wisdom is that a green score is the goal. It is not. A green score on a page with a failing field assessment means the simulation is kinder than reality, and chasing the last ten points on a page that already passes in the field is time better spent on content.
The limitation is the one most site owners hit first: no field data. Low-traffic pages and new sites often have nothing in the field section, which leaves only the lab score. In that case the score is an estimate of user experience, not a measurement of it. Use it to catch genuine problems, such as a score in the poor band, and do not treat small movements as meaningful. When the traffic arrives, the field data will follow, and that is the number to track from then on.
Frequently asked questions
What is a good PageSpeed Insights score?
Google says a performance score of 90 or above is considered good, 50 to 89 needs improvement, and below 50 is considered poor.
Why does PageSpeed Insights give different results each time?
Google names local network availability, client hardware availability and client resource contention as common sources of variability. Run several tests and look at the spread.
Is the PageSpeed Insights score a ranking factor?
No. John Mueller said Google does not use the X/100 Lighthouse score for search; it uses Core Web Vitals field data separately.
Why is there no field data for my page?
Field data comes from real Chrome users and needs enough traffic. Low-traffic pages often show only lab data.
The takeaway Read the field section first and the lab score second. Fix what fails for real users; ignore the run-to-run wobble in the number.
