Managing Plugin Bloat: What Stays, What Goes

Every WordPress site over two years old has them: the slider plugin from a homepage design that shipped and was redesigned twice since, the SEO plugin installed alongside the other SEO plugin, the 'temporary' maintenance-mode plugin that has been deactivated-but-installed for ages. Plugins accumulate the way kitchen drawers accumulate cables — each one arrived for a reason, and nobody remembers the reason.

The usual advice is 'use fewer plugins,' which is about as actionable as 'spend less money.' The count was never the problem. A site with 30 well-chosen, maintained, single-purpose plugins is healthier than a site with 8 plugins where two are abandoned, one is a 40-module Swiss Army knife doing one job, and one nobody can explain. What you need isn't a number — it's a system for holding every plugin accountable. Here's one you can run in about ninety minutes, twice a year.

Why bloat actually costs you (it's not just speed)

Be precise about the damage, because it shapes the audit:

  • Attack surface. Every installed plugin is PHP code an attacker can probe — and this is the big one. The large majority of WordPress compromises come through plugin vulnerabilities, not core. Crucially, deactivated plugins still count: their files are still on disk, and some vulnerabilities are exploitable by requesting a plugin file directly, no activation required.
  • Performance, unevenly. Plugins are not equal. A well-written plugin adds near-zero overhead; a bad one adds a query to every page load or drags a 300 KB script onto pages that never use it. Ten good plugins beat two bad ones. The audit's job is finding the bad ones, not counting.
  • Update drag and conflict risk. Every plugin is a recurring decision: update now or later, test or trust. Each one multiplies the combinations that can conflict after a major WordPress or PHP upgrade. This is the tax you pay weekly, forever.
  • Cognitive load. When something breaks, every unexplained plugin is a suspect. A lean, documented plugin list cuts debugging time more than most performance tweaks.

Step 1: Build the inventory (30 minutes)

You can't judge what you haven't listed. Make a spreadsheet — genuinely, a spreadsheet — with one row per installed plugin. If you have WP-CLI, wp plugin list --fields=name,status,update,version gives you the skeleton in five seconds. Columns:

  1. Name and status (active / inactive / must-use).
  2. Job — one sentence: what user-visible or business function does this serve? Write it in outcomes ('lets customers book appointments'), not features ('adds a booking system'). If you can't write the sentence, that's a finding, not a blank cell.
  3. Owner — who on your team would notice if it vanished?
  4. Last update from the developer — check the plugin page. Note anything over 12 months.
  5. Tested up to — is it tested against a recent WordPress version?
  6. Replaceable by — could core, your theme, your host, or another plugin you already run do this job?

The Job column does most of the work. Roughly a quarter of the plugins on a typical mature site fail it — nobody can say what they're for without opening the plugin's settings page and reverse-engineering the answer.

Step 2: Score every plugin against four questions

For each row, work through these in order. The order matters — it's cheapest-decision-first.

Question 1: Is it doing a job anyone still needs?

Not 'is it working' — is the job still real? The Instagram feed widget for the account you stopped posting to long ago works perfectly. The job is dead. Common zombie jobs: integrations with abandoned services, features from a previous design, one-time migration and import tools, 'coming soon' plugins on sites that came, seasonal campaign plugins from seasons past. If the job is dead, the plugin goes. No further questions.

Question 2: Is it maintained?

An unmaintained plugin is a slow-motion liability: no security patches, no compatibility fixes, and someday a PHP upgrade kills it at 2am. Rules of thumb, not laws:

  • No update in 12+ months: yellow flag. Some simple plugins are genuinely finished — a 50-line plugin that disables emojis doesn't need monthly releases. Judge complexity: the simpler the plugin, the more slack it earns.
  • No update in 2+ years, or 'tested up to' trailing 3+ major WordPress versions: red flag. Plan a replacement on your schedule, before it forces one on its own.
  • Closed or delisted from the plugin directory: replace now. Plugins get delisted for security issues more often than people realize, and you won't be notified.

Question 3: Is it duplicating something you already have?

Overlap hides well because plugin names describe features, not territory. Look for these classic collisions: two plugins adding caching layers (often a caching plugin plus a 'performance' module inside a Swiss Army plugin), two things generating XML sitemaps (SEO plugin + core + another SEO plugin), three things adding security headers, two image optimizers, form plugin + newsletter plugin + marketing suite that all do forms. Also check against your host: managed WordPress hosts typically provide server-level caching, backups, and security scanning — plugin versions of those aren't just redundant, they sometimes fight the platform. Pick one owner per job, remove the rest.

Question 4: Is the cost proportionate to the job?

This is where the multi-hundred-module mega-plugin earns scrutiny. If you run a plugin with 40 features to use one — a table-of-contents block, say — you're paying full attack surface, full update tax, and full admin-page clutter for a sliver of the product. Same for the page-builder addon pack loaded sitewide for one icon. Ask: what's the smallest thing that does this job? Sometimes the answer is a single-purpose plugin. Sometimes it's ten lines in a small custom plugin — redirects, a scripts snippet, disabling a core feature are all classically three-line jobs hiding inside 5 MB plugins. Sometimes the honest answer is 'keep the big one, we use six of its modules' — fine, now it's a decision instead of an accident. Disable the unused modules where the plugin allows it.

Step 3: Find the performance offenders with data, not vibes

Don't guess which plugins are slow — measure. Two quick methods:

  • Front-end weight: open your homepage and a typical content page with browser devtools (Network tab, disable cache). Sort by size, and look at which plugins' directories the JS and CSS come from. Any plugin loading assets on pages that don't use its feature is a finding. Contact-form scripts sitewide when the form exists on one page is the canonical example.
  • Back-end time: install a query monitor tool temporarily (the Query Monitor plugin is the standard) and load a few pages. It attributes database queries and load time by plugin. Anything contributing dozens of queries or a triple-digit-millisecond chunk per page needs a justification or a replacement.

A practical threshold: on a typical small-business site, a plugin that adds more than 100 ms of server time or more than 100 KB of front-end assets to pages that don't use it should have to defend itself. Some earn it (WooCommerce is heavy because commerce is heavy). Most don't.

Step 4: Remove things safely

The removal ritual, in order, because 'I deleted a plugin and the site broke' is an avoidable genre of incident:

  1. Backup first. A real one you could restore. Obviously.
  2. Check for data and shortcodes. Search your content for the plugin's shortcodes (wp db search 'shortcode_name' or the admin search) — removing a form plugin leaves raw shortcode text in pages. Note whether the plugin owns data you need to export first (form entries, redirects, events).
  3. Deactivate, then wait. Deactivate and live with it for one to two weeks. Some plugin jobs are invisible until month-end (reports, feeds, scheduled emails). The waiting period catches those.
  4. Then delete — actually delete. Deactivated-forever is the worst state: all of the attack surface, none of the function. Deletion also triggers many plugins' cleanup routines. Note that some plugins leave tables and options behind regardless; a database-cleanup pass once a year catches the residue, but don't let that chore block the deletion.
  5. Log it. One line in a site changelog: date, plugin, why. Six months from now, this line is the answer to 'wait, didn't we used to have…?'

Keeping it from growing back

Bloat is a rate, not a state. Three habits keep the list clean between audits:

  • An entry bar. Before installing anything, answer the same Job question in one sentence, check the plugin's last-update date and active-install count, and check whether something you run already does it. Ninety seconds. It filters out most impulse installs.
  • Trial hygiene. When comparing three plugins for a job, the two losers get deleted the day you pick a winner — not deactivated, deleted. Trials are where zombie plugins are born.
  • The changelog habit. Every install and removal gets a line. The audit's Job column then writes itself next time, and the ninety-minute audit becomes a thirty-minute one.

What a healthy plugin list looks like

After a couple of audit cycles, you converge on something like this: every plugin has a one-sentence job someone will vouch for; nothing has been update-abandoned by its developer; one plugin per territory (one SEO, one caching layer, one forms, one backup — and backups possibly owned by the host instead); zero long-term deactivated plugins; and a changelog explaining the history. The count might be 12 or it might be 28 — genuinely, it doesn't matter. What matters is that you could defend every row of the spreadsheet to a colleague in one breath. That's the difference between a plugin stack and a plugin pile, and it's worth three hours a year to stay on the right side of it.

Photo: Anthony Rahayel on Pexels