How many plugins is too many? The real answer.

"Keep it under 20 plugins" is one of the most repeated pieces of WordPress advice, and it is also one of the least useful. It treats every plugin as if it costs the same, when in practice a single plugin making an unconditional database query on every page load can cost more than fifteen well-behaved plugins that read one cached option and get out of the way. Plugin count is a proxy for risk, not a measurement of cost, and proxies stop working the moment you optimize for them instead of the thing they were supposed to represent.

Think of it like a kitchen. Twenty line cooks who each do one job quickly and step aside do not slow the kitchen down. Five cooks who each insist on re-checking the entire pantry before starting their task will. What matters is not how many people are in the kitchen, it is what each one does on every single order.

This guide explains why plugin count is the wrong metric, what actually makes a plugin expensive, how to measure the real cost of the plugins you already have installed, and how to decide what to remove without guessing.

Why is plugin count the wrong metric?

A WordPress plugin is just a set of functions hooked onto WordPress's action and filter system. Two plugins can look identical on the plugins list screen, both with thousands of installs and a high star rating, and cost wildly different amounts on every page load, because what each one hooks into and how often it runs is invisible from that screen.

The real cost driver is per-request behavior: does the plugin run on init or wp_head on literally every request regardless of whether the page needs it, does it query the database unconditionally even on pages where its feature never appears, and does it enqueue CSS and JavaScript sitewide instead of only where it is actually used. A plugin that hooks into init and does nothing 99% of the time is close to free. A plugin that hooks into init and runs a query to check a setting every time is not, no matter how small that query looks in isolation, because it runs on every page, every visitor, all day.

This is why a five-plugin site can be slower than a thirty-plugin site. Count alone tells you nothing about what is actually running.

What actually makes a plugin expensive?

Three patterns account for most of the real cost we see when auditing plugin behavior.

1. 1.It hooks into every request, not just the pages it applies to. A related-posts widget that only ever renders inside a single-post template should only run there. If it instead hooks into wp_head globally and checks internally whether it is on a single post, it still pays the cost of loading its class and registering its hook on every admin screen, archive, and search result, before it ever answers that question.
2. 2.It queries the database on every load, regardless of relevance. Plugins that store settings across many separate rows, or that run a custom query to check a license, geolocate the visitor, or log the request, add real query time to pages that have nothing to do with the plugin's feature. A 5 to 10ms query is invisible once. It is not invisible run on every page load, every visitor, all day.
3. 3.It enqueues CSS and JavaScript sitewide instead of conditionally. A slider or popup plugin used on two landing pages should only load its script and stylesheet on those two pages. Many ship a global enqueue on wp_enqueue_scripts with no conditional check, so every page on the site downloads and parses assets it will never use.

None of these three patterns show up in a star rating, and none of them show up in the plugins list count. They only show up when you measure.

Plugin type

Expensive pattern

Cheap pattern

SEO / schema plugin

Rebuilds schema markup on every request, even cached ones

Generates schema once on save, serves the cached output

Contact form plugin

Enqueues its full CSS and JS bundle sitewide

Only enqueues on pages containing its shortcode or block

Related posts widget

Runs a fresh, uncached query across the whole posts table on every view

Caches the result in a transient, recalculates only on publish

Security / firewall plugin

Writes a database row on every single request, including bots and 404s

Batches log writes or samples traffic instead of logging synchronously

Analytics / heatmap plugin

Loads a synchronous tracking script that blocks rendering

Loads asynchronously and batches events instead of firing per view

How do you measure the real cost of each plugin?

Query Monitor is the fastest place to start. It is a free, widely used WordPress debugging plugin that breaks down database queries, hook execution, and page generation time by the plugin or theme responsible, in a panel added to the admin toolbar. Install it on a staging copy of your site (it adds its own overhead while active, so it is not meant to stay on in production), load a representative page, and open the "Queries by Component" and "Hooks & Actions" panels. Sort by time and you will usually find that two or three plugins account for most of the measurable cost, while the rest are close to free.

