Your site got slow. You installed a caching plugin. It didn't help.
That's usually a plugin running expensive code on every request, before the cache even has a say. Caching can't touch that. Admin pages, logged-in users, WooCommerce carts, the REST API. None of that is cached. So a heavy plugin drags all of it down. I wrote a whole post on why caching plugins don't fix a slow WordPress if you want the long version.
The hard part is knowing which plugin. You've got 22 active. Deactivating them one by one is slow and it breaks the site for real visitors while you test. I've done that dance on client sites. It's miserable.
Here's how I actually find the guilty plugin. Manual first, so you understand what's going on. Then the faster way.
Start with the total, then the breakdown
Before you blame anything, measure your baseline. TTFB (time to first byte) is the number that matters here. It's how long the server takes to start sending the page.
Open your browser dev tools, Network tab, reload the homepage. Click the document request, look at Timing. If TTFB is over 600ms on a warm cache, something server-side is slow. Plugins are the usual suspect.
Now you need per-plugin numbers. The free tool for this is Query Monitor. Install it, activate it, load a page as an admin. In the admin bar you'll see a menu with timing. Open it and go to "Queries by Component". This groups every database query by the plugin that fired it, with time totals.
That view alone tells you a lot. If one plugin ran 340 queries and burned 180ms, you found a candidate.
Confirm it with a real profile
Query Monitor shows database time well. It's weaker on pure PHP time, the CPU a plugin spends not touching the database. Some plugins are slow because they loop over options, parse big arrays, or call external APIs on every request.
To catch those you profile the PHP itself. The honest way is a profiler like Xdebug or Tideways. Xdebug is free. You enable it in php.ini:
xdebug.mode=profile
xdebug.output_dir=/tmp/xdebug
xdebug.start_with_request=trigger
Load a page with the trigger, then open the resulting cachegrind file in a tool like QCacheGrind or KCachegrind. You get a call tree. Sort by "self" time. Follow the expensive branches and you'll see the plugin's namespace show up, WooCommerce, Elementor, whatever it is.
This works. It's also fiddly. You need shell access, you need to install the extension, you need a desktop app to read the output, and cachegrind files get huge fast. On shared hosting you often can't do any of it.
There's a quick sanity check that needs no profiler. The Health Check & Troubleshooting plugin (from the WordPress team) has a troubleshooting mode. It disables all plugins for your session only, not for real visitors. You then re-enable them one at a time and watch TTFB. When the number jumps, that's your plugin.
It's the cleanest manual method because it doesn't take the live site down. But it's still one plugin at a time, and it only tells you PHP is slower, not why.
Where the slowness actually hides
Once you've narrowed it to a plugin, the real cause is usually one of three things.
Slow queries. The plugin runs a SQL query with no index, so MySQL scans the whole table. On a small site you never notice. At 80,000 posts it's 400ms. You confirm this by running EXPLAIN on the query. If the type column says ALL and rows is a big number, it's doing a full table scan. I wrote a separate post on reading EXPLAIN output if that part is new to you.
Autoload bloat. WordPress loads every option marked autoload = yes on every single request. Plugins dump settings, transients, and cached blobs in there and never clean up. Check it:
SELECT SUM(LENGTH(option_value))
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto');
WordPress 6.6 changed these values, older cores still use yes/no. Anything over about 800KB and you'll feel it. I've seen 6MB of autoloaded junk on sites that "felt slow for no reason".
External calls. The plugin phones home, checks a license, or pulls a feed on page load, with no timeout. One slow remote server and your TTFB is hostage to it.
The faster way
Here's where I'll be straight with you. Doing all of the above properly means Query Monitor plus Xdebug plus a cachegrind reader plus manual SQL, stitched together by hand. It's a good skill to have. It's also an afternoon per site, and I do this across a lot of client sites.
So I built WP Multitool to collapse that whole workflow into one dashboard. It's a paid plugin, $79 a year or $499 for a lifetime license. I'm telling you that up front because the manual route above is genuinely free and it works. Buy the tool when your time is worth more than the afternoon.
What it does for this specific problem. It profiles every active plugin and shows you the real load cost of each one, PHP time and query time together, ranked - that per-plugin performance score is the number you're really after. No cachegrind files, no desktop viewer. For the slow queries it finds them and runs EXPLAIN for you, so you see the full-table-scan offenders without writing SQL by hand. It measures autoload size and shows what's bloating it. It reads object cache and HPOS state, so the numbers reflect how your site actually runs, not a fake environment.
The tagline I use is "most optimization plugins guess, this one runs EXPLAIN". That's the honest difference. A lot of speed plugins just toggle caching and hope. This one actually measures what's slow and shows you the numbers.
It replaced about ten separate plugins I used to string together, and it's aimed at people running more than one site, agencies especially, where doing this manually every time doesn't scale.
What to do next
If it's one site and you've got time, go the manual route. Query Monitor for the query breakdown, Health Check troubleshooting mode to isolate the plugin, EXPLAIN and the autoload query to find the root cause. You'll learn your site in the process, and that knowledge sticks.
If you're doing this weekly, or you want the whole profile in one screen, that's what WP Multitool is for.
Either way, stop deactivating plugins at random. Measure first. The slow one always shows up in the numbers, and once you've seen its real cost, you stop guessing about your site for good.