“How many plugins is too many?” is the wrong question. One badly built plugin can slow a site more than thirty good ones. What matters is what each plugin does, where it loads and whether you still need it. I’ll walk you through a WordPress plugin audit for speed, the same process I use before any performance project, so you can find the heavy, redundant and risky plugins and remove them without breaking the site.
Why plugins slow sites down
Plugins can cost you speed in two places.
- On the server: database queries, external API calls and heavy processing every time a page is built. This raises server response time, especially on uncached pages, the cart and the admin.
- In the browser: CSS and JavaScript files loaded on pages that don’t need them. A form plugin loading its scripts on every page, or a slider plugin loading on pages without a slider, adds weight everywhere.
Plugins also leave things behind: database tables, scheduled tasks and autoloaded settings that stay after the plugin is deleted.
The WordPress plugin audit, step by step
Do this on a staging copy. Never deactivate plugins one by one on a live store.
Step 1: Make an inventory
List every installed plugin, active or not, in a spreadsheet with these columns: name, what it does on this site, which pages use it, last updated date, and who asked for it. Inactive plugins go straight onto the removal list. They do nothing for you but can still be a security risk.
Step 2: Find overlaps
Look for plugins doing the same job. Common overlaps I find:
- Two SEO plugins, or an SEO plugin plus a separate sitemap plugin.
- Two caching or optimization plugins.
- Several slider, gallery or popup plugins, each used once.
- Two or three page builder addon packs adding widgets the site barely uses.
- Separate plugins for tracking codes that could all be managed in Google Tag Manager.
Step 3: Measure server cost
Install Query Monitor on staging, load your key pages (home, a service page, a blog post, a product page, the cart) and check queries by component. It shows which plugins make the most database queries and which make the slowest ones.
Step 4: Measure front-end cost
Open each key page in Chrome DevTools, go to the Network tab and look at the CSS and JavaScript files. The file paths include the plugin’s folder name, so you can see what each plugin loads and where. Note anything loading on pages that don’t use it.
Step 5: Test removal one at a time
On staging, deactivate one candidate, clear caches, retest speed and check the pages it affected. Write down the result before moving on.
Step 6: Check the abandoned ones
Plugins that have not been updated in a year or more, or that were removed from the WordPress plugin directory, are a security risk. Replace them even if they’re not slow. Abandoned plugins are a common way in for the infections I clean up as part of malware removal.
Step 7: Look for hidden work
Some plugin costs never show up on the front end. Install the free WP Crontrol plugin on staging and look at the scheduled tasks list. You will often find jobs from plugins that were deleted years ago, or tasks running every minute that only need to run daily. Then check the database for tables named after plugins you no longer use, and for large autoloaded options. Your developer can clear these out safely once you have a backup.
What to do with each plugin
- Keep: needed, light and maintained.
- Restrict: needed but loading everywhere. Use a script manager plugin, or a few lines of code, to load its assets only on the pages that use it.
- Replace: a needed function provided by a heavy or abandoned plugin. Swap it for a lighter one, or for a small custom plugin if the job is simple. I keep custom logic in small plugins rather than in the theme, so it survives a theme change.
- Remove: unused, duplicated or inactive. Delete it and clean up its leftover tables and settings.
In a speed project, a leaner plugin stack is often one of the biggest changes, alongside caching and a lighter front end. A shorter stack also means fewer updates to manage and fewer things that can break during them.
Be realistic about what “replace” costs. Swapping a form plugin means rebuilding forms and retesting where their submissions go. Swapping an SEO plugin means checking that titles, redirects and sitemaps carried over. Put the easy removals first and plan the replacements as small projects, each with its own test.
What to do next
- Agree a simple rule: no new plugin without a reason written in the inventory.
- Review the list every quarter and remove anything that no longer has a job.
- Run updates on staging first and test forms and checkout.
- Delete plugins you test and decide not to use, instead of leaving them deactivated.
This kind of routine is built into my WordPress maintenance plans, so the stack stays lean after the speed work is done.
If you’re working on this, these pair well with it: how to fix Largest Contentful Paint on a WordPress site and a WordPress speed checklist that passes Core Web Vitals.
FAQ: plugin audits
How many plugins is too many?
There’s no fixed number. A site with 40 well-built plugins can be faster than one with 10 heavy ones. Judge each plugin by its cost and its value.
Does deactivating a plugin remove its data?
No. Deactivating keeps its data. Deleting it may or may not remove the data, depending on the plugin, so check for leftover tables and options afterwards.
Are page builder addon packs bad for speed?
Not always, but they often load assets for widgets you never use. Turn off unused widgets in their settings, or remove the pack if you only use one or two widgets from it.
Can I do the audit on my live site?
The inventory, yes. Deactivating and testing should happen on staging, especially on stores and lead-generation sites.
Should I use a plugin to control which scripts load on each page?
Script manager plugins work well for restricting heavy plugins to the pages that need them. Keep a note of every rule you add, because a forgotten rule can break a feature months later.
Book a free website review, and I’ll flag the plugins that cost you the most speed and the ones that put your site at risk.
