How to Audit Your WordPress Plugins

"How many plugins is too many?" is the wrong question, and it is the only one most people ask. Twenty lightweight plugins that load nothing on the front end cost less than one page builder.

The right question is what each plugin costs on each request, and there are four numbers that answer it — one of which WordPress calculates for you and displays in the admin.

Number	Where to find it	What it tells you
Autoloaded options size	Site Health → Info → Database	Data loaded on every request
Database queries per page	SAVEQUERIES, on staging	Which plugin is querying, and how much
Assets loaded per page	Browser dev tools, network tab	Scripts and styles loading where they are not used
External requests	Network tab, third-party domains	Calls to other servers inside your page load

Start with the first one. It is free, it takes ten seconds, and it catches the worst offenders — including plugins you deleted years ago.

---

Number 1 — Autoloaded options

This is the most under-used measurement in WordPress, and since WordPress 6.6 it has been sitting in Site Health.

What autoloaded options are: rows in the wp_options table marked to load automatically on every single page request, whether or not anything needs them. Settings, licence keys, cached API responses, feature flags.

The thresholds, from WordPress itself:

• Site Health warns above 800,000 bytes total — the check was added in 6.6 and is adjustable through the site_status_autoloaded_options_size_limit filter
• Core refuses to autoload any single option larger than 150 kilobytes. In WordPress's words, "a value that is greater than 150k bytes will no longer be set to autoload"
• WordPress's optimisation guidance puts it plainly: "Generally, you should try to keep your site's autoloaded options under 800kb."

Where to look: Tools → Site Health → Info → Database. The autoloaded options figure is listed there, and if it is over the limit you will also see a warning on the Status tab.

What a large figure means. Almost always one plugin storing something enormous — a cached feed, a log, a licence payload, an image-optimisation queue. And very often a plugin that is no longer installed, because deactivating and deleting a plugin does not remove its options unless it cleans up after itself, and most do not.

This is the single best argument against "just install it and see." Every plugin you have ever trialled may still be costing you bytes on every page load.

---

Number 2 — Database queries

A slow page is often a page making four hundred queries instead of forty.

WordPress can tell you exactly which queries ran, how long each took, and what called it — with one constant:

define( 'SAVEQUERIES', true );

WordPress documents what this does: it "allows each query to be saved along with the time it took to execute and the function that called it", and "The array is stored in the global $wpdb->queries."

With the warning attached: "This will have a performance impact on your site, so make sure to turn this off when you aren't debugging."

So do this on staging, not on production. The measurement itself slows the site, and the results on a busy live site are muddied by other traffic.

What you are looking for:

• Total query count, compared between pages and between templates
• The calling function, which is what names the plugin
• Queries repeated many times in a single request, which usually means something is not caching a lookup it should

The interpretation that matters: a plugin making thirty queries on the page where it is used is doing its job. A plugin making thirty queries on every page including ones where it does nothing is the problem.

---

Number 3 — Assets loading where they are not used

This is the most common plugin sin, and the easiest to see.

Open the browser's network tab on a plain blog post and look at the CSS and JavaScript files loading. A contact form plugin's script has no reason to load on a post with no form. Neither does a slider library on a page with no slider.

How to read it:

• Filter to CSS and JS, and read the file paths — they contain the plugin's folder name
• Count how many separate plugin folders appear on a page that should be simple
• Note the file sizes, particularly any single file over a couple of hundred kilobytes

Why it happens: enqueueing assets conditionally takes more work than enqueueing them globally, so many plugins do the simple thing.

What it costs: every one of those files is a download, a parse and a main-thread cost — which is why this measurement maps directly onto the INP problem described in Core Web Vitals for WordPress.

---

Number 4 — External requests

The measurement people forget, and the one with the worst failure mode.

In the same network tab, sort by domain. Anything not on your own domain is a request to somebody else's server inside your page load — fonts, analytics, chat, maps, tag managers, review widgets, social embeds.

Three costs:

• Latency, because each new domain means a DNS lookup and a connection before anything transfers
• Main-thread time, because most of them run JavaScript
• A dependency, because if that server is slow today, your page is slow today

And a fourth consideration that is not about speed at all: each of those is a third party receiving your visitors' data. That is a privacy and security question as much as a performance one, and it belongs in the same audit — see WordPress plugin security.

---

The audit

Seven steps. Do it on staging where you can, and take a backup either way.

Step 1 — List what is installed, and what is merely present

Active, inactive, and must-use plugins, plus anything your host installed. Inactive plugins are not free — they still occupy disk, still need updating, and their leftover options may still be autoloading.

Step 2 — Read the autoload figure in Site Health

Tools → Site Health → Info → Database. Note the number. Under 800kb and this is not your problem; well over it and you have found something.

Step 3 — Baseline the front end before changing anything

