How to Speed Up WordPress

Slow WordPress is rarely mysterious: the same five weights — unoptimised images, plugin sediment, theme bloat, missing caching, tired hosting — explain almost every sluggish install, and they're fixable in a long afternoon without touching code. This is the general speed discipline as a WordPress-specific procedure, ordered by impact-per-hour, with the measurement loop that proves each step paid.

Step 0: Baseline before touching anything

PageSpeed Insights on the homepage, a post, and your heaviest template — field data where available, lab diagnostics for the culprit list — plus a waterfall look (any browser dev-tools) at what actually loads. The named LCP element and the largest scripts are your work order; optimisation without a baseline is the redecoration the testing doctrine warns about.

The fixes, in impact order

1. Caching on (the transformation): a page-caching plugin (the roundup picks by situation — or your host's built-in layer, which increasingly exists and wins) turns every anonymous view from PHP-and-database work into a served file — routinely halving TTFB on shared hosting. One cache only, configured once, per the one-tool rule.
2. Images industrialised: the optimizer pipeline — compression, WebP, correct sizing automated at upload, lazy-loading native (WordPress does it by default now; verify the LCP image is excluded, per the eager-hero rule) — plus the one-time bulk pass over the existing library.
3. The plugin purge: the quarterly audit run honestly — deactivate-and-delete the unused, replace the heavy (query-monitor-class tools name the expensive ones), and interrogate every "just in case" survivor: each is PHP on every load, scripts on every page, per the subtract doctrine.
4. Script hygiene: defer what isn't render-critical (caching plugins bundle this), load chat/analytics/embeds on interaction or delay, host fonts locally with font-display: swap — the INP and render-blocking work in WordPress clothes.
5. Theme reckoning: if the baseline names theme assets as the weight (builder frameworks are the usual suspects), the options in cost order — the theme's own performance settings, an asset-cleanup plugin unloading per-page, or the replacement decision when tuning can't save it.
6. Hosting honesty: if TTFB stays slow with caching on, the server is the floor — the upgrade math: modest managed/VPS tiers transform sites that outgrew shared oversell.
7. The CDN finish: assets served from edges — most caching plugins and hosts integrate one in minutes.

The verification loop

Re-measure after each step (not all at once — attribution teaches what your site actually needed), confirm in field data over the following weeks via Search Console's CWV report (the lab-vs-field rule: green field metrics are the finish line, lab 100s are decoration), and add the regression guards: new plugins profiled before adoption, the quarterly purge calendared, and the baseline re-run after major updates — speed decays by accretion, per the whole audit philosophy.

Frequently asked questions

Which single step should I do if I only have an hour?

Caching plus the LCP-image fix — the pair that moves both TTFB and LCP, typically the two failing metrics, in under an hour on any install. The purge is the best second hour ever spent.

Do I need a premium speed plugin or will free do?

Free covers the fundamentals (caching, basic optimisation) genuinely well; the premium suites earn their fee on convenience and the long tail (critical CSS automation, better exclusion controls) — worth it for site owners who'd otherwise not do those steps, redundant for tinkerers, per the buy-what-you'll-use rule.

Will these fixes improve my rankings directly?

The threshold answer: escaping red field metrics pays; polishing past green doesn't — and the conversion/bounce effects pay regardless, which is the honest business case. Speed is the floor swept; the contest above it stays content and authority (our contest).