"How many plugins is too many?" is the most-asked and least-useful question in WordPress.
The answer is that it depends entirely on which plugins. Twenty well-coded, actively maintained plugins that load assets only where needed will comfortably outperform six bloated ones that each dump 200KB of CSS and JavaScript onto every page whether it's used or not.
Count is a proxy people reach for because measuring weight sounds hard. It isn't. Here's how to measure what each plugin actually costs, and what to cut.
The short version
Measure four things per plugin:
- Asset weight — what CSS and JS it loads, and where
- Query load — how many database queries, and how slow
- Maintenance status — last updated, and compatibility
- Actual use — do you genuinely use it?
Then cut in this order: unused, duplicated, abandoned, expensive-relative-to-value.
Two free tools do all the measuring: Query Monitor and PageSpeed Insights.
Step 1 — The obvious cuts, first
Before measuring anything, three categories come out immediately.
Deactivated plugins. They're still files on your server, still a security surface, and still there to be exploited if one has a vulnerability. Deactivated is not removed. Delete them.
Plugins you can't identify. If you don't know what it does or why it's there, find out. If nobody knows, it's a candidate.
Duplicates. Two SEO plugins, two caching plugins, two security plugins, two form plugins. These don't just waste weight — they actively conflict, writing competing meta tags or caching layers. Pick one.
That alone often removes a third of the list.
Step 2 — Find out what each plugin loads
PageSpeed Insights, free, no installation.
Run any page and expand "Reduce unused JavaScript" and "Reduce unused CSS." You get a list of files with sizes — and the file paths are your plugin folders.
/wp-content/plugins/slider-plugin/assets/js/slider.min.js — 342 KB
A 342KB slider script on a page with no slider is a plugin loading everywhere when it should load nowhere.
What to look for: any plugin loading substantial assets on pages that don't use its functionality. Contact form plugins are the classic offender — loading their scripts site-wide for a form that exists on one page.
The fix is often not deletion. Several optimisation plugins (Perfmatters, Asset CleanUp) let you disable specific plugin assets on specific pages. That keeps the functionality and removes the cost.
Step 3 — Measure query load with Query Monitor
Query Monitor is free, and it's the tool that turns guesswork into data.
Install it, activate it, and load a page on the front end while logged in as an admin. A panel appears in the admin bar showing:
Total queries and total query time. Under 50 queries is healthy for a typical page. Over 100 warrants investigation. Over 200 is a problem.
Queries by component — the crucial view. It attributes queries to specific plugins, so you can see exactly which one is running forty queries per page load.
Slow queries, highlighted individually.
Hooks, HTTP requests, and PHP errors, which surface plugins making external API calls on every page load. Those are a genuine cause of poor TTFB and they're invisible otherwise.
What to act on: a plugin generating disproportionate queries or making external HTTP requests on every page load. Those are the expensive ones, and they rarely announce themselves.
Deactivate Query Monitor when you're done. It adds overhead itself, which is fine for diagnosis and pointless the rest of the time.
Step 4 — Check maintenance status
Go to Plugins → Installed Plugins and check each one's WordPress.org page.
Red flags:
No update in over a year. Both a break risk when core or PHP moves, and a security risk since vulnerabilities go unpatched.
"Untested with your version of WordPress." Sometimes just a lazy header update, sometimes genuine abandonment. Check the support forum for recent developer replies.
Unanswered support threads. A plugin whose forum is full of unresolved questions from six months ago is effectively unmaintained.
Ownership changes. Popular plugins get acquired, and quality sometimes drops sharply afterward — occasionally into aggressive upselling or worse. Worth knowing who maintains what you run.
Abandoned plugins are a security problem as much as a performance one. The security angle.
Step 5 — The keep-or-cut decision
For each remaining plugin:
Do I use this? Not "might it be useful" — do you use it. Cut what you don't.
Is there a lighter way? Some plugins exist to do something a few lines of code in your child theme's functions.php would handle. Others duplicate what your theme or a plugin you already have provides.
Is it worth its weight? A page builder is heavy and you need it. A social sharing plugin loading 180KB for buttons nobody clicks is not the same trade.
Is it maintained? Covered above, and it's often the deciding factor between two similar options.
And the honest test: if you removed this tomorrow, what would break, and would anyone notice?
The categories usually safe to cut
Patterns that come up in most audits:
Social sharing plugins. Heavy, and share buttons see very low engagement on most sites. A few lines of HTML with share URLs does the job weightlessly.
Related posts plugins. Often run expensive queries on every page load. Many themes include the functionality already.
Single-purpose plugins for trivial jobs. "Insert header and footer scripts," "hide admin notices," "change the login logo" — several of these can be replaced by a handful of lines in a child theme.
Analytics plugins. Many exist to paste a tracking script. Pasting the script directly, or using one lightweight header/footer plugin for all of them, is lighter.
Slider plugins. Heavy, and sliders perform poorly for engagement in most published testing. If you have one, it's worth asking whether it earns its cost.
Old page builder addon packs where you use one widget from a library of sixty. More on that.
Are page builder addons a problem?
Frequently the single biggest contributor on builder sites, and the most overlooked.
Each addon pack — Essential Addons, Ultimate Addons, Happy Addons — loads its own CSS and JavaScript framework. Install three packs to get four widgets and you've tripled the overhead for a handful of elements.
What to do:
Count what you use. Usually one or two widgets per pack.
Check for module toggles. Most packs let you disable individual widgets, cutting asset load substantially. This is the fastest available win and almost nobody does it.
Consolidate to one pack covering everything you need, and remove the rest.
Doing it safely
Back up first, files and database.
Test on staging if you have it.
Remove one at a time, checking the site after each — front end, forms, checkout, mobile menu.
Deactivate before deleting, and give it a few days. Settings survive deactivation; deletion often removes them permanently.
Keep a record of what you removed and when. When something breaks in three weeks, that list is what tells you where to look.
Frequently asked questions
How many plugins is too many?
There's no number — weight and quality matter far more than count. Twenty well-coded plugins that load assets only where needed will outperform six bloated ones loading scripts site-wide. What matters is whether each is maintained, actually used, not duplicating another, and worth what it costs in assets and queries. If you can't say what a plugin does and why it's installed, that's the real signal.
How do I know which plugin is slow?
Query Monitor attributes database queries to specific plugins, so you can see exactly which one is running forty queries per page load or making external HTTP requests on every request. For front-end weight, PageSpeed Insights' "Reduce unused JavaScript" and "Reduce unused CSS" sections list files by size, and the file paths name the plugin folders directly. Both are free.
Are page builder addons a problem?
Often the biggest single contributor on builder sites. Each addon pack loads its own CSS and JavaScript framework, so installing three packs to get four widgets multiplies the overhead considerably. Most packs let you disable individual widgets you don't use, which cuts their asset load substantially — that's usually the fastest available fix, ahead of removing the pack entirely.
What to do next
Install Query Monitor, load your homepage, and look at "Queries by Component."
That one screen usually names the two or three plugins costing you the most — and it's frequently not the ones you'd have guessed. People assume the page builder is the problem and find a related-posts plugin running sixty queries.
Then delete every deactivated plugin sitting in your install. That's a free security improvement in about two minutes.
Free: The WordPress maintenance checklist.
Related guides
- WordPress speed: the Core Web Vitals playbook — where the audit fits
- How to read a PageSpeed Insights report — the unused JS and CSS lists
- Find a plugin conflict safely — when a plugin breaks rather than slows
- Elementor site speed — addon packs specifically
Join the Newsletter
Get practical marketing tactics delivered straight to your inbox.
Written by
Muhammad Basim
Related Articles
Transactional Email Services Compared for WordPress
Every one of these services will deliver your password resets. That's not the differentiator. What differs is setup difficulty, what the free tier covers, how good the logs are when something goes wrong, and — the one people never consider until it bites them — whether the service also handles marketing mail, and whether you […]
Contact Form Notifications Not Arriving: Every Cause
Here's the version of this problem that costs the most: it's been happening for months and you don't know. The form says "thank you." The visitor believes they've reached you. You believe nobody's been in touch. There's no error, no bounce, no alert — just an absence, and absences are invisible. Most of the time […]
WooCommerce Order Emails Going to Spam: The Fix
"I never got a confirmation. Did my order go through?" Every store owner gets this message. And when it arrives often enough, you stop treating it as customer confusion and start realising your receipts genuinely aren't landing. This costs more than most email problems, because a missing order confirmation doesn't just annoy someone — it […]