Google Insights PageSpeed: What the Scores Actually Mean
You paste your URL into Google Insights PageSpeed, hit Analyse, and get back a number. Sometimes it's red. Sometimes it's amber. Occasionally it's a satisfying green. Most people stare at it for a moment, feel vaguely worried or vaguely relieved, and then close the tab. That's understandable, because the tool does not explain itself particularly well. These scores are not arbitrary, though. Each one points to something specific happening on your site, and understanding what they measure changes how you respond to them.
On this page
One Tool, Two Very Different Tests
The first thing worth knowing is that PageSpeed Insights runs two separate analyses. One simulates a mobile device on a slow 4G connection. The other tests desktop conditions. You get a score for each, and they often differ by 20 points or more.
Mobile nearly always scores lower. That is not a flaw in the tool. Mobile users are genuinely on slower networks and less powerful hardware, so the test reflects real-world conditions rather than a best-case lab environment. If your mobile score is in the red and your desktop score is green, that is not balance, that is a problem half-hidden.
What the Colour Bands Actually Represent
PageSpeed Insights scores run from 0 to 100. Google groups them into three bands, and the thresholds are worth knowing precisely rather than roughly.
- 0 to 49 (red) , Poor. The page is likely causing real frustration for visitors. Slow load times at this level are directly linked to higher bounce rates.
- 50 to 89 (amber) , Needs improvement. Not catastrophic, but there is measurable room to speed things up, and some users will notice the delay.
- 90 to 100 (green) , Good. Most pages in this range pass Core Web Vitals and give visitors a reasonable experience.
The number itself is a composite, though. It is not a direct reading of how fast your page loads in seconds. It is a weighted average of several underlying metrics, which is where most people’s understanding stops.
The Metrics Doing the Real Work
Behind the headline score sit six individual metrics. Not all of them carry equal weight. Some metrics matter far more than others, and knowing which ones Google emphasises is the difference between fixing the right things and wasting a day on the wrong ones.
Largest Contentful Paint (LCP) measures how long it takes for the biggest visible element on the page to load. That is often a hero image or a large heading. Total Blocking Time (TBT) captures how long the main thread is locked up by JavaScript, leaving the page technically loaded but unresponsive to taps and clicks. Cumulative Layout Shift (CLS) records whether elements jump around as the page settles, which is the experience of going to tap a button and having it move at the last second.
These three carry the most weight in the final score. Improving them moves the needle. Chasing the others without addressing these is tidying around the edges.
Lab Data vs Field Data
PageSpeed Insights shows you two kinds of information side by side, and most people do not notice the distinction. Lab data is collected by running a controlled simulation every time you run the test. Field data, shown in the ‘Discover what your real users are experiencing’ section, comes from real Chrome users visiting your site over the previous 28 days.
Field data is only available if your site has enough traffic for Google to have collected it. If you do not see it, the lab data is all you have. The two often disagree. A page can score 78 in the lab and still show red Core Web Vitals in field data if real-world conditions are harsher than the simulation assumes.
For SEO purposes, field data is what Google actually uses in its ranking signals. The lab score is useful for diagnosis. The field data is the report card.
Why the Score Changes Every Time You Run It
This catches people out. You run the tool twice in a row and get 71 then 68. Nothing has changed on the site. The variation is real and normal. The simulation uses a throttled connection, and network conditions in Google’s testing infrastructure fluctuate slightly. A swing of three to five points between runs is noise. A swing of fifteen points is worth investigating.
A common issue we see across many sites is a score that looks reasonable on average but collapses under load or at certain times of day, which points to a server performance problem rather than a front-end one. A good host matters as much as a lean codebase.
If you want a stable baseline, run the test three times and take the middle result. Then look at what the individual numbers are telling you rather than fixating on the composite score alone.
What the Score Does Not Tell You
A score of 90 does not mean your site is fast for every visitor. It means it performed well under a specific simulated condition. Shared hosting, a CDN without proper caching, or a theme loading four hundred kilobytes of unused CSS can all drag real-world performance below what the tool shows.
The score is a starting point, not a finish line. Treat it as a prompt to look deeper, not a pass or fail certificate.