How to speed up a WordPress site

WordPress isn’t slow. Neglected WordPress installs are slow — and since roughly every install accumulates plugins, oversized images, and database sediment over the years, the reputation stuck. The good news is that WordPress slowness is boringly diagnosable. Resist the classic mistake of installing a “speed plugin” as step one; that’s a fix in search of a diagnosis. Find out where the time goes first.

1. Find out which half is slow

Load a page and look at where the time is spent (the site speed guide covers measurement properly). One number splits the problem in two: time to first byte — how long the server thinks before responding.

• Slow first byte means backend: PHP, database queries, plugins, hosting, missing page cache.
• Fast first byte, slow page means frontend: images, scripts, fonts, theme weight.

The fixes for each half don’t overlap, which is why guessing wastes so much time. Test both a rarely visited page and a popular one — if the popular page is fast and the rare one is slow, you’re mostly looking at a caching story.

2. Get the platform basics right

Open Tools → Site Health in the WordPress admin. It’s easy to ignore and quietly useful: it flags an outdated PHP version, missing PHP extensions, and disabled scheduled tasks. Running a current, supported PHP release is the cheapest backend win available — newer PHP releases are meaningfully faster, and the upgrade usually costs one support ticket or a click in the hosting panel. While you’re there, confirm with your host that OPcache is enabled; it usually is, but it’s worth one question.

If the site is on hosting that was sized years ago, check the fit — the hosting guide covers what actually matters for a busy CMS (database performance and request capacity, not advertised bandwidth).

3. Cache pages — the big one

Without a page cache, WordPress rebuilds every page from PHP and database queries for every single visitor. For anonymous traffic — which for most sites is nearly everyone — that work is identical every time, and caching it is the largest single improvement available. Use your host’s page cache if it offers one, or one well-regarded caching plugin if not. One. Two caching plugins don’t cache twice as hard; they conflict.

Know the limits: logged-in users, carts, and checkouts bypass page caches by design. If your slow pages are exactly those, caching isn’t your fix — the backend work itself is, which brings us to plugins.

4. Audit plugins and the theme

Plugin count matters less than plugin quality — one badly written plugin can outweigh twenty tidy ones. Instead of guessing, measure: a profiling plugin such as Query Monitor shows which plugins and queries eat the time on a slow page. Deactivate suspects one at a time on a staging copy and re-measure; the numbers end debates that opinions can’t.

Themes deserve the same scrutiny. Heavyweight multipurpose themes and page builders ship features you’ll never use on every page you serve. You don’t need to rebuild the site today — just know what the theme costs, so the next redesign makes it a criterion.

Remove what’s deactivated. Disabled plugins don’t slow the site, but they’re unpatched code waiting for the wrong kind of attention.

5. Fix the media library

Everything in the image optimization guide applies doubly to WordPress, because editors upload camera-original photos straight into posts. Right-size and compress on upload — automatically, via the media pipeline or a plugin, because a workflow that relies on editors remembering will not survive contact with a deadline. Recent WordPress versions lazy-load most images automatically, so your job is mainly the file sizes themselves, plus making sure the hero image at the top of the page isn’t lazy-loaded.

6. Object cache and database sediment

Two backend items pay off for dynamic sites:

• A persistent object cache (Redis or Memcached, where hosting supports it) saves repeated database lookups between requests. WooCommerce and membership sites — the ones page caching can’t fully help — benefit most.
• Database cleanup. Post revisions, expired transients, and orphaned tables accumulate for years. Special mention goes to autoloaded options: WordPress loads every option marked “autoload” on every request, and plugins that came and went often leave megabytes behind. Query Monitor will show you; clean up on staging first, with a fresh backup either way.

7. Re-measure, then stop

Make one change at a time and re-measure under the same conditions — it’s slower than heroics and it’s the only way to know what worked. When the numbers are good, stop. A CDN for static assets is a sensible final layer, but chasing the last few points of a lab score past the point visitors can feel it is how sites end up with five optimization plugins and a new problem.

Sources and further reading

• WordPress Advanced Administration: Optimization
• web.dev: Optimize Time to First Byte
• web.dev: Optimize Largest Contentful Paint