Improve PageSpeed on WordPress: the fixes that matter

Here's the short version, then the detail. To improve PageSpeed on WordPress you fix three things — images, caching, and the scripts and fonts that block the first paint — and you ignore most of the other twenty-odd warnings Lighthouse throws at you. Those three carry almost the whole score because they're the things that decide how fast a real person sees your page. The rest is mostly noise that'll eat a weekend and move the needle by a point. I read the actual Lighthouse breakdown, sort the fixes biggest-impact-first, and stop when the real-visitor numbers go green. Here's how to do the same.

Stop chasing the number. Read the breakdown.

When most people run PageSpeed Insights they see a red 48, panic, and start ticking off warnings top to bottom. That's backwards. Lighthouse hands you a list of thirty "opportunities" with no honest sense of which ones matter, so you can spend hours preloading a font and deferring a stylesheet and watch the score barely twitch.

The score isn't one number — it's a weighted average of a handful of metrics, and two of them do most of the work. Largest Contentful Paint (LCP) — how long until the biggest thing on screen, usually your hero image or headline, actually shows up — is the heaviest. Total Blocking Time (a lab stand-in for how janky the page feels while scripts run) is next. Get those two right and the score follows. Everything else on the list is rounding.

So before you touch anything, read the breakdown and ask one question of each warning: does this change LCP or blocking time? If yes, it's on the list. If no, it can wait, possibly forever.

The three fixes that actually move it

On a typical WordPress site, in the order I'd do them:

1. Images — almost always the single biggest win. Nine slow WordPress sites out of ten are slow because someone uploaded a 4000-pixel-wide, 2MB photo straight off a phone and dropped it into the hero. The browser downloads the whole thing, then shrinks it to fit. Fix: resize images to the size they're actually displayed at, serve them as WebP, and let everything below the fold lazy-load. WordPress lazy-loads by default now, but the hero image must not be lazy-loaded — that's the one thing you want to arrive first. This alone often drags LCP from four seconds to under two.
2. Caching plus a delivery layer in front. A WordPress page is built fresh from the database on every visit — PHP, MySQL, the lot — which is slow. Page caching turns that into a flat HTML file served instantly. That's your biggest server-side win and it fixes a slow Time To First Byte. Put a content delivery network in front (Cloudflare's free tier is genuinely fine for a small business site) and your assets get served from an edge close to the visitor instead of one box. One good caching plugin set up properly does this. You don't need three.
3. Kill the render-blocking scripts and fonts. This is where page builders and plugin sprawl bite. Every plugin that adds its own CSS and JavaScript to every page — the contact form, the slider, the social icons, the cookie banner — adds weight the browser must deal with before it can paint. Defer or delay the JavaScript that isn't needed for the first view, only load each plugin's assets on the pages that use them, and self-host your fonts with font-display: swap so text shows immediately in a fallback rather than sitting blank. This is what drags blocking time down.

Do those three, in that order, and you'll have captured the large majority of the gain. A site that was a red 45 lands in solid green territory, and — more importantly — it actually feels fast on a real phone.

The fixes that don't move the needle (but everyone obsesses over)

Here's where I'll take a position the speed-plugin marketing won't: a stacked "all-in-one optimiser" with every checkbox ticked is usually a downgrade. Same logic as a cheap WiFi booster — it looks like the obvious fix and it quietly makes things worse. Combining and minifying every file, inlining critical CSS, "removing unused CSS" — these are real techniques, but on a normal WordPress site they're where people lose a weekend and break their layout for a two-point gain.

• Minifying and combining files shaves kilobytes that modern compression and HTTP/2 already handle. The risk-to-reward is poor: one wrong combine and your menu stops working.
• "Eliminate render-blocking resources" on a stylesheet you actually need just delays the look of the page. Defer scripts, not the CSS that styles what the visitor sees first.
• Chasing the last 10 points to hit 100. The jump from 45 to 85 is felt by every visitor. The jump from 90 to 100 is felt by nobody and often costs you a fragile config that breaks on the next plugin update.
• Stacking optimisation plugins. Two caching or "speed" plugins fighting over the same files is the most common cause of a site that mysteriously breaks after a "speed fix". Pick one. Bin the rest.

Lab score vs the score Google actually uses

This is the bit that catches people out, so it's worth being blunt: the number Lighthouse gives you is a lab test — one simulated run on one simulated phone. Google doesn't rank on that. It ranks on Core Web Vitals measured from real visitors — the field data, which you'll find in Search Console under the Core Web Vitals report. A site can score a flashy 96 in the lab and still fail its real vitals because actual people are on a mid-range Android on a congested mobile tower out past the suburbs, not on your fast laptop on fibre.

So treat the Lighthouse number as a workshop tool, not the goal. The goal is green field vitals from your real audience. If your lab score is mediocre but Search Console says your vitals pass, you're done — go and write content instead.

Test like an Australian visitor, not like a developer

Most WordPress sites I'm handed test fine on the owner's machine and badly in the wild, for one reason: the owner is on a fast connection and a powerful laptop, and their customers aren't. A real slice of Australian traffic is on a mid-tier phone, on mobile data or a busy NBN connection at dinnertime, possibly a long way from the nearest data centre. That's the device and the line to optimise for — so read the mobile tab and the field-data panel in PageSpeed Insights, not just the lab gauge, and open your own site on your phone off WiFi and count the seconds until you can read the headline. Fix for the slowest realistic visitor and everyone faster comes along for the ride.

What I'd actually do, start to finish

If it were my site: compress and right-size the hero and the heaviest images first, and make sure the hero isn't lazy-loaded. Install one reputable caching plugin, turn on page caching, and put Cloudflare's free tier in front. Then go through the plugins, stop the ones that don't belong on a page from loading there, and self-host the fonts. Re-test on the mobile tab, watch the field data over the next couple of weeks, and stop the moment it's green. That's the whole job — an afternoon's work in the right order, not a renovation. PageSpeed is one piece of the picture; our guide on how to show up in AI search covers how speed, content and rankings fit together, and once the site's fast it's worth getting your spare domains pointed at the main site the right way.

Done all that and your WordPress site still drags? That's usually a theme or page builder doing far too much, or hosting that's slow before a single image loads — worth a proper look rather than another plugin. We'll read your real Lighthouse and field data, tell you straight which fixes will help yours, and sort it without selling you gear you don't need. Send us your site's address and we'll tell you where the time is going.

Frequently asked questions