Why Your WordPress Site Is Still Slow After Installing Every Cache Plugin

You installed Smush, a caching plugin, Autoptimize, maybe WP-Optimize for the database. Your PageSpeed score went up a bit. And the site still feels slow, especially in wp-admin. I run into this all the time.

Don’t start deleting plugins at random. That usually breaks something and doesn’t fix the speed anyway. The real problem is almost always the backend, and cache plugins can’t reach it. That’s the part I want to walk through.

One thing first: measure your site before you change anything. I won’t repeat it here, the WordPress Performance Boost guide covers PageSpeed, Pingdom and GTmetrix. Get your numbers, then come back. If you never measured, you won’t know whether a fix actually did anything.

Frontend vs backend, and why it matters

Almost every WordPress speed guide is about the frontend. That’s half the story, and usually not the half that’s slowing you down.

Frontend is everything that happens after the server finishes its work. Compressing images, caching finished pages, minifying CSS and JS. That’s Smush, your cache plugin, Autoptimize. Good stuff, worth doing.

Backend is everything before that. WordPress boots, loads its options, hits the database, runs your plugins’ queries, builds the page. If that part is slow, caching won’t save you, because the first visitor and every logged-in user still pays full price. So does every click in wp-admin.

Quick way to tell you’ve got a backend problem: the site feels slow even though everything’s cached, and wp-admin drags. Admin pages are almost never cached, so they show you the real speed.

The five things that are usually to blame

Backend slowness almost always comes down to the same short list. I’ll go through them in the order I usually find them.

1. Autoload bloat

On every request, WordPress reads a pile of options from the database that are set to autoload. A few hundred KB is fine. The problem is plugins that dump big blobs in there and never clean up, even after you delete them. I’ve seen sites carrying several megabytes of autoloaded junk on every single page load. You pay for that constantly.

2. Slow database queries

One bad query from one plugin can add hundreds of milliseconds to every page. PageSpeed won’t show it, because PageSpeed looks at the finished page, not the time your database spent grinding through an unindexed lookup. Related posts, analytics, and old membership or shop plugins are the usual offenders.

3. No persistent object cache

WordPress caches query results, but by default only for one page load. Then it throws them away and does the same work again for the next visitor. A persistent object cache (Redis or Memcached) keeps them between requests. On a query-heavy site it’s often the biggest single win. Most people skip it because it sounds scary. It isn’t.

4. wp-config left on defaults

Out of the box, WordPress keeps every post revision forever, runs cron on every visit instead of on a schedule, and often has debug logging left on in production. Each one is small. Together they add up, and the revisions quietly bloat your database for years.

5. A runaway debug.log

This one’s sneaky. You turn on WP_DEBUG_LOG to check something, forget about it, and months later debug.log is 2 GB of repeated PHP notices, written to on every request. I’ve seen it take a site down.

How to find them without guessing

This is where most guides fall apart. They give you the list and say “go fix it”. But how do you know which of these you’ve actually got, or how bad? Digging through phpMyAdmin and reading wp-config.php by hand is exactly the scary, error-prone stuff that made you avoid the backend in the first place.

So don’t guess. Run a health check and let it tell you.

The tool I use for this is WP Multitool. It’s built for the backend layer. Their line is “most optimization plugins guess, this one runs EXPLAIN“, which basically means it asks the database which queries are slow instead of hand-waving. You install it like any plugin, open the dashboard, and get a plain report of what’s actually wrong. No SSH, no SQL. There’s a free scan too, if you just want to see what it flags.

The modules line up with the list above:

• Autoload: the Autoloader Optimizer shows your total autoload size and which options are the worst, so you can clear the orphaned junk.
• Slow queries: the Slow Query Analyzer profiles what’s running (the EXPLAIN part) and names the plugin behind it.
• Object cache and database: the Database Optimizer handles cleanup and getting a persistent cache working.
• wp-config: the Config Manager checks revisions, cron and debug settings and flags the risky ones.
• debug.log: the Debug Log Guard catches and caps a bloated log before it hits gigabytes.

That’s 5 of its 18 modules. The rest score each plugin’s performance impact, find slow callbacks, and so on. But those five are where the fast wins are.

The tool matters less than the workflow. Measure, get a diagnosis, then fix. Walk into the backend knowing what’s slow, instead of poking around and hoping you don’t break anything.

Fix it, then measure again

Once you know what you’re dealing with, the fixes are usually quick:

• Clear the orphaned autoload options the scan flagged.
• Turn on a persistent object cache, if your host has Redis.
• Cap revisions in wp-config.php: define('WP_POST_REVISIONS', 5);
• Delete or rotate debug.log, and turn WP_DEBUG_LOG off in production.
• Deactivate or replace the plugin behind the slow query.

Then measure again. Same tools, same conditions as before. Backend fixes often don’t move your PageSpeed score much, because that’s a frontend number. What they move is TTFB and how the site feels, especially in wp-admin. Watch those.

Do both

Both halves matter. The frontend plugins handle what the browser sees. The backend work handles everything before the browser gets involved. A cache plugin sitting on top of a bloated, mis-tuned backend is just hiding the problem.

The backend part is less scary than it looks once you stop guessing and let a health check do the diagnosis. Run it, fix what it flags, measure again. Do that once and a slow WordPress site usually stops being slow.

If you do one thing after reading this, run a backend health scan before you touch anything else. You’ll probably be surprised what’s been dragging the site down.