I once took over a client site running 47 plugins. The homepage loaded in 11 seconds. After removing 19 plugins and replacing 6 others with lighter alternatives, load time dropped to 2.8 seconds. Same hosting, same theme, same content. The only thing that changed was the plugin stack.
Every plugin you install adds PHP execution time, database queries, and often CSS and JavaScript files that load on every single page. Some plugins add a little. Others add a lot. And the worst offenders? They load their assets everywhere, even on pages where they’re not used.
The average WordPress site runs 20-30 plugins. That’s not automatically a problem. I’ve seen sites with 40 plugins load in under 2 seconds, and sites with 12 plugins that took 6 seconds. The number isn’t what matters. What matters is which plugins you’re running and how they behave.
This chapter gives you a systematic process for auditing every plugin on your site, finding the ones dragging you down, and making smart decisions about what stays and what goes.
The Plugin Audit Process
Most people approach plugin performance the wrong way. They Google “slow WordPress plugins” and start deleting things from a list someone else made. That’s backwards. Your site is unique. The plugin that’s killing your performance might work fine on someone else’s setup, and vice versa.
I use a methodical process that I’ve refined over hundreds of client audits. It takes about an hour for a typical site, and it gives you hard data instead of guesswork.
Step 1: Baseline Your Current Performance
Before you touch anything, measure where you stand right now. Run three tests on your homepage and three on your most-visited inner page. Use GTmetrix or WebPageTest. Write down these numbers:
Fully loaded time (the total time until nothing else is loading)
Total requests (how many files the browser had to download)
Page size (total weight of everything downloaded)
TTFB (Time to First Byte, your server response time)
Number of JavaScript files and their combined size
Number of CSS files and their combined size
Average the three tests for each page. This is your baseline. Everything you do from here gets compared against these numbers.
Step 2: The One-by-One Deactivation Test
This is tedious. I won’t pretend otherwise. But it’s the only way to get accurate data.
Go to your plugins list. Start with the plugin at the top. Deactivate it. Run your speed test. Write down the numbers. Reactivate it. Move to the next one.
Yes, this takes time. On a site with 30 plugins, you’re looking at 60-90 minutes of testing. But you’ll walk away with exact data on what each plugin costs you. I’ve done this on hundreds of sites, and every single time it reveals at least one surprise, a plugin nobody suspected was the bottleneck.
A few tips to make this faster. Only test one page (your homepage is usually best). Use a tool like GTmetrix that gives consistent results. Don’t test during peak traffic hours when your server is under load. And clear your cache between each test so you’re comparing apples to apples.
Step 3: Categorize Your Results
Once you have data for every plugin, sort them into three categories:
Negligible impact (under 50ms and no extra requests): These are fine. Don’t waste time on them.
Moderate impact (50-200ms or 2-5 extra requests): Worth investigating. Can you replace these with lighter alternatives?
Heavy impact (200ms+ or 5+ extra requests): These need action. Either replace them, configure them better, or remove them entirely.
Using Query Monitor to Find Problem Plugins
Chrome DevTools tells you about the frontend. But half the performance story happens on the server, before the browser even gets involved. That’s where Query Monitor comes in.
Query Monitor is a free WordPress plugin (yes, a plugin to find bad plugins) that shows you exactly what’s happening during every page load. I install it on every client site during an audit and remove it when I’m done.
What to Look For
After installing and activating Query Monitor, you’ll see a new toolbar at the top of your admin bar. The numbers it shows you right away are telling.
Database queries: A well-built WordPress site generates 20-40 queries on a typical page. If you’re seeing 150+, something is wrong. Click into the queries panel and sort by time. You’ll see exactly which plugin is generating the slowest queries. I’ve found plugins running 60+ queries on every page load. That’s not a plugin. That’s a database attack.
HTTP API calls: Some plugins make external API calls on every page load. Checking for updates, fetching social share counts, loading remote resources. Each call adds latency because your server has to wait for a response from somewhere else on the internet. If a plugin is making HTTP requests on frontend page loads (not just admin), that’s a red flag.
Hooks and actions: Query Monitor shows you how many hooks each plugin fires. This isn’t always a problem by itself, but a plugin that hooks into 50+ actions is doing a lot of work. Cross-reference this with the query data to find the real offenders.
Conditionals: This tab shows you which template files WordPress is using and which conditional checks are happening. It’s less about performance and more about understanding how your theme and plugins interact.
Real Example
On a client site last year, Query Monitor showed me that a social sharing plugin was running 23 database queries and 4 HTTP API calls on every single page load. The HTTP calls were fetching share counts from Facebook, Twitter, Pinterest, and LinkedIn. Each call took 200-400ms. On a bad day, that single plugin added over a second to every page load.
We replaced it with a plugin that caches share counts and only refreshes them every 12 hours. Same functionality. Zero per-page API calls. Page load dropped by 800ms.
Reading the Waterfall Chart
Open Chrome DevTools (F12 or right-click and Inspect), go to the Network tab, and reload your page. You’ll see a waterfall chart showing every resource the browser downloads, in order, with timing information.
This is one of the most useful debugging tools you have, and most people never look at it.
What the Waterfall Tells You
Each bar in the waterfall represents one file. The length of the bar shows how long it took to download. The position shows when it started. And the color coding tells you what type of file it is.
Look for these specific problems:
Long bars at the top: Your HTML document should load fast. If the first bar is long (over 500ms), your server is slow. That’s a hosting or caching issue, not a plugin issue.
Clusters of small files: If you see 15 JavaScript files loading one after another, that’s 15 separate HTTP requests. Each one has overhead. Plugins that enqueue lots of small files are worse than plugins that bundle everything into one.
Files loading from external domains: You’ll see requests going to fonts.googleapis.com, ajax.googleapis.com, cdn.sometracker.com, and similar. Each external domain requires a DNS lookup, which adds 50-100ms the first time. If you count 8-10 different external domains, that’s real overhead.
Render-blocking resources: Look at the blue “DOMContentLoaded” line and the red “Load” line. Everything before the blue line is blocking your page from rendering. If you see plugin CSS files loading before that line, they’re delaying your visible content.
The Third-Party Problem
Sort the waterfall by domain. Count how many different domains are involved. I’ve seen sites making requests to 25+ different domains. Analytics scripts, font services, chat widgets, social embeds, tracking pixels, retargeting cookies. Every single one adds load time.
Each external domain typically costs you 100-300ms in DNS + connection + download time. If you’ve got 10 third-party scripts, you’re looking at 1-3 seconds just from things that aren’t even on your server.
Plugins I Always Remove (and What to Replace Them With)
After 800+ client projects, I’ve developed strong opinions about specific plugins. These are the ones I remove almost every time I find them.
All-in-one “optimization” suites that try to do everything. Plugins that combine SEO, caching, security, and performance into one package almost always do each job poorly. You’re better off with dedicated plugins for each task. One focused caching plugin will outperform the caching module of an all-in-one suite every time.
Social sharing plugins that fetch counts in real-time. Switch to one that caches counts or skip share counts entirely. I stopped showing share counts on my own site years ago. Nobody clicks more because a button says “47 shares.”
Related posts plugins that query the database on every page load. These are performance killers. They often run complex LIKE queries across your entire posts table. If you need related posts, use a plugin that pre-calculates relationships and caches results, or just hand-pick them.
Contact form plugins that load CSS and JavaScript on every page. Your contact form is on one page. Why is the plugin loading 40KB of JavaScript on your blog posts? Look for a form plugin with conditional loading, or manually dequeue its assets on pages that don’t need them.
Analytics plugins that add JavaScript to your frontend. You don’t need a WordPress plugin to add a Google Analytics script. A simple code snippet in your theme’s header does the same thing without the overhead of a full plugin. Or better yet, use a server-side analytics solution.
Visual page builder plugins on sites that don’t need them. If you built your site with a page builder two years ago and haven’t touched the builder since, you’re still loading hundreds of kilobytes of builder CSS and JavaScript on every page. For sites that are “done,” consider converting the builder output to native blocks and removing the builder entirely.
The “Do I Really Need This?” Framework
For every plugin on your site, ask these five questions:
Is this plugin doing something I actually use? I’ve found active plugins on client sites that nobody remembered installing. A migration plugin still active two years after the migration. A coming-soon plugin on a live site. A plugin for a feature they tried once and forgot about. Check your plugin list right now. I bet there’s at least one you don’t need anymore.
Can native WordPress do this? WordPress core has gotten better over the years. Things that used to need plugins, like responsive images, lazy loading, basic sitemaps, and custom CSS, are now built in. If you installed a plugin for something WordPress added to core after the fact, you might be running duplicate functionality.
Can a code snippet replace this? If a plugin does one small thing and that thing can be done with 5-10 lines of PHP in your functions.php (or a code snippets plugin), the code snippet is almost always better. Less overhead, fewer updates to manage, fewer potential conflicts.
Is there a lighter alternative? For every popular heavy plugin, there’s usually a lighter alternative that does 80% of the work at 20% of the performance cost. You don’t need every feature. You need the features you actually use.
What happens if I remove this? Some plugins are scared cows. People are afraid to remove them because “what if something breaks?” Here’s my approach: deactivate (don’t delete) and check your site. If nothing breaks after a day, it probably wasn’t doing anything critical.
Replacing Plugins with Code Snippets
I keep a library of code snippets that replace common plugins. A few of the most useful ones:
Disable WordPress emojis. WordPress loads an emoji script on every page. If you’re not writing emoji-heavy content (and your readers have modern browsers, which they do), this is wasted load. Five lines of PHP removes it.
Remove jQuery Migrate. WordPress loads jQuery Migrate for backward compatibility with old plugins. If all your plugins are up to date, you probably don’t need it. That’s 10KB of JavaScript gone.
Limit post revisions. WordPress stores every revision of every post. On a site with 500 posts and unlimited revisions, that’s thousands of extra database rows. A single line in wp-config.php limits this and keeps your database lean.
Add async or defer to scripts. Instead of a plugin that “optimizes” script loading, you can add async or defer attributes with a small PHP filter. Though I’d recommend a proper caching plugin for this since they handle it more thoroughly.
Disable RSS feeds if you don’t need them. Most sites don’t actively promote their RSS feed. If nobody’s using it, a few lines of PHP removes it and the associated overhead.
The point isn’t that you should never use plugins. The point is that you should question whether each plugin earns its place. A plugin that saves you hours of development time is worth its performance cost. A plugin that replaces five lines of PHP is not.
Plugin Alternatives: Lighter Versions of Heavy Plugins
I won’t name names on the “bad” side (you know the usual suspects). But here’s my thinking on choosing lighter alternatives.
For any plugin category, look at the frontend footprint first. Install the plugin, load your site, and check how much CSS and JavaScript it added. A contact form plugin that adds 200KB to every page is not the same as one that adds 15KB only on the contact page.
Check the database query count before and after with Query Monitor. If a plugin adds 20+ queries to every page load, that’s heavy. Most well-built plugins add zero queries on pages where they’re not active.
Look at whether the plugin conditionally loads its assets. Good plugins only load their CSS and JavaScript on pages where they’re actually used. Bad plugins load everything everywhere. This single behavior is the difference between a fast plugin and a slow one.
And pay attention to external dependencies. A plugin that loads five files from three different CDNs is adding latency you can’t control. A plugin that keeps everything local gives you more predictable performance.
The Plugin Count Myth
People love to debate the “right” number of plugins. You’ll see articles claiming you should have no more than 10, or 15, or 20. These numbers are meaningless without context.
I’ve worked on a WooCommerce site with 55 plugins that loaded in 1.8 seconds. Good hosting, good caching, well-built plugins that only loaded on the pages that needed them. And I’ve worked on a blog with 8 plugins that took 5 seconds because two of them were disasters.
The number doesn’t determine performance. The quality of each individual plugin does. But I’ll add a caveat: fewer is usually better. Not because of some magic number threshold, but because every plugin is a maintenance burden, a potential security risk, and a possible conflict waiting to happen. If you can do the same thing with 20 plugins instead of 30, you should. Not for speed, necessarily, but for sanity.
The goal of a plugin audit isn’t to hit some arbitrary number. It’s to make sure every plugin on your site earns its spot. If a plugin adds value and performs well, keep it. If it doesn’t… it’s time to go.
Chapter Checklist
- [ ] Record baseline performance numbers before making any changes
- [ ] Install Query Monitor and check database queries per page
- [ ] Deactivate each plugin one by one and measure the impact
- [ ] Sort plugins into negligible, moderate, and heavy impact categories
- [ ] Check Chrome DevTools Network tab for render-blocking resources
- [ ] Count how many external domains your site makes requests to
- [ ] Remove or deactivate any plugins you’re no longer using
- [ ] Replace at least one heavy plugin with a lighter alternative or code snippet
- [ ] Verify native WordPress can’t handle tasks currently done by plugins
- [ ] Re-test your site after making changes and compare to baseline
Chapter Exercise
Do a full plugin audit on your site right now. Start by recording your baseline numbers. Then deactivate each plugin one at a time, testing after each one. Build a spreadsheet with three columns: Plugin Name, Load Time Impact, and Keep/Replace/Remove. When you’re done, act on the “Remove” list immediately and research alternatives for the “Replace” list. Compare your final numbers to your baseline and document how much you improved.