conversion for every additional second of load time. A site that takes four seconds instead of one has already lost about a fifth of its potential customers before they see a single word.
The three metrics that count
Google measures page experience through Core Web Vitals. There are three, and they map to three different frustrations:
- LCP — Largest Contentful Paint. How long until the main thing appears. Target: under 2.5 seconds. This is the one users describe as "slow".
- INP — Interaction to Next Paint. How long until the page responds to a tap. Target: under 200 ms. This is the one users describe as "broken".
- CLS — Cumulative Layout Shift. How much the layout jumps while loading. Target: under 0.1. This is the one that makes people tap the wrong button and leave.
Test on a mid-range Android phone over a mobile connection. Testing on a desktop with fibre tells you how the site performs for the one visitor who is not your customer: you.
Fixes, ordered by return
Performance work has sharply diminishing returns. In practice the first two items below account for most of the improvement on most sites.
1. Images
Usually the single largest win. A photograph exported straight from a camera can be 5 MB; the same image at the size it is actually displayed, in AVIF or WebP, is often under 150 KB. Serve several sizes and let the browser pick, and always set width and height so the layout does not jump.
2. Blocking scripts
Every script in the head that is not marked defer or
async stops the page from rendering. Audit third-party tags
ruthlessly: chat widgets, heatmaps and abandoned analytics tools routinely add
a second on their own.
3. Fonts
Preconnect to the font host, use font-display: swap so text is
readable immediately, and load only the weights you use. Four weights of two
families is a common and expensive habit.
4. Server response
Time to first byte under 500 ms is fine; under 200 ms is good. If yours is above a second, the host or the backend is the problem and no amount of front-end work will hide it.
What is safe to ignore
Chasing a perfect score is a poor use of budget. Once you are comfortably inside the Core Web Vitals thresholds, further micro-optimisation delivers less than rewriting a weak headline would. Speed is a floor to clear, not a score to maximise.
The business case
For a site taking 100 enquiries a month, cutting load time from four seconds to one recovers roughly 20 enquiries monthly — every month, for as long as the site runs. That is usually a larger return than any single campaign the same budget could buy.
Frequently asked
What is a good load time in 2026?
Largest Contentful Paint under 2.5 seconds on a mid-range phone over 4G. Test on that, not on your office fibre connection and desktop — most visitors are on neither.
Does speed matter more than content?
No. Speed decides whether your content gets read at all. It is a gate, not a substitute — a fast page with nothing to say still fails.
Will a faster host fix everything?
It fixes server response time, which is usually the smallest part of the problem. Oversized images and blocking scripts are almost always the bigger share.
How do I know what is slowing my site down?
Run a page speed test and read the opportunities list top-down. The first two items usually account for most of the loss; everything below them is rounding error.
We check any site against these criteria free of charge, in about 30 seconds.
Check your site