Open PageSpeed Insights, type in your URL, and you get a number between 0 and 100. It feels like a verdict. It is not — it is a lab estimate of one part of a bigger picture. But that does not mean you should ignore it, because the thing the score is trying to measure — how fast your pages actually are for real people — is one of the most reliably profitable levers in commerce. This post separates the two: why speed matters (with the evidence), what your score really measures, and what Google actually ranks on.
The business case: speed is measured in money
Speed is not a developer vanity project. Every extra second between a click and a usable page is a slice of your audience deciding to leave, and a slice of your ad budget spent on visits that never convert. The research on this is unusually consistent across a decade of independent studies.
- Bounce climbs fast. Google's mobile benchmarks found that as page load time goes from 1 to 3 seconds, the probability that a visitor bounces rises 32%; from 1 to 5 seconds it rises 90% (Google, 2017).
- Most mobile visitors will not wait. 53% of mobile site visits are abandoned if a page takes longer than 3 seconds to load (Google / DoubleClick, 2016).
- Small gains, real revenue. In the Milliseconds Make Millions study, a 0.1-second improvement in mobile speed lifted retail conversions by 8.4% and average order value by 9.2% (Deloitte with Google, 2020).
- Fast pages simply convert more. A site that loads in 1 second converts about 2.5× better than one that loads in 5 seconds, and the first five seconds have the largest impact on conversion rate (Portent, 2022).
- The giants proved it years ago. Walmart reported up to +2% conversions for every 1 second of improvement; Amazon famously estimated every 100ms of latency cost about 1% in sales.
Speed is the rare investment that improves three things at once: conversion rate (fewer people leave), ad economics (a faster landing page helps Google Ads Quality Score and lowers cost per click), and SEO (below). Most optimisations move one number. This moves all three.
What your PageSpeed score actually measures
The 0–100 Performance score comes from Lighthouse, and it is a weighted blend of five lab metrics — measurements taken by simulating your page on a mid-range device over a throttled network, not by watching your real visitors.
- Largest Contentful Paint (LCP) — when the main content appears — 25%
- Total Blocking Time (TBT) — how long the page is frozen to input — 25%
- Cumulative Layout Shift (CLS) — how much the layout jumps around — 25%
- First Contentful Paint (FCP) — when anything first appears — 10%
- Speed Index — how quickly the page visibly fills in — 10%
Two consequences fall out of the word lab. First, the number can swing between runs — the simulated network and the machine running the test both vary. Second, the test assumes a deliberately slow device and connection, so your real users often experience the page as faster than the lab score suggests. A score that bounces from 72 to 88 on refresh has not changed your site; it has changed the weather in the test lab.
The number Google actually ranks on is field data
Here is the distinction that saves teams from wasting weeks: the Performance score itself is not a Google ranking factor. What feeds Google's page-experience signals is Core Web Vitals field data — measurements from real Chrome users, aggregated over the trailing 28 days (the CrUX dataset). A page can post a mediocre lab score and still rank perfectly well if real users are having a good experience. The reverse is also true.
Google's "good" thresholds, measured at the 75th percentile of your real visitors, are:
- Largest Contentful Paint (LCP) ≤ 2.5 seconds — main content is visible quickly
- Interaction to Next Paint (INP) ≤ 200 milliseconds — the page responds promptly to taps and clicks (INP replaced First Input Delay in March 2024)
- Cumulative Layout Shift (CLS) ≤ 0.1 — the layout stays visually stable
Do not chase 100. Aim for green in the lab (90+) and "good" Core Web Vitals in the field for at least 75% of real users — then stop. The last few points almost always cost you a feature that earns more than the points are worth. A 100 score is a nice screenshot; it is not the goal.
What it looks like when you actually fix it
We do this work for a living — it is the whole point of our page speed optimisation practice. Numbers on a slide are easy; here is a real store. When Careshop came to us, its Magento storefront was slow enough to threaten both conversion and ad economics. This is where the mobile scores moved to:
| Metric | Before | After |
|---|---|---|
| Home — Performance | 40 | 97 |
| Home — Accessibility | 57 | 90 |
| Home — Best Practices | 44 | 100 |
| Home — SEO | 64 | 92 |
| Product page — Performance | 38 | 95 |
And because the score is only a proxy, we measured the thing customers actually feel: add-to-cart dropped from about 4 seconds to under 1 second. That is the part that shows up in the conversion report, not just in Lighthouse. The full story is in the Careshop case study.
How to read your own score without chasing a vanity number
- Look at field data first. If PageSpeed Insights shows a "Discover what your real users are experiencing" panel, read that before the lab score — it is what Google uses.
- Fix the worst Core Web Vital, not the lowest sub-score. Usually that is LCP (a heavy hero image or slow server response) or INP (too much JavaScript on the main thread).
- Re-check after ~28 days. Field data is a trailing 28-day average, so a fix you shipped today will not show in the field numbers immediately.
- Test on a real mid-range phone, not just your desktop and office Wi-Fi — that is closer to how most of your customers actually arrive.
- Protect the features that earn. Live chat, personalisation and a working checkout are worth more than the last five points of a lab score.
Frequently asked questions
Is the PageSpeed score a Google ranking factor?
No — the 0–100 score itself is not. Google ranks on page-experience signals that include Core Web Vitals measured from real users (field data), not on the Lighthouse lab number. A low score can still rank well if real users have a good experience.
Do I need a 100 score?
No. Aim for the green band (90+) in the lab and "good" Core Web Vitals in the field for at least 75% of real users. Pushing past that usually means removing features that make you more money than the extra points do.
Why does my score change every time I run it?
The Performance score is a lab test using simulated network throttling on a virtual device, and both vary between runs. For a stable read, use the 28-day real-user field data rather than a single lab result.
Lab data or field data — which should I trust?
Field data (real users) for any decision that affects rankings or revenue, because it reflects actual experience and is what Google uses. Lab data is best for debugging a specific issue in a repeatable environment.
How fast is fast enough?
Target LCP ≤ 2.5s, INP ≤ 200ms and CLS ≤ 0.1 for 75% of real visitors, and aim to keep key interactions — add to cart, search, filters — under about one second. Beyond that, returns diminish quickly.
If your score is in the red and you can feel the site dragging, the fix is rarely a single plugin — it is server response time, render-blocking assets, oversized media and too much JavaScript, addressed in the right order. That is exactly the work we do. Tell us about your store and we will tell you honestly what is slowing it down and what it is worth fixing first.