The site is stuck at 400 milliseconds TTFB, the admin panel opens slowly, and you can't remember the last time you deactivated a plugin. If the number of active plugins has passed twenty, the problem is probably neither the hosting nor the theme; it's the pile of code, each piece of which eats a few milliseconds from every request. WordPress plugin auditing means exactly this: measuring, not guessing.
Measure first, then delete
The first instinct of most admins is to open the plugin list and delete whatever seems "unnecessary" to them. This usually breaks the site and doesn't solve the speed problem either, because the most expensive plugin is often the one you think you need.
The right tool is Query Monitor. Install it, activate it, and open a page of your site. In the admin bar, you'll see the total time, number of queries, and memory usage. Click on the Queries section and look at the "Caller" column; each query shows which plugin or which theme file executed it. Now go to the "Components" section: Query Monitor shows the execution time of each plugin separately.
A practical tip: do this measurement on the homepage, a product or post page, and an archive page separately. The numbers differ, and a plugin that's innocent on the homepage might take half the time on the shop archive.
Reading the numbers
On a typical site on shared hosting, if the total plugin time is under 150 milliseconds, there's no cause for concern. Between 150 and 400 milliseconds, you have two or three heavy plugins. Above 400 milliseconds, the problem is structural and you need to make a hard decision. The number of queries also matters: over 100 queries for a page means there's a plugin that fires several dozen queries on every load.
If you don't know what these numbers are good or bad relative to, Website speed test; a guide to interpreting results and prioritizing fixes is a better starting point, because it measures TTFB from the outside and without the admin panel's bias.
Signs of an abandoned plugin
An abandoned plugin isn't necessarily slow; its danger lies elsewhere. Take these signs seriously:
- The last update in the WordPress repository was more than a year ago. WordPress itself shows this on the plugin page.
- You see the message "This plugin has not been tested with the current version of WordPress." That means the developer hasn't even updated the readme file.
- In the Advanced tab, the "Auto-updates" option is grayed out and disabled, because the plugin doesn't come from the official repository.
- The number of active installations is under 10,000 and the latest user feedback is from two years ago.
A plugin that has all four conditions is a security risk, even if it's fast. Here's where people make a mistake: the site admin deletes the abandoned plugin without checking whether a theme or another plugin depends on it. The result is a white screen or a Fatal error: Uncaught Error: Call to undefined function in the log. Before deleting, do a search to make sure the plugin's function names or shortcodes aren't used anywhere else.
Which to delete: a decision rule
Create three categories. The first category is plugins without which the site stops working: shop, contact form, backup. The second category is plugins whose job can be done with a few lines of code in functions.php or with WordPress's own capabilities. The third category is those that no one remembers why they were installed.
Delete the third category with peace of mind. Replace the second category one by one. Don't touch the first category, but if one of them takes over 100 milliseconds in Query Monitor, it's time to find a better replacement.
| Plugin status | Recommended action | Risk |
|---|---|---|
| Active, fast, up-to-date | Keep it | None |
| Active, heavy, up-to-date | Replace or reconfigure | Medium |
| Inactive, installed | Delete completely | Low |
| Active, abandoned | Delete after checking dependencies | High |
Deactivating isn't enough
An inactive plugin is still on disk, its files don't get updated, and if it has a vulnerability, an attacker can send requests directly to its files. Delete it, don't just deactivate it. Before deleting, back up the database; some plugins delete their tables when removed, and if you want to restore them later, the data is gone.
Turn auditing into a routine
A one-time audit becomes ineffective three months later. Every time you install a plugin, check right then in Query Monitor how much it adds to page time. If it's more than 50 milliseconds, instead of installing it, look for another way.
For sites with real traffic, do this on a staging environment, not on the live site. If you have a dedicated server or VPS, you can get a quick list with wp plugin list --status=active --format=table via WP-CLI and save it to a file so you can see the differences next time. For sites hosted on Linux hosting, SSH access makes this easy.
If the number of plugins is large and managing them on shared hosting has become time-consuming, WordPress hosting with WordPress-specific management tools shortens this cycle, but note that no hosting can replace deleting a poorly written plugin.
A common measurement trap
Query Monitor itself has some overhead and shouldn't stay active all the time on high-traffic sites. Activate it only during the audit and then deactivate it. Also, if page caching is enabled, the numbers you see relate to uncached requests; for a fair comparison, temporarily turn off the cache.
And a warning: if the site didn't get faster after deleting several plugins, the bottleneck is probably elsewhere. With Website uptime monitoring; a practical guide to downtime alerts without false errors you can figure out whether the problem is server response time or WordPress code. The difference between these two completely changes the path to fixing the problem.
Frequently asked questions
How many WordPress plugins is too many for a site?
There's no fixed number; the criterion is the total execution time and number of queries. A site with 40 lightweight plugins can be faster than a site with 8 heavy plugins. If the total plugin time in Query Monitor stays under 150 milliseconds, the number doesn't matter.
Does an inactive plugin slow down the site?
No, an inactive plugin's code doesn't run and has no effect on page speed. But it's still on disk, doesn't receive security updates, and can be a target for attacks. So it's harmless in terms of speed, but not in terms of security.
How do I find out which plugin has slowed down the site?
Install the Query Monitor plugin and look at each plugin's time in the Components section. Repeat this on several different page types, because a plugin that's lightweight on the homepage might be heavy on the archive or product page.
Does deleting a plugin erase its data?
Some plugins delete their tables and settings from the database when removed, and some don't. Before deleting, take a full database backup. If you just want to test, deactivate first and after a few days, if there's no problem, delete it.
Open Query Monitor right now and look at the execution time of the first three plugins in the list. If none of them is over 100 milliseconds, your site's problem isn't plugins and you should look at the server, cache, or database.
Comments 0
No comments yet — be the first!