A simpler, no-plugin-required test is a before-and-after comparison with WP-CLI and curl. Deactivate a candidate plugin, measure time to first byte, reactivate it, and measure again:

wp plugin deactivate example-plugin
curl -o /dev/null -s -w "%{time\_starttransfer}\\n" https://example.com/
wp plugin activate example-plugin
curl -o /dev/null -s -w "%{time\_starttransfer}\\n" https://example.com/

Run each curl call three to five times and compare the average. A gap under 10ms is noise. A gap of 50ms or more on a page the plugin has no business touching is a real, measurable cost you can now weigh against what the plugin does for you.

Deciding what to remove

1. 1.Rank by measured cost, not familiarity. Run the deactivate-and-remeasure test on your heaviest suspects first, then sort the results by milliseconds added.
2. 2.For anything enqueuing assets sitewide, ask whether it needs to be sitewide, or only on the two or three templates where the feature actually appears. Many plugins have a "load everywhere" setting you can turn off.
3. 3.If you cannot explain why a plugin is installed, check whether the feature it provides still matters. If it does not, remove it entirely rather than leaving it deactivated; a deactivated plugin still shows up in your update queue and attack surface.
4. 4.Never decide based on count alone. Five plugins each adding 5ms is cheaper than one plugin adding 200ms, and removing the wrong four to hit a round number changes nothing that matters.

Always take a full backup before removing or deactivating anything you cannot instantly restore. A backup turns a risky change into a reversible one.

How BoltAudit finds the expensive ones for you

Running Query Monitor across every page template and cross-referencing the results by hand takes real time. [BoltAudit](/) is a free, read-only WordPress performance audit plugin that runs entirely on your own server. Its Local Audit is built to surface exactly the patterns in this guide: which plugins hook into every request regardless of relevance, which enqueue assets sitewide, and where the unconditional database queries live, with an estimated cost for each. Nothing leaves your site, and nothing is changed automatically; the decision to keep or remove a plugin stays with you. Audits are located under Tools then BoltAudit in your WordPress admin.

Run it on your plugin list

If you are staring at a plugins screen wondering which ones are actually worth their cost, stop counting and start measuring. Install BoltAudit free, run a Local Audit from Tools, then BoltAudit, and let it point at the specific plugins adding real time to every page, not just the ones that make the count look high.

Key takeaways

• Plugin count is not the cost metric. What each plugin does on every request is.
• Watch for three patterns: hooking into every request unconditionally, unconditional database queries, and sitewide asset enqueuing.
• Measure before you guess. Query Monitor and a deactivate-and-remeasure test tell you the real number in minutes.

Frequently asked

Is there a safe number of plugins to run?

No fixed number. A well-behaved plugin that only runs where it is needed adds close to zero measurable cost, so thirty of them can be lighter than five poorly written ones. Judge each plugin by what it does on every request, not by where the count sits.

Does deactivating a plugin delete its data?

No. Deactivating a plugin stops its code from running but leaves its database tables, options, and settings in place, so it is safe to deactivate as a test. Deleting a plugin is a separate step, and some plugins remove their own data on deletion while others leave it behind.

Will BoltAudit tell me which plugin to remove?

BoltAudit's free Local Audit is read-only and runs on your own server, so it does not deactivate or remove anything for you. It surfaces which plugins are adding measurable time on every load, with an estimated cost for each, so the decision to keep or remove stays with you.

What is Query Monitor?

Query Monitor is a free, widely used WordPress debugging plugin that shows database queries, hooks, and page generation time broken down by the plugin or theme responsible. Install it on a staging copy, review the findings, and deactivate it when you are done since it adds its own overhead while active.

Not sure which plugin is costing you the most? [The free Local Audit](/features) names it in about a minute.

Plugins Query Monitor Performance

BA

BoltAudit team

Builders and operators who name the exact bottleneck slowing a WordPress site and rank every fix by visitors recovered.

[Talk to us](/contact)