One representative page, measured three ways: total requests, total transferred size, and time to first byte. Write the numbers down. An audit without a baseline is a series of opinions.

Step 4 — Categorise every plugin by what it earns

Four buckets, and be honest:

• Essential — the site does not work without it
• Earning — measurably contributing to revenue, traffic or a workflow you actually use
• Convenience — pleasant, replaceable by a theme function or a manual step
• Forgotten — installed for a reason nobody remembers

Most sites find three or four in the last bucket immediately, and those are free wins.

Step 5 — Deactivate the forgotten ones, one at a time

One at a time, checking the site after each. The method for doing this without breaking a live site — including how to test safely and what to do when something depends on something else — is in find a WordPress plugin conflict safely.

Deactivate first, delete later. Give it a week; a plugin doing something invisible reveals itself when it stops.

Step 6 — Measure the same page again

Same page, same three numbers. This is the step that converts the audit from tidying into evidence.

Then re-check the autoload figure, which is where deleting an offender shows up most clearly.

Step 7 — Delete properly, and check what was left behind

Deleting through the admin removes files. It does not reliably remove data. After deleting, re-check the autoload figure and look for orphaned option rows carrying the old plugin's prefix.

Take a database backup before removing anything by hand, and if you are unsure whether a row belongs to something still installed, leave it. The guidance on backups is in WordPress backups: what most people get wrong.

---

What not to do

Do not judge by plugin count. It correlates with nothing useful. A site with 35 well-behaved plugins can be faster than one with 8 heavy ones.

Do not deactivate everything at once on production. You lose the information about which one mattered, and you may lose settings.

Do not install a plugin to audit your plugins on a live site permanently. Diagnostic tools are for diagnosis. Leaving one running adds to the thing you are measuring.

Do not delete option rows you cannot attribute. An unattributable row is cheap to keep and expensive to guess wrong about.

Do not confuse "not updated recently" with abandoned. A small, stable plugin that does one thing may genuinely not need changes. What matters is whether it still works on your PHP and WordPress versions — and whether anyone would fix it if it stopped.

---

How often

Twice a year is enough for most sites, plus two triggers:

• After any major site change — a redesign, a new page builder, a host migration
• When Site Health starts warning about autoloaded options, which is WordPress telling you something changed

And once, properly, now — because the first audit on a site that has never had one is where nearly all the available improvement is.

---

Frequently asked questions

How many WordPress plugins are too many?
The count is the wrong measure. What matters is what each one loads per request. Twenty lightweight plugins can cost less than one page builder. Measure autoloaded options, queries per page, assets loaded where they are not needed, and external requests.

What are autoloaded options in WordPress?
Rows in the wp_options table loaded automatically on every page request, whether or not anything needs them. WordPress advises keeping the total under 800kb, warns in Site Health above 800,000 bytes, and since 6.6 refuses to autoload any single option over 150 kilobytes.

Where do I find autoloaded options size?
Tools → Site Health → Info → Database. The total is listed there, and a warning appears on the Status tab if it exceeds the limit.

Do deactivated plugins slow down WordPress?
Not on the front end directly, but their leftover options may still be autoloading on every request, and they still require updating for security. Deleting a plugin removes its files but does not reliably remove its data.

How do I find which plugin is slowing my site?
Measure a baseline, then check assets loading on pages where they are not used, and query counts using SAVEQUERIES on staging. WordPress warns that SAVEQUERIES affects performance, so turn it off afterwards.

What is SAVEQUERIES in WordPress?
A wp-config.php constant that saves every database query with its execution time and the function that called it, stored in $wpdb->queries. WordPress warns it has a performance impact and should be turned off when not debugging.

Should I delete plugins I am not using?
Yes — deactivate first, wait a week, then delete. Inactive plugins still need security updates and their options may still be autoloading. Check the autoload figure afterwards to see whether the data was removed too.

Is a plugin that has not been updated in a year unsafe?
Not necessarily. A small, stable plugin may not need changes. What matters is whether it works on your current PHP and WordPress versions, and whether anyone would fix it if it broke.

---

What to do next

Open Tools → Site Health → Info → Database and read the autoloaded options figure. Ten seconds, and it is the one measurement in this article that WordPress has already done for you.

If it is comfortably under 800kb, plugin data is not your bottleneck and you can go straight to the asset audit. If it is over, you have found something specific, and it is almost certainly one plugin rather than many.

---

Related guides

• Speed up WordPress: what actually moves the number — where plugin weight sits among the levers
• Core Web Vitals for WordPress — the metrics plugin assets damage
• WordPress caching explained — including transient and option bloat
• Find a WordPress plugin conflict safely — the deactivation method
• WordPress plugin security — the other half of the same audit
• WordPress backups: what most people get wrong — before deleting anything
• Choosing WordPress hosting for speed — when the plugins are not the problem