Performance
Why your site got slower after adding a plugin
5 August 2026 · 6 min read
On this page
Plugin count matters less than people think. Thirty well-built plugins can be fine. Three badly built ones can be fatal. The useful question is not "how many" but "which one".
What makes a plugin slow
Queries on every page load. A related-posts plugin that runs a complex query on every request, including pages with no related posts to show.
Loading assets everywhere. A contact form plugin that loads its CSS and JavaScript on all 400 pages of your site, including the 399 without a form. This is the most common offence.
Its own copy of jQuery. Now two libraries load instead of one.
External API calls during page load. A social feed plugin fetching from an API while the visitor waits. If that API is slow, so is your page.
Writing to the database on every visit. Analytics and popup plugins that log each view.
Autoloaded options. Settings marked to load on every request. Enough of these and every page pays.
Finding the culprit
Query Monitor, first
Install Query Monitor (free). It adds a toolbar showing, for the page you are on: total queries, time spent, memory used, and crucially which plugin is responsible for each query.
Look for: a plugin with dozens of queries, any single slow query, total queries over about 100, or page generation time over a second.
This usually names the offender in five minutes without any elimination testing.
Elimination, if Query Monitor is inconclusive
On a staging copy, never live:
- Measure the page with GTmetrix — three runs, take the median
- Deactivate one plugin
- Measure again
- Reactivate, move to the next
Tedious, and conclusive. Do it in the order Query Monitor suggested to save time.
Check what is loading
Chrome DevTools → Network, filter to JS and CSS. Look at the filenames — most will contain the plugin folder name. Anything loading on a page where the plugin does nothing is waste.
The usual suspects
Not universally bad, but the categories that most often cause problems:
- Page builders — large CSS and JavaScript bundles on every page
- Sliders — heavy, and usually for one element on one page
- "All-in-one" suites — loading twenty features to use two
- Related posts and popular posts — expensive queries
- Social feeds — external API calls in the request path
- Live chat widgets — third-party scripts you do not control
- Statistics plugins — a database write on every page view. Use Google Analytics or a hosted alternative instead
What to do when you find it
Delete it, if you can live without it. The fastest fix, and more often viable than people expect.
Replace it. There is usually a lighter alternative — a simpler form plugin, native WordPress galleries, a block instead of a shortcode.
Limit where it loads. Some plugins offer this. Otherwise, a plugin like Asset CleanUp or Perfmatters lets you disable specific scripts on specific pages, which fixes the "form CSS on every page" problem without removing the plugin.
Cache around it. Page caching hides the cost for anonymous visitors, because the expensive work happens once. It does not help logged-in users or dynamic pages, so this is mitigation rather than a fix.
Deactivating is not deleting. A deactivated plugin no longer runs, but the code is still on your server and still a security consideration. If you have decided you do not need it, delete it.
The prevention
Before installing anything, three questions: what does this actually do that I need, when was it last updated, and how many active installs does it have?
And then a quarterly audit. Open the plugin list, and for each one ask whether you would install it today. Most sites are carrying two or three plugins nobody remembers adding and nothing depends on.
That audit is on the maintenance checklist and included in the care plans — it is dull, takes twenty minutes, and is frequently the largest single performance improvement available.