How fast should a website be, and when is chasing 100 a waste
A perfect PageSpeed score is not always reachable, and it is not always worth reaching. Where the real gains are, and where the effort stops paying.
Run any website through Google's PageSpeed Insights and you get a number out of a hundred. It is the most quoted metric in web work and one of the most misunderstood.
What the number is actually measuring
The score is a summary of a handful of measurements, and one of them dominates: Largest Contentful Paint, the moment the biggest thing on screen finishes drawing. On most pages that is the main photograph or the headline.
The others matter less than people think. Layout shift — content jumping about while the page settles — is worth fixing because it is genuinely annoying. Interaction delay matters on heavy applications and almost never on a brochure site.
So when someone says a site "scores badly", they nearly always mean one thing: the main picture takes too long to appear.
Where the real gains are
In our experience these four account for nearly all of it, in this order:
- Serve pictures in a modern format. The same photograph as AVIF instead of JPEG is routinely a third of the size with no visible difference. On one recent site this alone cut total page weight by 36%.
- Serve the right size. A picture displayed 400 pixels wide should not be sent at 1280. Cutting several widths and letting the browser choose costs nothing at build time.
- Stop making the browser wait for things it does not need yet. Anything below the fold can load late. Fonts and scripts that block the first paint are worth hunting down individually.
- Tell the browser what is coming. One line naming the picture that will be the largest thing on the page lets it start fetching before it has finished reading the rest.
None of this is exotic, and all of it can be done once, in the build, so it keeps working for every page added afterwards.
Where the effort stops paying
Here is the part that agencies do not usually put in writing. On a well-built site you will typically reach 100 on desktop and somewhere around 95 to 97 on mobile — and the last few points may be unreachable.
The mobile test runs on a deliberately slow simulated device on a throttled connection. Past a certain point the number is dominated by that simulation rather than by anything on your site. We have watched a site sit at 2.13 seconds through a dozen genuine improvements, moving by twenty milliseconds either way, because the remaining time was the simulated processor and not the page.
There is a second trap: the tool is not a stopwatch you can trust across time. Run the same page twice an hour apart and the score moves, because the machine running the test is busier. We once chased a "regression" from 97 to 93 that turned out to be nothing but load on the testing machine. If you are comparing two versions, test them back to back, several times each, and compare the middle values.
What to ask for instead
A sensible target for a business site:
| Measurement | Worth having | Diminishing returns |
|---|---|---|
| Largest Contentful Paint | under 2.5s | under 1.5s |
| Layout shift | under 0.1 | zero |
| Page weight | under 1 MB | under 500 KB |
| Mobile score | 90+ | chasing 100 |
If a site meets the middle column, speed is not what is holding it back, and the money is better spent on the pages that do not exist yet.
Why we mention it at all
Because a slow site quietly costs you the visitors least willing to wait, and because the fix is mostly a build-time decision rather than an ongoing expense. Get it right once and it stays right.
You can check any site yourself, ours included, at PageSpeed Insights. It takes about thirty seconds and it is free.