How to Read Your Google PageSpeed Insights Report

Google’s PageSpeed Insights is free, takes a minute to run, and tells you a lot about how your website performs — if you know how to read it. Most people look at the big score, panic or relax, and miss the parts that actually matter. Here is how to read it properly.

A slow website costs enquiries, particularly on phones. But “my site feels a bit slow” is hard to act on. PageSpeed Insights turns that feeling into specific measurements and a list of causes, using Google’s own definitions of what a good experience looks like.

How to run the test

1. Go to pagespeed.web.dev.
2. Enter the full address of the page you want to test. Test your most important pages individually — your homepage, your main service page and your contact page — not just the homepage.
3. Check the Mobile results first, then Desktop. The mobile test simulates a slower device and connection, so it tends to show problems first.

The two kinds of result on the page

The report shows two different sets of data, and confusing them is the most common mistake.

Real-user data: what your visitors actually experienced

At the top, the report may show how real people’s visits went. Google’s documentation explains that this comes from the Chrome User Experience Report, reflects real users on a variety of devices and connections, and covers the previous 28 days.

If your site is new or does not get much traffic, you may see a message saying there is not enough data. That is normal. Google says that when a page has too few real-user samples, the tool falls back to data for the whole site — and if the site also lacks data, no real-user results are shown at all. It is not a penalty; it simply means there is not enough traffic yet to measure.

Lab data: a simulated test

Further down is the score most people notice. Google describes this as a simulated load of the page on a single device with a fixed set of network conditions. It is useful for diagnosing problems, but it is a test, not a record of real visits — so it can swing from run to run.

What the score colours mean

According to Google’s documentation, the performance score is grouped into three bands:

• 90 or above — good (green)
• 50 to 89 — needs improvement (amber)
• below 50 — poor (red)

An amber score is worth improving, but it is not a sign that the site is broken. The score is a summary of the lab test; the individual measurements below it tell you where the time is actually going.

The three numbers that matter most

Google’s Core Web Vitals are three measurements of real user experience. Google’s guidance on web.dev sets out what “good” means for each:

Largest Contentful Paint (LCP): how fast the main content appears

This measures loading. Google says a good experience means the largest piece of content on the screen appears within 2.5 seconds. On most business sites, that is a large hero image, a heading or a background video, which is why oversized images and videos are such common culprits.

Interaction to Next Paint (INP): how quickly the page responds

This measures how responsive the page is when someone taps or clicks. Google’s threshold for good is 200 milliseconds or less. It became one of the Core Web Vitals in 2024, replacing an older metric called First Input Delay. Heavy scripts and too many plugins are the usual causes of poor results.

Cumulative Layout Shift (CLS): whether the page jumps around

This measures visual stability — the annoying moment when you go to tap a button and the page shifts. Google’s threshold for good is 0.1 or less. Images without set dimensions and adverts or banners that load late are common causes.

Google also recommends judging these at the 75th percentile of page loads, separately for mobile and desktop. In plain terms: most of your visitors, not just the lucky ones on fast connections, should get a good experience.

Reading the list of suggestions

Below the numbers, the report lists suggestions, often with an estimated time saving. Google updates the tool regularly, so the exact wording changes over time, but the suggestions tend to fall into a few familiar groups:

• Render-blocking requests — stylesheets and scripts that must load before anything appears on screen. Plugins that load their files on every page are a frequent cause.
• Image delivery — photos uploaded far larger than they are displayed, or saved in heavy formats when a lighter one would look the same.
• Cache lifetimes — files the server tells browsers not to keep, so returning visitors download them again.
• Unused CSS or JavaScript — code loaded for features the page doesn’t use.

The estimated savings help you prioritise. Start with the items that save the most time and are easiest to change. Images are usually the quickest win; plugin and script issues often need more care, because removing the wrong file can break something.

A sensible way to use it

• Test more than once. Lab scores vary between runs, so look at the pattern rather than a single number.
• Prioritise mobile and the pages that bring in enquiries.
• Chase the Core Web Vitals, not a perfect score. A score of 100 is not the goal; a fast, stable experience for real visitors is.
• Change one thing at a time and test again, so you know what made the difference.

Speed on its own will not win rankings, but a slow site quietly loses visitors who were ready to get in touch. If you want to see why that matters commercially, our Media & Insights summary of a Deloitte study on 0.1-second speed improvements is a good place to start.