Measure before you optimise anything

Most speed advice is a pile of twenty tips presented as equals. They are not equals. Done in the right order, the first three changes usually deliver more than the other seventeen combined — so here they are, in that order.

Run your site through PageSpeed Insights or WebPageTest before touching a thing, for two reasons. First, the waterfall tells you your bottleneck — and optimising the wrong thing feels identical to optimising the right one until you measure. Second, without a before number, you cannot know whether anything you did worked.

Look at three numbers and ignore the rest at first: total page weight, number of requests, and Largest Contentful Paint (when the main content appears). And note the trap in lab scores: a 90 on your fibre connection can be a ten-second load on a phone on the train. Test the mobile profile; that is where your slow visitors live.

Images are usually the biggest single win

On a typical small site, images are 60–80% of page weight, which makes them the highest-leverage fix by far. Three moves, in order of effort-to-payoff:

Resize to display size. A 4,000-pixel camera photo displayed in an 800-pixel column ships five times the pixels anyone sees. Export at the size you use (or double it for high-density screens) before anything else — this alone routinely halves page weight.

Compress and convert. WebP at quality 80 typically lands at a quarter of the equivalent JPEG with no visible difference; every image tool and WordPress optimiser can emit it now. A 300KB hero photo becoming 60KB is a bigger win than any plugin will ever hand you.

Lazy-load below the fold. loading="lazy" on images the visitor has to scroll to defers them until needed. Keep it off your top image — lazy-loading the hero delays the very thing LCP measures. And always set width and height so the page does not jump as images arrive.

Caching does more than any plugin bundle

Caching is the art of not redoing work, and it happens at two levels that get conflated.

Browser caching tells returning visitors to keep your CSS, JS and images locally instead of re-downloading — a few lines of Cache-Control headers in .htaccess. Set long lifetimes on assets and version the filenames so updates still reach people. (Our own build learned that lesson the hard way; hash-versioned URLs are the correct answer.)

Page caching is the big one for WordPress and other dynamic sites: instead of running PHP and a dozen database queries for every visitor, serve a saved copy of the finished page. A single good caching plugin — or server-level caching where your host offers it — regularly cuts response times from hundreds of milliseconds to tens. If you install one performance plugin, make it this; if you have installed six, that is part of your problem, which brings us to…

Reduce what loads before the page is usable

Every plugin, font, tracker and widget you add spends your visitors' time. The audit is simple: open the request waterfall and ask what each entry is for.

Plugins: deactivate anything you have not needed in three months; several WordPress plugins each adding a stylesheet and script to every page is death by a dozen cuts. Fonts: one family in two or three weights, self-hosted where possible — each extra weight is another download, and third-party font services add whole extra connections before text can settle. Third-party scripts: chat widgets, embeds and trackers are the slowest things on most pages because you are waiting on someone else's server; keep the ones that earn their cost, load them deferred, and delete the rest.

Server, PHP version, and what NVMe actually adds

Everything above happens on your side. Underneath sits a floor set by the hosting: distance to the server (latency physics no plugin fixes — a CDN helps if your audience is far from your host), the PHP version (8.3 is dramatically quicker than the 7.x era for WordPress workloads — switching is one panel setting), and storage speed, where NVMe genuinely helps database-heavy sites and honestly matters little for cached ones — the full honest breakdown.

Yes, Traxio runs NVMe and current PHP throughout — and we will still tell you that compressing your images comes first. The order of this article is the advice: measure, then images, then caching, then subtraction, and only then the infrastructure questions. Do the first three this afternoon and measure again; for most sites, that is the whole project.