Too many plugins: why each one costs three times over

Too many plugins is not a number. It is plugins that nobody needs any more, that do the same job twice, or that are no longer maintained. Each one costs three times over: it loads files that slow the site down, it brings third-party code that can contain a security hole, and it has to be checked again with every update. That makes the plugin list the one place where a single step — deleting a plugin — shrinks three problems at once. Deactivating is not enough.

What the plugin list tells you

The plugin list in the admin area is often the most revealing page of a website. It tells the site's story: a slider was needed here once. Someone installed a second form plugin there because the first one did not work. Over there sits an add-on for a theme that has not been in use for years.

None of these leftovers is just clutter — each one is loading time, attack surface and maintenance work. The three costs one by one:

Cost 1: loading time

Many plugins bring their own stylesheets and scripts — and load them on every page, not only where their feature appears. The form plugin loads on the home page, the slider plugin on the contact page.

That is not cosmetic. Google's audit tool Lighthouse describes what such files cost:

• A script in the head of the page without defer or async, and every ordinary stylesheet, block the first paint of the page.
• For a blocking script, the browser has to download, parse, compile and run it before it can carry on.
• Even code loaded later competes for bandwidth while it downloads — and uses up mobile data.

For WordPress, Lighthouse gives a single, remarkably direct piece of advice: reduce or switch the plugins that load unused JavaScript into the page.

The WordPress handbook for plugin developers says the same from the other side: scripts should only be enqueued on the pages where they are needed. Where a plugin does not do that, removing it is the most effective step — more effective than any optimisation plugin that combines or defers the files afterwards.

Cost 2: security

WordPress itself is rarely the problem. Patchstack, a WordPress security vendor, counts the following for 2025 in its report "State of WordPress Security in 2026":

Measure	Value
new vulnerabilities in the WordPress ecosystem	11,334 (42 percent more than in 2024)
of which in plugins	91 percent
of which in themes	9 percent
in WordPress core	6, all low risk
without a fix from the developer at the time of disclosure	46 percent

The attack surface of a WordPress site is therefore almost entirely its plugins. The WordPress developer handbook itself names plugins and themes as the key points of weakness.

And it happens fast. For the heavily exploited vulnerabilities, Patchstack puts the median time to the first mass exploitation at five hours; about half of the high-impact vulnerabilities were exploited within 24 hours. If you update once a month, a new hole leaves you open not for hours but for weeks. Every plugin fewer is one place less where that can happen.

Deactivated is not deleted

A plugin that does nothing is not harmless. A deactivated plugin keeps all its files on the server, and some vulnerabilities can still be exploited through them. The WordPress.org hardening guide is brief accordingly: keep plugins updated, and delete any plugin you do not use.

Cost 3: maintenance

Every plugin has to be updated, every update can break something, every update wants checking. Twenty plugins are twenty possible conflicts with every WordPress update — and twenty changelogs someone ought to read.

Then there is what plugins leave behind in the database. On every page request WordPress loads part of the stored settings in one go, the so-called autoloaded options. Since version 6.6, Site Health in the admin area reports a critical issue when these add up to more than 800 KB. A common cause: plugins that created settings and did not clean them up when they were removed.

Whether cleanup happens depends on the plugin. The Plugin Handbook draws a clear line: deactivation should only flush caches; only deleting through the admin area should remove options and tables — provided the developer built it in.

How many are too many?

There is no number that fits everyone. A shop needs more than a business-card site, and a fixed limit cannot be backed up. Four principles are more useful:

• One plugin per job. Two form, two cache or two SEO plugins are almost always a sign that something once did not work and nobody tidied up. Duplicate plugins often work against each other.
• No plugin for ten lines. A redirect, an extra field, a disabled default behaviour can often be solved with a few lines of code.
• No plugin for design. Anything that only exists to make something look different belongs in the theme or the CSS.
• No all-in-one bundles of which you use two features. They usually load the rest anyway.

The honest rule is: every plugin has to be able to justify why it is there.

The stocktake: three questions per plugin

1. Is it still needed? If you cannot say what it does, that is already an answer. Common candidates: the slider from an old home page, maintenance-mode plugins after launch, import tools after a migration, add-ons for a replaced theme, statistics plugins nobody looks at, an old cache plugin next to the current one.

