Installed a Caching Plugin and WordPress Is Still Slow?

Why Installing a Caching Plugin Didn't Fix It

A page cache stores finished HTML and serves it to the next anonymous visitor without booting WordPress at all. That is a real win for public traffic - but the cached page is the output, not the work. Whatever made that page slow still runs every time the cache cannot serve it.

The Pattern

The speed test goes green for logged-out visitors. Your own clicks - logged in, inside wp-admin, inside the cart - feel exactly as slow as before, because for you nothing is cached. The plugin is doing its job. The job is just narrower than the problem.

So the cache can be working perfectly and the site still feels slow everywhere that matters to you. The question stops being "is the cache working" and becomes "what is still running underneath it."

What a Page Cache Cannot Touch

Cache plugins are honest about this in their docs - they just lead with the benchmarks. These are the places a page cache never applies, and the work that keeps running inside them:

What is slow	Why the cache misses it	Which module sees it
wp-admin screens	The admin is never cached - every click boots WordPress and runs every plugin's admin hooks	Slow Query Analyzer, Find Slow Callbacks
Logged-in frontend	Personalized pages bypass the cache for every signed-in user - members, customers, editors	Find Slow Callbacks
Cart, checkout, my account	Excluded by design - caching them would leak one customer's data into another's page	Find Slow Callbacks, Slow Query Analyzer
Slow database queries	The cache stores the result; the query still runs on every miss and every uncached page	Slow Query Analyzer
Autoloaded options	The wp_options autoload set loads before WordPress renders anything - cached or not	Autoloader Optimizer
Slow plugin callbacks	An 800ms admin_init hook fires on every uncached request the PHP app produces	Find Slow Callbacks
External HTTP calls	Update checks, license pings and telemetry fire inside the request, behind the cache	External Call Optimizer

First: Is the Cache Actually Working?

Before blaming the code underneath, confirm the cache caches at all. Site Doctor fires a loopback request at your own site and reads the real cache header the server sends back - HIT, MISS or BYPASS - instead of trusting the plugin's own settings page. A homepage that answers BYPASS gets reported as info, not as a failure, because the homepage is the page most often excluded on purpose.

It also reads the settings of your other active optimizers and lists only what is switched on in both places - the classic "two plugins doing the same minify" situation - so you can pick one owner per job instead of paying for the work twice.

What Stays Slow After the HTML Is Cached

Slow database queries. Slow Query Analyzer logs the queries that cross its threshold, runs MySQL EXPLAIN on the request that logged them, and suggests ready-to-run index fixes
Autoload bloat. Autoloader Optimizer ranks your biggest autoloaded options and disables autoload on the offenders - on sites with a real object cache the gain shrinks, and it says so
Slow plugin callbacks. Find Slow Callbacks profiles one URL per request and ranks every callback over 10 milliseconds by time, with the hook and the source file that registered it
External HTTP calls. External Call Optimizer clamps proven-chatty third-party hosts to a sane timeout and briefly caches repeated GET/HEAD polls - payment and checkout calls are never touched

To Be Clear: WP Multitool Ships No Page Cache

Keep your caching plugin

It handles the anonymous-visitor part. WP Multitool handles the uncached part underneath - the queries, autoload, callbacks and outbound calls that decide how fast the uncached render is. Site Doctor's overlap check exists precisely because the two jobs are different; it even lists page-cache-only plugins as non-conflicting.

Where to Start

Run Site Doctor. One scan: the page-cache probe, Redis checks, configuration, database bloat, autoload and overlapping optimizers. Read-only - nothing changes until you say so.
Check the queries. Open Slow Query Analyzer and EXPLAIN the worst offenders it captured.
Audit the autoload. If the scan shows a bloated wp_options autoload set, let Autoloader Optimizer rank it.
Profile what is left. Point Find Slow Callbacks at the still-slow URL and read the name of the function costing you.
Clamp the phone-home. If the callbacks show external HTTP, let External Call Optimizer put the chatty hosts on a timeout.

Caching Didn't Fix It FAQ

I installed a caching plugin - why is my WordPress site still slow?

A page cache speeds up repeat views for anonymous visitors only. wp-admin, logged-in sessions, cart and checkout, and every cache miss still run full PHP - and whatever makes that render slow (queries, autoload, callbacks, external calls) keeps running underneath the cache.

Does WP Multitool replace my caching plugin?

No - it ships no page cache at all. Keep your cache for anonymous traffic; WP Multitool diagnoses and fixes the uncached work underneath it. Site Doctor even checks for optimizations two plugins are doing at once.

Why is my site only slow when I am logged in?

Because the page cache deliberately skips you. Every signed-in user gets a fresh PHP render, so you feel the site's real speed - the queries, autoloaded options and plugin callbacks that anonymous visitors never wait for.

Why is WooCommerce checkout slow even with caching on?

Cart, checkout and my-account are excluded from page cache by design - caching them would serve one customer's data to another. Their speed is the speed of the uncached render: the queries and plugin callbacks running on those requests.

How do I know if my caching plugin is actually working?

Site Doctor fires a loopback request at your own site and reads the cache header the server really sends - HIT, MISS or BYPASS - rather than trusting the plugin's dashboard. A BYPASS on a page you meant to cache tells you the rule is wrong, not that the cache is broken.

Can two optimization plugins conflict with each other?

Yes - two plugins minifying the same files or optimizing the same images is a common way to make things worse. Site Doctor reads the settings of your other active optimizers and reports only what is switched on in both places, so you can pick one owner per job.