How to Measure and Improve Site Speed

Page speed affects both the visitor's patience and search ranking. But "the site is slow" is not a diagnosis on its own: the server responding late, images being heavy and the page jumping as it opens are completely different problems, and their solutions differ too.
Why does my site open slowly?
The great majority of slowness comes down to one of four causes: unoptimised images, a large number of external services added to the page (chat tool, analytics, ad pixel), slow-responding hosting and late-loading fonts. Rather than trying to guess which it is, measure; because all four look the same from outside, yet one is solved in minutes while another requires a hosting change.
Which metrics to look at
Three metrics summarise the page's real experience on the user's side:
| Metric | What it measures | Good | Poor |
|---|---|---|---|
| LCP | When the largest content appears on screen | under 2.5 s | over 4 s |
| CLS | The page shifting as it opens | under 0.1 | over 0.25 |
| INP | Response time to a tap or click | under 200 ms | over 500 ms |
TTFB is added to these: the time until the server sends the first byte. Under 200 ms is good; over 600 ms signals a problem on the hosting side.
CLS is the most neglected metric on most sites. If an image without specified dimensions or a late-loading ad slot pushes the text down just as the user starts reading, CLS is high. This is as annoying as slowness, but it goes unnoticed because it doesn't show as seconds in a speed test.
How to measure
There are two kinds of data, and they say different things:
- Lab data: a one-off measurement under controlled conditions. Suitable for quickly seeing whether a change worked.
- Field data: data collected from real visitors. This tells the real truth; the lab can come out good while the field comes out bad, because your visitors' devices and connections are weaker than your test environment.
Measure mobile-first. A page that opens in 1.8 seconds on desktop can reach 4 seconds on a mid-range phone, and most visitors come from there.
What to fix first
The order matters, because the first two items give most of the total gain on most sites:
- Images. A photo uploaded straight from the camera can be 3-5 MB; converted to WebP and scaled to its real display width it drops to 100-200 KB.
- Unnecessary external services. An unused chat tool, a second analytics, a pixel tried and forgotten. Each means a separate connection and a separate delay.
- Fonts. Loading more weights and language support than needed is a common waste;
font-display: swaplets the text show until the font arrives. - Hosting. If TTFB is consistently high, the base time doesn't change no matter how much the three items above are fixed.
Measure again after every step. Making five changes at once and looking at the result prevents you learning which one worked.
How much improvement to expect
On a site that has never been optimised, sorting out the images alone often halves the page weight. On an already optimised site, on the other hand, gaining the last 200 milliseconds takes serious effort and usually isn't worth it. Set the target not as "the fastest possible" but as "on the good side of the thresholds".
Why two tools give different results
Measuring the same page with two different tools and seeing different scores is normal and doesn't mean one of the tools is wrong. The location of the measurement point, the simulated connection speed, whether the cache is full and the server load at that moment change the result.
So instead of chasing an absolute score, compare your own measurement with itself: before and after the change, with the same tool, measuring a few times and looking at the average. An 8-point improvement in a single measurement may be noise; an improvement seen in the average of three measurements is real.
Realistic targets for page weight
There's no exact upper limit, but in practice these ranges work: for a brochure page under 1 MB is comfortable, up to 2 MB acceptable, over 3 MB struggles noticeably on a slow connection. A similar logic applies to request count; under 50 requests is healthy, over 100 usually indicates an accumulation that needs cleaning up.
Product listing and gallery pages are naturally heavier. There the gain comes less from shrinking images than from lazy-loading those not visible on screen.
Three easily overlooked slowdowns
- Autoplaying video on the home page. Usually a file of several MB, and most visitors scroll past without watching it.
- Redirect chains. Every extra step in a chain like
http→https→www→ final address is a separate round trip. Go to the target in a single step. - Plugin accumulation. Plugins tried and not removed keep loading their own CSS and JS files. A yearly clean-up makes a surprising difference in page weight.
When to call it "fast enough"
If you're on the good side of the metrics and no complaints come from visitors, turning to the content and conversion side pays more than chasing the remaining milliseconds. Speed is a threshold; once the threshold is passed, the return on each extra gain drops quickly.
How much caching and a CDN help
Caching prevents the same visitor downloading files again on the second visit; a CDN distributes files from servers geographically close to the visitor. Both give real gains, but they have limits.
Caching doesn't speed up the first visit. A user coming to your site for the first time downloads every file from scratch; so if you aim to win new visitors, the real job is still reducing file sizes.
A CDN makes a noticeable difference for visitors in distant geographies. If all your visitors are in the same country as your server, the gain stays limited. The CDN does have a second benefit: it protects the origin server during sudden traffic spikes.
The one thing to watch with caching is not changing content without changing the file name. If you replace an image given a long cache header with the same name, visitors keep seeing the old version for months. The solution is adding a version to the file name or address.
What a speed improvement changes, and what it doesn't
Getting faster doesn't bring a direct jump in ranking. Its effect is indirect and comes by two routes: the visitor sees the content without leaving the page, and the search engine reaches more pages when crawling your site.
The effect on the conversion side, on the other hand, is clearer. A quote form that opens slowly is abandoned before it's filled in; this is a direct loss, independent of ranking.
Frequently asked questions
Does the score have to be 100? No. The score is a tool indicator, not a target. Being on the good side of the metrics is enough; chasing the remaining points usually isn't worth the effort.
Does quality drop when images are shrunk? A quality value of 80-85 in WebP is indistinguishable to the eye for most photos. For product images 90 may be preferred.
My site got faster but the score didn't change, why? Measurement conditions aren't the same every time. Look at the average of several measurements and at field data; a single measurement misleads.
You can measure your site's current state with the Site Speed Test and shrink your images with the Bulk Image Compression tool.