2. Is it maintained? The plugin's page on WordPress.org shows the number of active installations and the date of the last update. WordPress.org itself gets clearer once a plugin falls behind: the page then says the plugin has not been tested with the latest 3 major releases of WordPress and may no longer be maintained. A plugin with that notice belongs on the replacement list, however well it is described.

3. Is there a lighter way? Sometimes the theme or a plugin you already have can do the same. Sometimes a setting solves the problem.

The practical warning that goes with it: take a backup before tidying up. And go one at a time, not five at once — otherwise you will not know which removal broke something.

What usually stays

The plugins that do a real job on almost every site:

• Backup. Not negotiable.
• Security with monitoring for known vulnerabilities.
• Cache, unless the host does it.
• SEO, if you maintain titles and descriptions.
• Forms, unless the theme brings them.
• Image optimisation on upload.
• Depending on the business: consent management, appointment booking, multiple languages.

Anything beyond that should come with a reason.

The gap between two updates

The five hours create a problem that care alone does not solve: even if you update daily, you are unprotected between the moment a hole becomes known and the moment a fix appears. And in 46 percent of cases there was no fix at all at the time of disclosure.

The usual answer is called virtual patching: a security vendor distributes a rule that blocks the attack pattern before the plugin itself is fixed. Patchstack says it rolls out such rules at the moment a vulnerability is disclosed — that is the claim of a vendor who sells this service, but it describes the principle.

For a small business-card site this is often more than needed. For a business whose website generates enquiries or takes orders, it is the obvious answer to a timing problem that faster action cannot solve. The best remedy is still the simplest: a plugin that is not installed needs no protection.

How to check it yourself

• Go through the plugin list. For each one: do you know what it does? When was it last updated?
• Look for deactivated plugins. Each one should be deleted, not left deactivated.
• Open the Network tab on a simple page. Take the imprint page — a page with no features — open the developer tools with F12 and reload it in the "Network" tab. Every script and stylesheet from wp-content/plugins/ whose feature does not appear on that page is dead weight. This is the most convincing test, because you see at once how much is loaded that does nothing.
• Run Lighthouse. In the same developer tools, the "Lighthouse" tab lists unused JavaScript and blocking files — with the path showing which plugin they come from.
• Look for duplicate jobs. Two cache, two SEO, two form plugins.
• Open Site Health (Tools → Site Health) and see whether autoloaded options are flagged.

What to do

1. Backup first, then tidy up. One at a time, with a check after each step.
2. Delete the deactivated ones first. That is progress with almost no risk.
3. Resolve duplicates. Pick one.
4. Replace unmaintained plugins. For almost every orphaned plugin there is a maintained alternative. Switching is work once and quiet afterwards.
5. Delete through the admin area, not through file access — only then can a plugin remove its own settings and tables.
6. Make the plugin inventory part of regular maintenance. Once a quarter, go through the list and ask whether each one is still needed.
7. Before every new install, three questions: do I really need it? Is it maintained? Do I have a backup?

The plugin list is the place where three problems get smaller at the same time. Every plugin removed makes the site faster, shrinks the attack surface and saves maintenance.

Sources

• Patchstack, State of WordPress Security in 2026 — 11,334 vulnerabilities in 2025, plus 42 percent, 91 percent plugins, 9 percent themes, 6 in core, 46 percent without a fix, five-hour median, about half within 24 hours, protection rules at disclosure: patchstack.com
• WordPress.org, Hardening WordPress — keep plugins updated, delete unused plugins: developer.wordpress.org
• WordPress.org, Common APIs Handbook: Security — plugins and themes as key points of weakness: developer.wordpress.org
• DreamHost, Abandoned WordPress Plugins — files of deactivated plugins stay on the server and can be exploited: dreamhost.com
• Chrome for Developers, Lighthouse: Reduce unused JavaScript — cost of unused code, advice on WordPress plugins: developer.chrome.com
• Chrome for Developers, Lighthouse: Eliminate render-blocking resources — blocking scripts and stylesheets: developer.chrome.com
• WordPress.org, Plugin Handbook: Enqueuing — enqueue scripts only where they are needed: developer.wordpress.org
• WordPress.org, Plugin Handbook: Uninstall Methods — deactivation versus deletion, removing options and tables: developer.wordpress.org
• Make WordPress Core, Options API: Disabling autoload for large options — Site Health check above 800 KB since WordPress 6.6: make.wordpress.org
• WordPress.org support forum — wording of the "not tested with the latest 3 major releases" notice: wordpress.org