Most advice about WordPress speed starts with “install a caching plugin”. Sometimes that works. Often it papers over the real problem, and you end up with a fast-looking homepage and an admin area that still takes eight seconds.
Measure first. WordPress sites are slow for a handful of well-understood reasons, and they leave clear fingerprints. Here’s how to find yours.
Where the time actually goes
Slowness has three separate sources, and the fix for one does nothing for the others.
| Source | Symptom | Typical cause |
|---|---|---|
| Server response | Long wait before anything appears | Bloated database, heavy plugins, no object cache, cheap hosting |
| Payload size | Slow to finish, especially on mobile | Unoptimised images, too many scripts and stylesheets |
| Rendering | Visible but janky, content jumping | Render-blocking assets, layout shift, heavy web fonts |
Caching plugins mostly help the first. If your problem is a 4MB hero image, caching it just serves the same 4MB faster.
The quickest way to tell them apart: load a page and watch time to first byte versus total load time. A slow TTFB is a server-side problem. A fine TTFB with a slow finish is a payload problem.
The usual culprits, in the order they’re usually guilty
1. Autoloaded options
WordPress loads every option marked autoload on every single request, including admin pages and AJAX calls. Plugins add to this table and frequently don’t clean up when removed.
A healthy site has a few hundred KB of autoloaded data. Sites that have run for years with plugins coming and going routinely have several megabytes, being read from the database before a single line of your page renders.
This is the highest-value thing to check and the least talked about, because no caching plugin fixes it.
2. Post revisions and database bloat
WordPress keeps every revision of every post forever unless told otherwise. A page edited 60 times stores 60 copies. Multiply across a content site and wp_posts becomes enormous, slowing every query that touches it.
Related: expired transients that never got cleaned, orphaned postmeta from deleted plugins, and spam comments nobody emptied.
3. Too many plugins, or one bad one
Plugin count matters less than people think. One badly written plugin running a query on every page load hurts more than twenty well-behaved ones.
The tell is a plugin that adds work to requests it has no business touching, like a contact-form plugin loading its assets on every page rather than the one with the form.
4. No object cache
Without persistent object caching, WordPress recomputes the same queries on every request. Redis or Memcached lets it remember between requests. On a database-heavy site this is often the single biggest win, and it’s invisible to page-speed tools that only measure the front end.
5. OPcache disabled
PHP recompiles your code on every request unless OPcache is on. It’s usually enabled on decent hosting and usually off on cheap shared plans. Free to fix if you have the access.
6. Cron backlog
WordPress runs scheduled tasks by piggybacking on visitor requests. If tasks pile up, some unlucky visitor pays the cost of running them. A large backlog means someone is regularly waiting on work that should have happened in the background.
Diagnosing without guessing
The manual route: install Query Monitor, load a slow page, and read where time goes. It’s excellent and it’s the standard answer.
The faster route, if you have an AI agent connected via a WordPress MCP server, is to ask for a report. EMCP’s analyze-performance tool audits the things above in one pass, server configuration, database size, autoloaded options, revisions, cron backlog, object cache, OPcache, plugin count, plus a target page, and returns a scored report with ranked recommendations.
You: Why is this site slow?
AI: analyze-performance({ url: "https://example.com/" }) → Score 61 (D) • 3.2 MB of autoloaded options (critical) • 4,180 post revisions (warning) • No persistent object cache (warning) • 1.8 MB hero image (warning)The value isn’t the scoring. It’s that the answer is specific to your site rather than a generic checklist, and it’s ranked, so you know what to do first.
Fix in this order
- Autoloaded options. Biggest hidden win. Find the large ones and remove what’s orphaned.
- Database cleanup. Limit revisions going forward (
WP_POST_REVISIONS), then clear the backlog, expired transients, and spam. - Object cache. If your host offers Redis, turn it on. Frequently a bigger improvement than any plugin.
- Images. Resize to actual display size, serve WebP, and load below-the-fold images lazily. Usually the single largest payload win.
- Audit plugins. Find the ones loading assets everywhere. Replace or scope them.
- Then cache. Once the underlying work is smaller, caching multiplies a good result rather than hiding a bad one.
Caching last is deliberate. Cache a slow site and you’ve hidden the problem from yourself, right up until you hit a page that can’t be cached, like a cart or a logged-in view.
What “fast enough” means
Chasing a perfect score is a poor use of time. Useful targets:
- TTFB under 600ms
- Largest Contentful Paint under 2.5s
- An admin area that feels instant, because that’s where you actually work
That last one gets ignored because page-speed tools don’t measure it. If wp-admin is sluggish, you have a server-side problem that front-end caching will never touch, and it’s costing you time every single day.
Related reading
- Performance Analyzer — what the audit actually checks
- Is my WordPress site hacked? — sudden slowness has one other cause worth ruling out
- What is a WordPress MCP server? — running diagnostics through an AI agent