What 40 plugins actually cost in milliseconds

Every few weeks someone sends me a WordPress site with the same sentence attached: we have too many plugins. Sometimes there are forty. Occasionally there are sixty. The number is almost never the thing that is wrong.

A plugin that adds a shortcode you use on one page costs nothing on the other ninety-nine. A plugin that enqueues its own stylesheet, its own copy of jQuery and a font from a third-party host costs you on every single page, whether or not you ever use the feature. Two plugins, same count, wildly different bill.

Measure the page, not the plugin list

The first thing I do is stop looking at the plugins screen and open the network waterfall on the slowest page. Not the homepage — the slowest page, which on a store is usually a category page and on a services site is usually the one with the contact form.

What I am looking for is the shape of the waterfall, in this order:

• Time to first byte. If the server takes 1.5 seconds to say anything at all, no amount of image work will save the page. That is PHP, the database, or the host.
• Render-blocking requests. Every stylesheet and every non-deferred script in the head is a wall the browser has to get through before it paints.
• Third-party hosts. Each new domain is a DNS lookup, a TCP handshake and a TLS negotiation before a single byte of content moves. Three of them in the head is often half a second on a phone.
• Total bytes, split by type. Usually images, and usually because nobody ever resized them.

Then attribute the cost

Query Monitor is the tool that turns "the site is slow" into "this plugin is slow". It breaks a page render down by hook, by query and by component, and it names the plugin responsible for each. On a typical slow WordPress homepage a small number of components account for most of the server time, and they are rarely the ones anyone suspected.

The patterns that come up again and again:

• A slider or page-builder module loading its full asset bundle on every page because the theme registers it globally.
• A related-posts or popular-posts widget running an uncached query with ORDER BY rand() against a large table.
• A security or analytics plugin writing a row to the database on every request, including bot requests, until the log table is the largest thing in the install.
• Two plugins that both bundle the same library, so the browser downloads it twice under two different filenames.

What I actually do about it

Deleting plugins is the last step, not the first. In order:

1. Stop loading what the page does not use. Conditionally dequeue the assets of plugins that only matter on specific templates. This alone often removes a third of the requests without removing a single feature.
2. Replace a plugin with the ten lines it was doing. A plugin whose entire job is adding a meta tag or a tracking snippet is a plugin, an update cycle and a settings page you are maintaining for ten lines of code.
3. Fix the query, not the symptom. A slow uncached query is usually slow because it is missing an index or because it should have been a transient. Caching the whole page on top of it hides the problem until the cache misses.
4. Serve images at the size they are displayed. Modern format, correct dimensions, explicit width and height so nothing shifts as the page loads.
5. Then delete what is left over. By this point the list of plugins that are genuinely unused is obvious, and removing them is uneventful.

The part nobody likes

Measure the same page, the same way, before and after. Same test, same connection, three runs, take the median. One run tells you nothing — the variance between two runs of the same page on the same host can be larger than the improvement you are trying to prove.

Every speed number on this site was produced that way, which is why the range is honest rather than flattering: sites that started above twenty seconds and finished under two, and sites that were already reasonable and finished under one. The method is the same. The starting point is what varies.