Reducing Plugin Bloat Without Breaking the Site

That last one is worth emphasising. Nearly every WordPress compromise I've cleaned up came in through an outdated plugin. Every plugin you remove is one fewer thing that can be exploited.

• PHP executed on every request, whether or not the page uses the plugin's features.
• Database queries, including options loaded on every page and meta lookups inside loops.
• CSS and JavaScript enqueued on the front end, very often site-wide when they're needed on one template.
• Remote HTTP calls — licence checks, analytics pings, feed fetches — which block PHP until the remote server answers.
• Scheduled tasks, which on a site without real cron run inside a visitor's page load.
• Maintenance and security surface: another codebase to update, another possible vulnerability.

Guessing which plugin is slow wastes time and occasionally removes the wrong one. Use a query monitoring tool in a staging environment to see, per page load, which plugin is responsible for which queries, how long each hook took, and what HTTP requests were made.

Do this on several page types — the homepage, a post, an archive, the checkout if there is one, and a wp-admin screen. Plugins that are invisible on the homepage sometimes dominate the admin, and vice versa.

Write down the numbers before you change anything, so you can tell whether a change helped.

Go through every installed plugin and put it in one of four buckets. This takes an hour and it's the most valuable hour in the process.

• Essential — the site's function depends on it. Keep, but check it's the lightest option.
• Useful — it does something worthwhile but the site works without it. Candidate for replacing with a few lines of code.
• Redundant — it duplicates something another plugin, the theme or core already does. Remove.
• Forgotten — nobody remembers installing it and nothing visibly uses it. Investigate, then remove.

• Multiple plugins doing the same job: two SEO plugins, two caching plugins, two security plugins. These conflict as well as duplicate.
• A whole plugin for one small thing — a plugin to add a favicon, or to insert a tracking script. Both are a few lines in the theme or a site-specific plugin.
• Slider and gallery plugins loading their libraries on every page for one slider on the homepage.
• Contact form plugins loading their scripts site-wide for a form on one page.
• Page builder add-on packs where you use three of the sixty included modules.
• Analytics and heat-mapping tools that were installed for one experiment two years ago.
• Plugins that were deactivated rather than deleted, still sitting in wp-content/plugins unpatched.

The removal process matters more than the decision. Plugins leave things behind and some of them are load-bearing.

• Do it on staging first, never on production.
• Take a full backup before each batch.
• Remove one at a time, or in small related batches, so you can attribute a breakage.
• Check the front end and the admin after each removal, including the pages you'd least expect to be affected.
• Watch for orphaned shortcodes — a removed plugin's shortcode renders as visible text in the content. Search the database for it before removing.
• Check for orphaned data: options, custom tables, post meta. Many plugins deliberately leave data on deactivation and only clean up on uninstall.
• Check scheduled tasks for events belonging to a plugin that no longer exists.
• Delete, don't just deactivate. Deactivated code is still on disk and still unpatched.

Most plugins enqueue their CSS and JavaScript on every page because they can't know where they're needed. On a site where a contact form appears on one page, that form plugin's assets are being downloaded on every other page for nothing.

You can dequeue them conditionally: check whether the current page actually uses the feature, and if not, remove the plugin's styles and scripts. On a typical site this is a bigger improvement than removing two plugins entirely, and it doesn't cost you any functionality.

It does need testing — dequeuing something a theme quietly depends on produces subtle breakage — so do it one handle at a time and check the affected pages.

Plenty of single-purpose plugins are a handful of lines. Adding a tracking script, disabling emoji, changing the excerpt length, adding a menu location, removing a dashboard widget — all of these are small snippets that belong in a site-specific plugin.

The important caveat: put them in a site-specific plugin, not the theme's functions.php. If switching themes would break the site's behaviour, the behaviour is in the wrong place.

Don't take this too far. Replacing a well-maintained security or backup plugin with your own code means you now maintain security and backup code. Replace the trivial ones; keep the ones where someone else's ongoing maintenance is the actual product.

• Check the last-updated date and whether it supports the current WordPress version.
• Look at how many assets it adds to the front end before committing to it.
• Prefer plugins that do one thing over suites that do forty, of which you need two.
• Check whether it cleans up after itself on uninstall.
• Read a few recent support threads — they tell you more about the developer than the marketing page does.
• Never install a nulled premium plugin. It's the most reliable way to get a backdoor.

Plugin lists grow. Someone needs a thing, installs a plugin, and the thing is done — but the plugin stays. Six months later nobody remembers what it was for.

A quarterly review, with the same four buckets, keeps this in check. It takes an hour and it's the cheapest performance and security work you'll do all year.