PageSpeed Insights: how to read it and why scores vary
Each part of PageSpeed Insights explained: real-user data vs. lab tests, why your score changes on every run and what really deserves your attention.
Key takeaways
- The report has two parts: real-visitor data (what Google uses) and a lab test (the 0 to 100 score).
- The score changes on every run because of the network, the server and the simulation; small swings are normal.
- Prioritize the Core Web Vitals range from real visitors; the score helps you find problems, it is not what ranks you.
In this guide
PageSpeed Insights is Google's free tool for measuring the speed of a page. It is also one of the most misunderstood: many people look only at the score, panic at a red number on mobile or get confused when the same site scores 62 in one test and 71 in the next.
Let's go through what the report shows, part by part, and what to do with each piece of information.
The two parts of the report
After you paste a URL and click analyze, the report appears in two tabs, Mobile and Desktop, and each has two very different parts.
Part 1: what your real visitors experience
At the top is field data: measurements from real people who visited the page using Chrome over the last 28 days. It comes from the Chrome User Experience Report.
You see the three Core Web Vitals (LCP, INP and CLS), plus FCP and TTFB, each with a colored range. At the top is the verdict: the page passed or failed the Core Web Vitals assessment.
- The value shown is the 75th percentile: 75% of visits were as good as that number, or better.
- If the page has little traffic, the report may show data for the whole site or say there is not enough data. This is common for small sites and is not a problem in itself.
This is the part Google uses to evaluate page experience.
Part 2: the lab test
Below it is the famous 0 to 100 score, generated on the spot by Lighthouse in a simulated environment:
| Score | Range |
|---|---|
| 90 to 100 | Good |
| 50 to 89 | Needs improvement |
| 0 to 49 | Poor |
Along with the score come lab metrics (FCP, LCP, TBT, CLS and Speed Index), a filmstrip of the page loading and a list of suggestions for what to fix, with an estimate of how much each could help.
Why the mobile score is so much lower
In the mobile test, Google deliberately simulates a mid-range phone on a slow mobile connection: that is the reality for many people. A site that flies on your Wi-Fi laptop can score 40 in this simulation, and that is not a bug. It is a warning about how the site reaches a lot of people.
Since Google evaluates sites based on their mobile version, this is the tab that matters most.
Why the score changes on every test
You test and get 68. You test again and get 74. Nothing changed on the site. This happens because the test depends on:
- Network: the connection between Google's server and yours at that moment.
- Your server: whether it was more or less busy, whether the cache was warm.
- The test environment itself: the machine running the simulation also varies.
- Location: the test runs in Google data centers in North America, Europe or Asia, and the distance to your host matters.
- Variable content: ads, banners and third-party scripts that load differently on each visit.
A swing of a few points is normal. To compare before and after a change, run the test three times and take the middle result.
What to do when the two disagree
It is common for the lab score to be low while real-user data is in the good range, or the other way around.
- Poor lab, good field: your visitors probably have better devices and connections than the simulation. Great, but use the suggestions so things do not get worse.
- Good lab, poor field: something the test misses is hurting real visitors: scripts that load after an interaction, heavier inner pages or audiences on slower connections.
When in doubt, field data wins: it reflects real experience and is what Google's assessment uses.
How to use the list of suggestions
The list is useful but can be overwhelming. A few tips:
- Start with the suggestions with the biggest estimated savings. They are almost always images, unused JavaScript and render-blocking resources.
- Do not try to clear the whole list. Some suggestions depend on third-party services you do not control.
- One change at a time. Fix, test again and see the effect.
- Share the report with whoever maintains the site. The suggestions use the technical vocabulary developers understand.
What PageSpeed Insights does not do
- It keeps no history: each test stands alone, so it is hard to tell whether the site got better or worse over the months.
- It does not alert you: if a plugin update makes the site slow, you only find out if you test again.
- It does not test several pages at once.
- It explains little: the terms are technical and there is no guidance on where to start.
Tracking tools exist to fill these gaps. Teste de Performance uses the same Google measurement engine, explains the results in plain language, keeps a history of your pages and alerts you when something gets worse. Our comparison of speed test tools shows the options side by side.
Summary
- Look at real-user data and the Mobile tab first.
- Use the score to find problems, not as an absolute goal.
- A swing of a few points is normal: compare trends.
- Tackle the highest-impact suggestions first.
To understand each metric in detail and how to improve it, see our Core Web Vitals guide.