Which plugin is slowing down my WordPress site? Measure it instead of guessing

#Why guessing does not work

Every slow WordPress site produces the same conversation: someone disables plugins one at a time, reloads the page, and declares a culprit. It rarely holds up. A single reload is dominated by noise (the server's other tenants, a cold object cache, a lucky or unlucky database moment). Plugins that only run in wp-admin get blamed for front-end slowness. And the real cost of a plugin is often not its PHP at all but the 800 KB of JavaScript it ships to every visitor, which no amount of reload-and-guess will reveal.

Measuring properly means repeated, interleaved timings, medians rather than single numbers, and a confidence band that says when the answer is not clear. That is what Dragon Speed Doctor does, and it is the successor to the much-missed P3 Plugin Performance Profiler, rebuilt with those rules.

#First, split the problem in two

There are two different kinds of slow, and they have different causes.

Server time (time to first byte). The gap between the request and the first byte of HTML. This is PHP, database queries and plugin bootstrap. Measure it from your own machine:

curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s  total: %{time_total}s\n" https://example.com/

Run it a few times. Anything over about 600 ms uncached, or over 200 ms with a page cache, is worth investigating on the server side.

Front-end weight. The HTML arrives quickly but the page takes seconds to become usable because of scripts, stylesheets, fonts and images. Your browser's Network tab, or a Lighthouse run, shows this. Plugins contribute here by enqueueing assets on every page whether the page uses them or not.

Speed Doctor measures both: per-plugin server time, and an asset audit that attributes every script and stylesheet on your pages to the plugin that ships it.

#Run the doctor

1. Install the plugin and open Tools, then Speed Doctor.
2. Press the button to install the measurement loader. This is a small must-use helper that lets the doctor load the site without a given plugin, for its own cryptographically signed internal requests only. Visitors are never affected, and it is removed automatically when you deactivate the plugin.
3. The pre-scan check confirms the site can be measured: loopback requests are allowed, a page cache is not answering the test requests, and no background jobs are running that would add noise. Fix anything it flags first; a scan under a page cache measures the cache, not the plugins.
4. Run a diagnosis. It takes a few minutes. The doctor times the site repeatedly with each plugin left out of its internal test requests only, interleaving the runs, discarding warm-up passes, and stopping early once a result is clear.

If you prefer the terminal or want to schedule it, wp speed-doctor scan does the same thing.

#Reading the results honestly

Each plugin gets a verdict in plain English: "Adds about 180 to 260 ms to page loads", with a Low, Medium or High impact badge, sorted worst first. Read them with these in mind:

• Ranges, not points. The doctor reports what it measured with a confidence band. A plugin at 40 to 60 ms is a real cost; one at 0 to 30 ms is in the noise.
• Front end and wp-admin are separate. A plugin that adds 300 ms to the editor and nothing to public pages is an annoyance for you, not a problem for visitors.
• "Inconclusive" is a result. When server noise is bigger than the differences it is trying to measure, the doctor says so rather than inventing a number. Re-run at a quieter time.
• Dependencies are measured together. A WooCommerce payment gateway cannot be tested without WooCommerce, so the pair is measured as a unit and labelled that way. Do not read that as the gateway being expensive on its own.

Then open the asset audit. It lists every script and stylesheet on your sampled pages with sizes and render-blocking flags, attributed to the plugin that enqueued it. This is where the "fast PHP, heavy page" plugins show up. And check the database signals: the size of autoloaded options, with probable owners. Every request loads all of them; a few megabytes here is a slow site with no obvious cause.

#What to do with what you find

• Heavy and unnecessary: deactivate and delete. Inactive plugins still get updated and still count against you in other ways.
• Heavy and necessary: look for a lighter equivalent, or check its settings. Many plugins have an option to load their assets only on the pages that use them.
• Assets on every page: if the plugin does not offer a scope setting, a small snippet with wp_dequeue_script on the pages that do not need it is often the whole fix.
• Autoload weight: usually one or two plugins storing large transients or logs as autoloaded options. Clear their caches or set retention, and consider a persistent object cache.
• Everything is slow, evenly: the host, not a plugin. Profiling cannot fix a server that is overloaded or a database on spinning disks.

#Prove it with a second scan

Make one change at a time and re-run. The doctor keeps a rolling history and shows a before and after comparison, so you can see that removing the slider plugin took 200 ms off the front end rather than believing it did. It is also the right habit around plugin updates: scan before, update, scan after, and you will catch the release that quietly doubled its cost.

#Related reading

Server time and dead links are the two most common ways a site rots between redesigns. Once the timings are under control, run the broken links guide too.