You ran your website through Google PageSpeed Insights. You got a number — maybe 34, maybe 87, maybe 96. And now you are wondering whether to panic, celebrate, or call your developer and ask why they have apparently built you a digital skip fire.
Here is the short version: the score matters less than you think. The specifics matter more. And chasing 100 is usually a waste of time.
Let us walk through what PageSpeed Insights actually tells you, which bits are worth caring about, and which bits you can safely ignore.
What PageSpeed Insights actually measures
PageSpeed Insights — PSI for short — is Google's free tool for testing how fast a page loads and how quickly it becomes usable. You give it a URL, it runs two tests — one simulating a mobile device on a 4G connection, one simulating a desktop on a fast connection — and gives you scores out of 100.
But here is the thing most people miss: the score is a lab test, not real-world data. It runs from Google's servers, in ideal conditions, with a clean cache. Your actual visitors might see very different results — better or worse — depending on their device, connection, and location.
That is why PSI also shows field data — real performance numbers from actual Chrome users who have visited your page in the last 28 days. These are the numbers that matter for your search rankings, because these are the numbers Google actually uses.
Lab data is the 0–100 score — a simulation. Useful for catching problems, but not what Google uses to judge your site in search.
Field data is the real-world measurements from actual visitors. If your field data shows green across Core Web Vitals, your visitors are having a fast experience — whatever the lab score says.
If your page does not have enough traffic to populate field data, PSI will tell you. Do not worry about it. The lab test is still useful for catching problems.
The three numbers that actually matter
Forget the 0–100 score for a moment. The important bit is Core Web Vitals — three specific measurements Google uses to judge whether a page feels fast to a real person.
LCP (Largest Contentful Paint) — how long until the biggest visible element loads. Think hero image, heading block, main video. Google wants this under 2.5 seconds. Under 4 seconds is "needs work." Over 4 seconds, you have got a problem.
INP (Interaction to Next Paint) — how quickly the page responds when someone clicks, taps, or types. Replaced FID in March 2024. Under 200 milliseconds is good. Under 500 is passable. Over 500, your page feels laggy.
CLS (Cumulative Layout Shift) — how much stuff jumps around while the page loads. You know when you go to tap a button and the page shifts and you hit an ad instead? That is CLS. Google wants this under 0.1. Anything over 0.25 is actively annoying your visitors.
These three numbers — not the headline score — are what determine whether Google considers your site fast. They are also the numbers most likely to affect your search rankings, though the impact is smaller than most SEO people claim.
What is worth fixing (and what is not)
PSI gives you a long list of "Opportunities" and "Diagnostics" after your test. Most of them look alarming. Most of them are not.
Worth your attention
- Large images not properly sized. If your 400px-wide thumbnail is a 4000px original, that is wasted bandwidth. Fix it.
- Code that blocks the page from loading. Some files force the browser to stop and read them before anything appears on screen. Often a quick win — your developer can defer these.
- Third-party tracking and chat tools. Google Analytics, live chat widgets, Facebook pixels, cookie consent popups. Each one phones home to another server before your page finishes loading. Audit which ones you actually need.
- Too many elements in your page. Every paragraph, button, image, and heading counts as a separate piece the browser has to build. Page builders routinely generate thousands of them because they stack containers inside containers. This is genuinely slow, and properly fixing it usually means rebuilding the site from cleaner code.
Mostly noise
- "Reduce unused code" (JavaScript / CSS). These are the files that control how your site behaves and looks. Every site ships a bit of code it does not strictly need. PSI flags this aggressively, but the real-world slowdown is usually tiny.
- "Serve images in next-gen formats." Modern image types like WebP and AVIF produce smaller files than old JPEGs. Useful, but if your images are already sensibly sized, converting format might save you a tenth of a second. Not nothing, but not urgent.
- "Too many page elements" when you are barely over the threshold. PSI's limit — 1,500 individual pieces on a page — is strict. A well-built site might have 1,800 without anyone noticing any slowdown.
- "Ensure text stays visible while fonts load." Means your visitors should see words immediately, even if the fancy font has not downloaded yet. Important, but if your fonts load in under a second, this is really just a checkbox exercise.
Fix things that save meaningful time, not things that tick boxes. Going from a 3MB page to a 1.5MB page matters — your visitors will feel the difference. Going from 94 to 96 because you shrank a tiny styling file from 4KB to 2KB does not.
Why your developer says "it is fine" when the score says 62
This is a genuinely common conversation. A business owner runs PSI, sees a 62 on mobile, and emails their developer in a mild state of alarm. The developer replies: "It is fine."
They might not be being lazy. Here is what they are probably seeing.
Your score is low because of things outside their control. Third-party scripts — Google Analytics, your live chat widget, that marketing pixel someone added last year — tank the score. Your developer cannot optimise someone else's JavaScript.
The lab test is brutal on mobile. PSI simulates a mid-range phone on a throttled 4G connection. A site that loads in 1.8 seconds on your iPhone on Wi-Fi might take 4.5 seconds in the test. That does not mean it is broken. It means the test is conservative by design.
The score weighs things your visitors do not notice. A brief delay in loading an image buried halfway down the page — somewhere your visitors will not even scroll to — will dock your score anyway.
Real-world data trumps lab data. If your Core Web Vitals assessment in Search Console shows "good" URLs, your actual visitors are having a fast experience — whatever the PSI lab score says.
That said: if your developer cannot explain why the score is 62, that is a different problem. A good developer knows exactly what is dragging the score down and can tell you what is worth fixing and what is not.
The real goal
A fast website matters. Visitors leave slow sites. Google prefers fast ones. But the point is not a perfect PSI score — it is a site that loads before your visitor gets bored and leaves.
For most business websites, the real target is:
- Core Web Vitals all green in Search Console
- Under 3 seconds to visually complete on a real phone on 4G
- No layout shift that makes buttons jump around
- No moment where the page looks broken while it loads
If you have got that, you are fine. Spend the optimisation budget on content, not on chasing the last three points.
If your site's PSI score is stubbornly low and you are tired of being told "it is fine," let us talk about it. We build websites that load fast by default — no page builders, no bloat, no excuses.
