“Too many plugins” is the most common explanation for a slow WordPress site, and it’s usually the wrong one. Ten well-built plugins can cost less than one heavy page builder add-on that loads its scripts on every page. What matters is what each plugin does on each request: the scripts and styles it adds, the database queries it runs, the data it autoloads and the background jobs it schedules.
This guide shows how to measure that, plugin by plugin, and then decide what to keep, replace, limit to certain pages or remove.
Step 1: Make an inventory with a reason for each plugin
Export the list: wp plugin list --status=active --fields=name,version,update. Next to each one, write the business job it does in one line. You will usually find three groups straight away:
- Duplicates. Two plugins doing one job, such as two SEO plugins, a caching plugin plus the host’s own cache, two form builders, or a security plugin plus Jetpack’s security module.
- Leftovers. Plugins installed for a campaign, a migration or a feature that no longer exists, such as an old slider, a coming-soon page or an importer.
- “Nobody knows.” Plugins no one on the team can explain. Test these first on staging.
Step 2: Measure what each plugin costs
Do this on a staging copy with the same plugins and data.
Front-end assets
Open a few key templates (home, a blog post, a product page, checkout) with Query Monitor active and check the Scripts and Styles panels. Look for plugins that load assets on pages where they do nothing. A contact form plugin loading on every page, or a slider library on pages without a slider, is the classic example. Browser DevTools’ Coverage tab shows how much of each file is actually used.
Database queries
Query Monitor’s Queries by Component shows how many queries each plugin runs and how long they take. A plugin running dozens of queries per page, or repeating the same query in a loop, is a stronger signal than its file size. See finding N+1 queries.
Autoloaded data and cron jobs
- Large autoloaded options are loaded on every request. List them as shown in our database optimization guide and match the option names to plugins.
wp cron event listshows scheduled jobs. A plugin that runs a heavy job every minute (stats sync, remote checks) hurts the server even if pages look fine.
The simple A/B test
For a suspect plugin, record uncached TTFB and the page weight, deactivate the plugin on staging, and measure again. If the numbers don’t move, the plugin is not your speed problem, whatever its reputation.
Step 3: Decide (keep, limit, replace or remove)
| What you found | Action |
|---|---|
| Business-critical and light (security, backups, payments, SEO) | Keep. Re-check yearly that it’s still the best option. |
| Needed on a few pages, loads assets everywhere | Limit its assets to those pages (see below) or ask the developer for conditional loading. |
| Duplicates another plugin’s job | Keep the better maintained one; migrate settings and remove the other. |
| Small feature that core or your theme now does | Remove. Lazy loading, basic SEO meta, SVG icons and simple layout blocks are often built in now. |
| Not updated in 12+ months, or closed on WordPress.org | Replace, even if it “still works”. It is also a security risk. |
| Heavy, but central to the site (page builder, LMS, large WooCommerce extensions) | Keep for now and plan a replacement as part of the next redesign. |
Limiting plugins to the pages that need them
Often the right answer isn’t removal but scope:
- Asset managers. Plugins like Asset CleanUp or Perfmatters let you switch off a plugin’s CSS and JS on pages where it isn’t used.
- Code-level dequeue. A few lines in a small site-specific plugin can dequeue a script except on, for example, the contact page. This is precise, but it needs re-testing after the plugin updates.
- Plugin settings. Many form, chat and analytics plugins already have a “load only where used” option that is switched off by default.
Removing a plugin without leaving a mess
- Search for its shortcodes and blocks first. Run
wp db search '[shortcode_name' --all-tablesor search post content for its block names. Otherwise, raw shortcodes appear on live pages. - Check its data. Some plugins delete their tables and settings on uninstall; most leave them. Decide whether you need that data (form entries, redirects, SEO meta) and export or migrate it before deleting.
- Clean up afterwards. Leftover tables, options and cron events.
wp cron event listwill show scheduled hooks that now point nowhere. - Remove it on staging first, then live, and check the pages it touched. If something breaks, see how to find which plugin is causing an error.
A lean stack is a maintenance decision, not a number
The goal isn’t the fewest plugins; it’s that every plugin earns its place: it does a real job, it’s maintained, and it costs little on the pages where it runs. Review the list every quarter, and every time someone wants to add “just one more”, ask which existing plugin or core feature already covers it. For a starting point, see must-have plugins for better performance.
Want a second opinion on your plugin stack? We audit WordPress and WooCommerce plugins, remove what is not needed and replace heavy ones with lighter options. See our performance services.
Frequently Asked Questions
Is there a number of plugins that’s “too many”?
No. A site with 25 focused, well-built plugins can be faster than one with 8 heavy, overlapping ones. Measure the cost per plugin instead of counting.
How do I know if a plugin is slowing my site down?
Use Query Monitor to see its queries and assets, then deactivate it on staging and compare uncached TTFB and page weight. That gives you a real answer instead of a guess.
Is it safe to deactivate a plugin on the live site to test it?
It’s risky. Shortcodes, blocks and settings the plugin provides can break pages for visitors. Test on a staging copy first.
Do deactivated plugins slow down WordPress?
They don’t run, so they don’t cost speed, but they can still be a security risk because the files remain on the server. Delete plugins you don’t plan to use again.