Most site speed advice starts with minifying JavaScript, which for a typical small business site is close to the last thing that matters. Here's the order actually worth working through — with our own numbers where we have them, so you can see the size of each lever.
First, measure the right thing
Look at Largest Contentful Paint: how long until the main thing on the page appears. Google's guidance is 2.5 seconds or less. A perfect score on a synthetic test means very little if the hero image still takes four seconds on a phone.
Test on mobile, on a throttled connection. A desktop on office fibre will tell you everything is fine, and it isn't.
1. Images — usually most of the problem
Not because there are too many, but because they're served at full camera resolution and shrunk by the browser. A 4,000-pixel-wide photo shown in a 400-pixel box is sending a hundred times the pixels it needs.
Resize to about twice the displayed size, convert to WebP, set width and height so the layout doesn't jump, and lazy-load anything below the fold. On an image-heavy page it's the biggest single reduction available, and the cheapest.
2. Hosting
Cheap shared hosting is cheap because you're sharing a server with a lot of other sites. Watch time to first byte — how long the server takes to start sending anything. Google treats 0.8 seconds or less as good and anything over 1.8 seconds as poor, and no amount of front-end work fixes a slow server.
This is the step people resist, because it costs money every month instead of once. It's also often the biggest improvement on the list, and a large part of why we host and look after sites as well as build them — see managed web hosting in Ballarat.
3. Third-party scripts
Chat widgets, analytics, tag managers, tracking pixels, review embeds. Each is a request to somebody else's server, and your page waits for it. Campaign pixels have a habit of outliving the campaign. List what actually loads and remove anything nobody looks at.
4. Plugins, if it's WordPress
Not the count — the weight. One page builder can add more front-end code than twenty small plugins. Check what each loads on every page against where it's actually needed. Sliders, form builders and anything animated are the usual suspects.
5. Fonts
Every custom font is a download that can hold text back from rendering. Two families with a couple of weights each is plenty. Use font-display: swap so text shows immediately in a fallback, and don't load nine weights when the design uses three.
6. Minifying — real, but small
Here's why it's near the bottom. Minifying every stylesheet and script on this site takes them from 642 KB to 419 KB, about 35% smaller, and trims the HTML from 842 KB to 749 KB. Worth having, and our build does it automatically. But the entire saving, across the whole site, is smaller than one full-resolution photo from a modern phone. If the images aren't sorted, minification is polishing the wrong thing.
7. Caching — last, and not only about speed
Caching genuinely helps, and it's deliberately last because caching a bloated page just serves the bloat faster. Fix the weight first.
It also decides what a burst of traffic costs you. Our own marketing site is set up so every page request goes back to the server rather than being served from the CDN's cache, which guarantees nobody sees a stale page after a deploy. In September that trade-off showed up on the bandwidth graph: a script polling one page every few seconds went straight through to the server every time, for 22 GB in three days. Pages that rarely change should be cached at the edge.
The honest summary
Work top to bottom and stop when it's fast enough. In our experience most of the gain comes from images and hosting, which is why they're first and second. If you've done both and it's still slow, then it's worth getting into the code — and at that point you're solving a real problem rather than a guessed one.
Run a free audit and see where yours stands.
Audit my site →