Guide WordPress

How to find the plugin that is slowing your site

A methodical way to find out which plugin is actually responsible before you start deactivating things at random.

iFastHosting Support Team Updated 26 August 2026 7 min read Intermediate

Guessing which plugin is slowing a site down is a bad use of time — the plugin causing a slowdown is very often not the one you would suspect on looks alone. A simple form plugin can be fine, while an SEO plugin quietly running dozens of database queries on every page load can be the real cost. The reliable approach is to measure, not to guess.

Method 1: deactivate everything, then bring plugins back one at a time

Slow but conclusive, and the method to use when nothing else is telling you where to look.

Take a backup first
You are about to deactivate plugins on a live site. See backing up a WordPress site if you have not taken one recently.
Deactivate every plugin
From Plugins, select all and choose Deactivate. Load the site and time it — this is your baseline, the speed of WordPress with nothing but the theme running.
Reactivate plugins one at a time
Turn one on, reload the site a couple of times, and note whether the load time changed noticeably. Then move to the next. This is tedious on a site with thirty plugins, but it is unambiguous, which the alternatives are not always.
Test more than the home page
Some plugins only cost anything on specific page types — a shop plugin on product pages, a forms plugin on the contact page. Test a post, a page, and any page type the plugin is meant to affect.

Do this on a staging copy if the site takes orders or logins

Deactivating plugins on a live shop or membership site, even briefly, can affect checkout or account functionality while you test. If that risk matters, do this on a staging copy instead. See creating a staging copy of your site.

Method 2: a query profiling plugin

Faster than the deactivate-and-test method, and it shows you the actual cause rather than just which plugin correlates with a slowdown. A profiling plugin such as Query Monitor adds a bar to the front end, visible to logged-in administrators, that breaks down exactly what happened to build the page: every database query, which plugin or theme function triggered it, how long each one took, and how many times a query ran when it should have run once.

What to look for once it is installed:

A large total query count. A typical page might run a few dozen queries. Hundreds is a sign that something is querying the database inefficiently, often inside a loop.
Duplicate queries. The same query run repeatedly usually means a plugin is fetching the same data separately for every item on a page instead of once for the whole page.
Slow individual queries. Most queries complete in a few milliseconds. One taking hundreds of milliseconds is worth investigating on its own, regardless of which plugin issued it.
External HTTP requests. Some plugins call out to a third-party service — a stock ticker, a social feed, a licence check — on every page load. If that remote service is slow, your site is slow, and no amount of local optimisation fixes it.

Remove the profiling plugin once you are done. It is a diagnostic tool, not something to leave running on a live site, since it adds its own overhead while active.

Method 3: WordPress's built-in Site Health

Under Tools → Site Health, the Info tab lists your active plugins along with basic server details. It will not point at a specific culprit the way a profiler does, but it is a useful first check for anything obviously wrong — a very old PHP version, or a plugin flagged as no longer maintained, both of which correlate with poor performance more often than chance would suggest.

What to do once you have found it

Check for an update. A plugin's performance problems are sometimes already fixed in a newer release you have not installed.
Look for a lighter alternative. Plugins doing the same job vary enormously in how efficiently they do it — this is common with SEO, forms, and "all-in-one" plugins that do far more than most sites need.
Check its settings. Some plugins have features you are not using turned on by default, each adding its own database queries. Turning off what you do not need sometimes solves the problem without removing the plugin at all.
Remove it properly if you decide to. See removing a WordPress plugin properly rather than just deactivating it.

If the slow plugin turns out to be essential and there is no lighter alternative, server-side caching can often absorb the cost for logged-out visitors even if it cannot fix the underlying query — see setting up caching on WordPress.

Frequently asked questions

Does the number of plugins alone slow a site down?

Not directly. A site with thirty lightweight, well-written plugins can outperform a site with three badly written ones. What matters is what each plugin does on every page load — how many database queries it runs, whether it loads its own CSS and JavaScript everywhere or only where needed, and whether it makes external requests. See how many plugins is too many.

Can a plugin be slow only on certain pages?

Yes, and this is a common trap. A plugin that adds a contact form, for example, might only load its scripts on the page containing the form — or, if written badly, on every page regardless of whether the form appears. Test more than one page type before ruling a plugin out.