After the theme surgery I described earlier in this series, I turned to the plugins, expecting worse. I found better, and that surprise is worth unpacking, because plugins fail differently than themes, and the diet that fixes them is different too.
Why are plugins cleaner than themes?
The WordPress plugin ecosystem did better. When I opened up the plugins on my sites the way I’d opened the theme, the code was, on average, in noticeably better shape. Fewer grafted-together parts. Fewer dead limbs. More evidence that a single mind had thought the thing through.
Part of the reason is structural. A plugin usually exists to do a job, and a job disciplines design in a way that a theme’s job, which is to look like everything to everyone, doesn’t.
Part of it is review: plugins submitted to the official directory get a human security review at initial submission. That gate has limits, though.
Later updates aren’t re-reviewed, so the version you install in year three may share nothing but a name with the version a human once examined. Repository presence means a plugin passed a checkpoint once. I think a lot of site owners read that listing as a promise, and nobody is keeping it.
So plugins start cleaner. Then they grow, and growth is where trouble starts.
The fifteen-things problem
Here’s the pattern that afflicts even good plugins. You install a plugin because it does one thing you need. It does that thing well. The author, needing reasons to ship updates and upsell a pro version, adds features.
A social sharing module. An analytics dashboard. A page builder element. An AI assistant, these days, always an AI assistant. Five years later the plugin you installed to do one thing does fifteen things, and fourteen of them load on every page of your site whether you use them or not.
You didn’t choose those fourteen things. They arrived by update, one release at a time, each too small to notice. This is how a lean site gets heavy without a single bad decision: every plugin on it is individually reasonable and collectively obese.
I hate the upsell treadmill behind this. The author needs a reason to charge for version five, so your contact form grows a dashboard, and your visitors pay for somebody else’s business model in page weight on every single visit. The sign is the settings page. Open any plugin’s settings and count the tabs. One tab, maybe two: a tool. Six tabs, a dashboard, an onboarding wizard, and a menu item with a colorful icon at the top level of your admin: a platform, and platforms eat sites.
How do you audit your WordPress plugins?
The diet starts with an audit, and the audit is simpler than it sounds. I went through every plugin on my sites and asked each one the same questions. Anyone can do this in an afternoon, and no code reading is required.
What job does this plugin do for me? Not what can it do. What does it do, on this site, today. If you can’t answer in one sentence, that’s an answer.
What else does it do that I never asked for? Open the settings, look at the modules, see what’s switched on. Most multipurpose plugins let you disable the features you don’t use, and doing so is the cheapest performance win in WordPress.
What does it cost every visitor? A plugin that runs only in the admin costs your visitors nothing. A plugin that loads scripts and styles on every public page costs everyone, always. The distinction outweighs the plugin’s size on disk.
Who maintains it, and how actively? Check the last-updated date, skim the support threads, read the changelog. You’re looking for a living project, and this question matters enough that the next article in this series is devoted to it entirely.
What happens if I remove it? Some plugins leave cleanly. Some leave shortcodes bleeding raw text across five years of posts. Knowing which kind you’ve installed changes how casually you should have installed it.
What the diet removed
On my own sites the audit found the usual suspects.
Two plugins doing overlapping jobs because I’d installed the second without remembering the first. A plugin kept for one feature that WordPress itself had since grown natively. Several platforms-with-tabs where I used one module and carried six. A plugin last updated three years ago, which in supply chain terms, as the incident that started this series taught me, is an unlocked door nobody is watching.
Each removal followed the same discipline: confirm what the plugin did, make sure something else covered the real need, snapshot, remove, test. Boring, methodical, and the site got faster and simpler with every pass. The final stack is small, and every plugin on it’s a one-sentence justification I can recite.
I’ll tell you what I don’t recommend: the plugin-count fetish. You’ll read that a good site has under ten plugins, or under twenty, as if the number itself were the measure. It’s not, because ten heavy platforms will bury a site that forty small single-purpose tools would leave fast. Count the weight.
What are the rules for a maintainable WordPress stack?
Going forward, four rules keep the weight off. Prefer single-purpose over Swiss Army. You can evaluate, trust, and replace a plugin that does one job. You have to adopt a platform, and adoption is the expensive relationship this whole series keeps warning about.
Audit annually. The stack that was lean last year has been updated fifty times since. The fifteen-things problem keeps happening one release at a time, so the diet has to keep happening too. Watch the front end. Before keeping any new plugin, look at what it adds to a public page. If a contact form plugin loads its scripts on pages with no form, that’s the author telling you how much they care about your visitors.
And treat every plugin as a standing update channel into your server, because that’s what it is. Fewer channels, better watched, from healthier projects. I’d much prefer to run a site on a dozen boring plugins I understand than on one flashy platform I can’t account for, and the security side of that choice is where this series goes next. If your own stack has gone soft and you’d rather have a professional run the audit, that’s work I do.
Frequently Asked Questions
