Google PageSpeed Insights: how it works and what you can get out of it

Your website feels fast on your laptop, on your wifi, with everything already cached. Your visitor is on a train on 4G with a three-year-old phone. PageSpeed Insights is Google's free tool that makes the gap between those two worlds visible — and for almost everyone it is the best place to start.

You do not need any technical knowledge to benefit from it. You enter your URL in Google's tool, wait half a minute and get a report. This article explains what is in that report, which numbers actually matter, what you can fix yourself, and where the point is that you need technical help.

Why speed matters (and not only for Google)

Two reasons, and the first is the more important one.

1. Visitors leave. Every extra second of load time costs conversion. That is not an opinion: it is one of the best-researched relationships in online marketing. On mobile the effect is largest, because connections vary and attention is shorter. A slower site means fewer enquiries, fewer sales and more expensive advertising, because you pay for a click that then walks away.

2. Google uses it as a signal. Speed is part of the page experience signals. It is not a primary factor — good content beats a fast empty page — but between comparable pages it can be the difference. It also carries over into what AI search engines and assistants can make of your page: anything that loads slowly or unstably is read less well.

In short: speed is not a technical hobby project, it is a commercial lever.

What PageSpeed Insights actually does

The tool does two things at once, and that is the main source of confusion.

• It runs a test load (lab data). Google loads your page on its own hardware with a simulated mobile connection and measures what happens. That produces the familiar score from 0 to 100.
• If there is enough data, it shows what real visitors experienced (field data). That comes from the Chrome User Experience Report, CrUX for short: anonymised measurements from real Chrome users over the last 28 days.

So the score comes from a lab test. The block at the top saying "Discover what your real users are experiencing" comes from CrUX. Those two can differ considerably — and usually that is not a fault but information.

The score: what does that number mean?

The colour bands are in the overview at the top of this article. Worth knowing:

• The score is not a grade for your website. It is a summary of one measurement of one page on mobile.
• It fluctuates. Two runs back to back can differ by 5 to 10 points. That is normal; look at the direction, not the decimal.
• 100 is almost never the goal. Green (90+) is fine. The last points often cost a lot of work and give your visitor little.
• Test per page, not just your homepage. A product page, a blog article and a landing page behave completely differently.

The three numbers that really matter

Under the hood it is about the Core Web Vitals: three metrics describing a visitor's experience. The exact Google thresholds are in the overview with this article.

• LCP — how fast the largest element is visible. Feels like "when do I see something useful?"
• INP — how fast the page responds to a click or keystroke. Feels like "is this thing responding?" (INP replaced the older FID metric in March 2024.)
• CLS — how much the page jumps while loading. Feels like "why did I just click the wrong button?"

Google judges field data at the 75th percentile: three out of four visits must land in the good range. That is deliberately strict — your average visitor is not your fastest visitor.

What you can get from the report without being a developer

Scroll past the score to the lower part of the report. That is where the recommendations sit, sorted by estimated savings. A good part of it is editorial work, not technical:

1. Images ("Serve images in modern formats", "Properly size images"). Almost always the biggest win and the least technical point. A 4 MB photo displayed at 800 pixels is pure waste. Exporting smaller and saving as WebP can halve a page.

2. Too many external scripts ("Reduce the impact of third-party code"). Every tracker, chat widget, cookie banner, review badge and A/B testing tool loads its own code. Walk the list and ask per item: do we still actually use this? That is a marketing decision, not a code question.

3. Shifting layout (CLS). Often caused by images without fixed dimensions, banners loaded later, or web fonts. Recognisable without any tool: load your own page on your phone and see whether anything moves.

4. Slow server (TTFB, "Initial server response time"). If the first response is already slow, front-end optimisation barely helps. That is about hosting, caching or an overloaded plugin stack — this is where technical work starts.

5. Unused CSS and JavaScript. A typical symptom of a heavy theme or a page builder with dozens of modules. Usually not something you fix yourself, but good to know before you install another plugin.

Practically: pick the two items with the largest estimated savings, fix those, measure again. Not everything at once — otherwise you never know what worked.

And then CrUX: if you really want to know

If you want to go beyond a single snapshot, CrUX is the source. Where the lab test says "this is how this page loads on our test machine", CrUX says "this is how this page loaded for thousands of real people, on their own devices and networks".

That is more valuable and more awkward:

• You need traffic. Without enough data, PageSpeed Insights shows no field data for that specific URL, sometimes only for the whole origin.
• It lags. The window is 28 days, so today's improvement only shows fully in weeks.
• It is not self-explanatory. CrUX tells you it was slow, not why. For the cause you still need the lab test, the Core Web Vitals report in Search Console, or real monitoring.
• Digging deeper needs tooling. The CrUX dashboard and CrUX API give you the split per device type and the trend over time — useful, but genuinely technical territory.

Hence the honest conclusion: PageSpeed Insights is an excellent base. For almost every business owner or marketer that base already gives enough to make better decisions. If you really want to know — which pages, which devices, which trend, which cause — CrUX is the right source, and technical help is not a luxury but the fastest route.

Where people go wrong

• Chasing 100. It costs disproportionately much and your visitor does not notice the last ten points.
• Only testing the homepage. Your revenue often comes from other pages.
• Taking the lab score as truth while CrUX says otherwise. If real visitors experience it as fine, a mediocre lab score is not a crisis. And the other way around: a nice lab score while CrUX is red is a real problem.
• Changing everything at once. Then you do not know which fix helped.
• Treating speed as a one-off project. One new plugin, one heavy video and you are back where you started. Put a moment in the calendar each quarter.

How to tackle this in an hour

1. Test your three most important pages on mobile: homepage, your best-selling or most-visited page, and one landing page.
2. Note the score plus LCP, INP and CLS per page. A screenshot is enough.
3. Check whether field data (CrUX) is shown. If so: it weighs more heavily than the score.
4. Take the two recommendations with the largest estimated savings. Large images and unnecessary scripts are often within your own control.
5. Measure again after a week and compare. Keep your notes, and you build your own baseline.

Do not want to dive into this yourself? Run our free website scan — it combines PageSpeed data with a look at your findability and conversion, in plain language. Or read on about conversion rate optimisation, because speed is one lever among several.

If your site stays slow despite every recommendation, it is nearly always a matter of hosting, theme or too many loose tools. We are happy to take a look with you.