WordPress speed optimisation: what actually moved the numbers
Most advice about WordPress speed is written by someone selling you the fix. The caching plugin’s blog says caching is the answer. The host says it’s hosting. The CDN says it’s edge delivery. None of them show you measured numbers from a real site, because measured numbers are inconvenient — some of the popular fixes barely move anything.
I rebuilt a busy WooCommerce shop recently and measured everything, before and after. Server response time went from 2.9 seconds to 0.22. Largest Contentful Paint from 3.9 seconds to 1.35. Page weight and request count roughly halved. This guide is what actually moved those numbers, what didn’t, and how to find out which fix your site needs — without buying anything first.
Why is my WordPress site so slow?
Nine times out of ten it’s one of four things: slow server response, oversized images, too much theme and plugin weight, or a page builder generating code faster than anyone can delete it. The trick is finding out which one is yours before spending money — and that takes about fifteen minutes, free.
Run your homepage through WebPageTest and PageSpeed Insights, then read three numbers in this order:
- TTFB (time to first byte). This is your server thinking. Anything over about 0.6 seconds means your problem starts before a single pixel is sent — hosting, PHP, database, or no page caching. No image plugin will fix this.
- The LCP element. PageSpeed tells you which element is your Largest Contentful Paint. If it’s a 2MB hero image, you’ve found your afternoon’s work.
- Page weight and requests. Over ~2MB or ~80 requests for a content page, and you’re carrying baggage — usually builder CSS, unused plugins’ scripts, or fonts loading four weights you don’t use.
Whichever number is worst is where your money and time should go. That sounds obvious. It’s also the exact opposite of how most people spend — they install a caching plugin against a 3MB image problem and wonder why nothing changed.
What actually moves the numbers?
Here’s the rebuild I mentioned, fix by fix. A trading WooCommerce shop on shared hosting, measured with WebPageTest before and after each change. Your mileage will differ — but the order of what matters probably won’t.
| Fix | What it moved | Effort | Honest verdict |
|---|---|---|---|
| Proper page caching on a LiteSpeed server | TTFB 2.9s → 0.22s | Half a day, done carefully | The single biggest win. Most “slow WordPress” is really “no working page cache”. |
| Serving images correctly (right size, modern format, lazy-loaded) | Biggest share of the weight halving; LCP 3.9s → 1.35s with the theme work | A day, incl. checking every template | Second biggest win on almost every site I see. |
| Replacing a bloated theme + builder with a lean build | Requests roughly halved; CSS from megabytes to kilobytes | A project, not a tweak | Transformative — but do the cheap fixes first and you may not need it. |
| Redis object caching | Snappier admin + logged-in pages; little change for anonymous visitors | An hour, easily reversed | Worth it on WooCommerce; not the headline some make it. |
| CSS/JS minification and combining | Barely measurable | Minutes — and real breakage risk | See the next section. |
The uncomfortable summary: the two fixes that did most of the work — caching and images — are the least glamorous and the most often half-done. A caching plugin that’s installed but misconfigured is the most common thing I find on “slow” sites. It looks ticked off. It isn’t working.
What barely matters (despite the noise)?
Some things get sold hard because they’re easy to sell, not because they move numbers. In my measurements:
- Minifying and combining CSS/JS. On a site that’s already sensibly built, this shaves kilobytes and risks breaking things. I’ve watched an optimisation plugin’s combine feature take a working shop down. The saving was going to be milliseconds.
- Chasing a 100/100 score. The score is a lab estimate, not a customer. I’ve had a page’s score bounce around because of a font repaint the visitor literally could not see — fixing it took ten minutes and changed nothing for real users. Fix the field data (what real visitors experience), not the trophy.
- Plugin count. “You have too many plugins” is folk wisdom. Five heavy plugins can cost more than twenty light ones. Audit by weight — what each one loads on the front end — not by number. I’ve written more on that in WordPress plugin bloat: how much is too much?
Is it your page builder?
Sometimes, yes — measurably. On one shop I took apart, the page builder had left behind roughly 11MB of generated CSS, more than a thousand rows of database metadata, and fifty stored templates — before a single product was counted. That’s weight the server carries on every request, every backup, every migration.
But be honest about the trade before you act. Builders exist so owners can edit without a developer, and that’s worth something real. If your site is a serious commercial asset that rarely gets restructured, a lean custom build wins on every measurement. If you rearrange your own pages weekly, the builder may still earn its keep — just keep it on a diet. I’ve written up the full decision, with the same shop’s numbers, in Page builders vs custom themes and the specifics in Elementor’s SEO problems and Gutenberg vs page builders.
Why is WooCommerce slower than plain WordPress?
Because a shop can’t cache everything. Carts, checkouts and logged-in sessions have to be generated fresh per visitor, so WooCommerce leans harder on your server than a brochure site ever will. Three things follow from that:
- Your hosting matters more. The parts of a shop that can’t be page-cached run at your server’s raw speed. This is where cheap hosting quietly costs money.
- Object caching earns its place. Redis speeds up the repeated database lookups WooCommerce makes on every uncached page. It’s an hour’s work and easily reversed — a rare free lunch.
- Don’t run two image optimisers. A common one: a WebP plugin on the server and a CDN optimising at the edge. The CDN can’t resize a pre-converted WebP, so full-size images ship anyway — and on one launch I saw exactly this combination cause intermittent 504 errors while the CDN choked cold-pulling thousands of oversized originals. Pick one optimiser. One.
One more WooCommerce-specific trap: filtering. Category pages that filter products can hammer the database if they’re built lazily. There’s a measured example in replacing plugin filtering with custom WooCommerce filtering.
What about Core Web Vitals?
Core Web Vitals are Google’s three measurements of real-visitor experience: how fast the main content paints (LCP — aim under 2.5 seconds), how quickly the page responds to taps (INP — under 200ms), and whether things jump around while loading (CLS — under 0.1). They’re measured from actual Chrome users, not from a lab.
Two honest notes. First: they’re a modest ranking factor, not a magic one — content and links still decide most of it; speed decides the close calls and, more importantly, whether visitors stay. Second: the field data lags. Fix your site today and Google’s 28-day collection window means the dashboard catches up next month. Don’t panic in week two. The fuller picture for shops is in Core Web Vitals for ecommerce.
Questions I get asked about WordPress speed
How much does WordPress speed optimisation cost in the UK?
Honestly: anywhere from £150 for an hour of someone competent pointing at the obvious, to £5,000+ if “speed optimisation” turns out to mean “your theme needs rebuilding”. Most one-off speed work lands in the £300–£1,500 range depending on what the diagnosis finds. Be wary of anyone quoting before they’ve measured — the fix depends entirely on which of the four causes you’ve got. I price this as a fixed piece of work after a measured look: details on the performance page.
Do caching plugins actually work?
Yes — page caching is the single biggest win on most sites, which is why it tops the table above. But one plugin, configured properly, matched to your server. Three caching plugins fighting each other is a thing I genuinely find in the wild, and it’s slower than none.
Will a CDN make my WordPress site faster?
For images and static files, usually yes — especially for visitors far from your server. It won’t fix a slow TTFB on your uncacheable pages (that’s hosting), and combined carelessly with a server-side image plugin it can make things worse — see the one-optimiser rule above.
How fast should my site actually be?
Under 2.5 seconds LCP for real visitors is Google’s bar and a decent one. The practical bar is simpler: noticeably faster than the other places your customer is shopping. On mobile, on their data plan, not on your office wifi.
Can I just install a plugin and be done?
If your problem is caching, largely yes. If it’s images, partly. If it’s hosting or theme weight, no — a plugin can’t transmute a slow server or delete 11MB of builder CSS. That’s why the fifteen-minute diagnosis comes first: it tells you whether you’re facing an afternoon or a project.
Where do you start?
Run the fifteen-minute diagnosis at the top. If TTFB is your problem, look at hosting and caching before anything else. If it’s images, fix them before touching a line of code. If it’s weight, decide whether you’re dieting or rebuilding — and get measured numbers before choosing.
And if you’d rather someone did the measuring and the fixing: that’s what my performance work is — same method as this guide, numbers before opinions — and the AI Operations retainer is how it stays fast after I’ve gone. Either way, start with the measurement. It’s free, and it’ll save you buying the wrong fix.