How to speed up a slow website: Seven things, in the order they pay

Most articles on this subject explain what page speed is. You already know what it is — your site is slow and you want it to stop. So this one skips the definition and goes straight to the seven things that actually move the number, in the order they move it, with real before-and-after readings from a site we rebuilt: our own.

How do you speed up a slow website?

You cut weight before anything else, because on nearly every small-business site the weight is images and unused scripts — no amount of caching rescues a page asking the phone to download 4 megabytes. Measure first, cut the two or three biggest items, and re-measure. Most sites are fixed by the first three items below.

What cutting weight actually looks like — our own numbers

These are readings from this site, measured 2026-09-18 and recorded in our own audit. They are not a case study about somebody else, which is the point: they are the sizes of the things that were wrong, so you can look for the same shapes on yours.

The portfolio page lost two-thirds of its weight. Nothing was redesigned and nothing was removed that a visitor could see — it was images at the wrong size and a library shipped in the wrong build. That is the ordinary case, and it is almost always where the seconds are.

The seven, in the order they pay

1. Resize the images before you compress them. The most common fault by a distance is a photograph 3,000 pixels wide displayed at 600. Compression on an oversized image is still an oversized image. Export at the size it is shown at, then compress.
2. Check whether any library is shipping its development build. Development builds carry warnings, comments and debugging for a browser that needs none of it — ours was 1,243 KB where the minified file was 652 KB. Same file, same behaviour, half the weight.
3. Delete the scripts nothing on the page uses. Chat widgets, old analytics, a slider plugin from a section that was removed two redesigns ago. Each one is a download, a parse and an execution before the page settles.
4. Give every image a width and height in the markup. This does not make the page lighter; it stops it jumping while it loads, which is a separate score and the one visitors actually feel as cheapness.
5. Turn on compression and caching at the server. This is the step everyone starts with and it belongs fifth, because compressing four megabytes of unnecessary images still leaves you with unnecessary images.
6. Load fonts deliberately. Two weights of one family, preloaded, with a real fallback. Five weights of three families is a second of blank text on a phone.
7. Re-measure on a phone, on mobile data, not on office wi-fi. Every number above was produced on a desk. The only reading that matters is the one a customer gets.

How to speed up a WordPress site specifically

WordPress needs the same seven steps, in the same order, plus two additions. Deactivate plugins one at a time and re-measure — on most slow WordPress sites, two or three plugins account for most of the added weight, and you cannot tell which without removing them. Also check what the theme loads on every page.

What will not fix it: a caching plugin installed on top of everything above. Caching makes the server’s part faster, and the server’s part is rarely the problem. Our own server answers in well under a second; the seconds were in the download.

Measure yours before you change anything

1. Run your address through the free nine-point audit and write down the total weight and the request count. It prints every reading rather than a score, so you get the numbers rather than a grade.
2. Open the page on your own phone, on mobile data, and count the seconds until you can read something. Over three is the threshold where people leave.
3. Fix items one and two only, then re-run the audit. On most sites that is the majority of the improvement, in an afternoon.
4. Only then look at caching. If you do it first you will never know which change did the work.

If the audit comes back failing on structure and metadata as well as weight, speed is not your largest problem — the technical issues we find on nearly every site covers the rest, and the signs a website is costing you work is the version of that written for an owner rather than a developer. If the site is slow because it was built badly rather than maintained badly, what a redesign actually costs is the honest next question. Our own current readings are published on the speed page, so you can check whether we take our own advice.