The Caching Trap
Your WordPress site loads in 4 seconds. You Google "speed up WordPress," install WP Super Cache or W3 Total Cache, and... it loads in 3.8 seconds.
What happened?
Caching works by storing a rendered copy of your pages so the server doesn't rebuild them on every request. That's useful when the rendering is the bottleneck. But for most slow WordPress sites, it isn't.
The bottleneck is in the database.
Where WordPress Actually Spends Its Time
On a typical page load, WordPress runs 30 to 200+ database queries. Each query hits MySQL, which looks up data, joins tables, and returns results. On a well-tuned site, this takes 50ms total. On a neglected site, it takes 2-5 seconds.
Caching skips this entirely for repeat visitors — but it doesn't fix the underlying problem. And there are plenty of scenarios where cache doesn't help:
- Admin pages — never cached
- Logged-in users — most caching plugins skip them
- WooCommerce carts — dynamic, uncacheable
- First-time visitors — cold cache, full query load
- AJAX requests — usually bypass cache
- REST API calls — typically uncached
So even with caching, your slow queries still run. A lot.
The Three Database Problems Nobody Talks About
1. Missing Indexes
WordPress core tables have sensible indexes, but plugin developers often create custom tables without them. When MySQL can't use an index, it scans the entire table row by row. That's called a full table scan, and on a table with 100,000 rows, it turns a 2ms query into a 2-second query.
The fix: run EXPLAIN on the slow query, check if it says type: ALL (full scan), and add the right index.
2. The Autoload Problem
Every WordPress page load runs this query:
SELECT option_name, option_value FROM wp_options WHERE autoload = 'yes'
This loads every option flagged as autoload into memory. On a fresh WordPress install, that's maybe 100KB. After two years and 30 plugins, it can be 5MB or more. That's 5MB of data loaded into PHP memory on every single request — cached or not.
The worst part: most of this data is orphaned. Plugins that were deleted months ago left their options behind with autoload still set to 'yes'.
3. Orphaned Data
WordPress accumulates garbage:
- Post revisions — 50 revisions per post, forever
- Expired transients — temporary cache entries that outlive their expiry
- Orphaned postmeta — metadata pointing to deleted posts
- Spam comments — sitting in the database, taking up space
- Old cron events — scheduled tasks that never got cleaned up
This data doesn't just waste disk space. It makes queries slower because MySQL has more rows to scan, more indexes to maintain, and more memory to manage.
What Actually Fixes a Slow WordPress Site
Find the slow queries — not all queries, just the slow ones. Run
EXPLAINon each and look for full table scans, missing indexes, and unnecessary joins.Clean the autoload table — identify which autoloaded options are actually needed. Set the rest to
autoload = 'no'.Remove orphaned data — delete old revisions, expired transients, orphaned metadata, and spam.
Add missing indexes — if a query scans 100,000 rows but only needs 10, an index makes it instant.
Then add caching — now it's the cherry on top, not a band-aid.
Doing This By Hand Is Painful
Running EXPLAIN on individual queries, auditing wp_options autoload values, cleaning orphaned data — it's doable, but it takes hours. And you need to know what you're looking at.
That's why I built WP Multitool. It has a Slow Query Analyzer that runs MySQL EXPLAIN automatically, scores each query's health, and suggests the exact CREATE INDEX statement to fix it. The Autoload Optimizer shows you which options to disable. The Database Optimizer cleans orphaned data in one click.
14 modules. $50 lifetime. No subscription, no external API calls, no data leaving your server.
Caching is great. But it should be your last optimization step, not your first.
Originally published at WP Multitool Blog.
Find what's slowing your WordPress. WP Multitool — 14 modules, $50 lifetime, zero bloat. Built by Marcin Dudek.
Top comments (0)