How to Find Which WordPress Plugin Is Slowing Down Your Site

Your site was fast enough. Then something changed. Pages take longer to load, the admin dashboard grinds, or your PageSpeed score dropped without an obvious reason.

Plugins are often the first thing to check. A single plugin can add database queries, load scripts on every page, run frequent background tasks, or call external services on every request. The difficult part is knowing which one.

This guide shows you how to find the slow plugin safely. No guessing, no disabling things randomly on your live site, no developer access required for most cases.

If your slowdown started immediately after installing or updating one specific plugin, skip to Step 4. If you are not sure when it started, work through the steps in order.

Before You Start

Quick Fix Summary

1. Take a backup.
2. Measure your current speed score with PageSpeed Insights.
3. Enable Health Check troubleshooting mode and disable all plugins in your session.
4. Re-enable plugins in groups to narrow down the slow one.
5. Confirm the culprit, then remove, replace, or reconfigure it.

Step 1: Measure Your Baseline Speed Score

Before disabling anything, measure where your site stands right now.

Go to PageSpeed Insights and test your homepage and one other important page (a product page, booking page, or blog post).

Write down:

• Performance score (0 to 100)
• LCP (Largest Contentful Paint) - good threshold is under 2.5 seconds
• INP (Interaction to Next Paint) - good threshold is under 200 milliseconds
• CLS (Cumulative Layout Shift) - good threshold is under 0.1
• Total load time

You need this baseline to confirm whether disabling a plugin actually helps. A consistent improvement of 10 or more points in the Performance score is a real signal.

For a second data point, also run your URL through GTmetrix. Its waterfall chart shows which scripts and requests take the longest, which helps you spot heavy external calls even before you start disabling plugins.

Note: Run the same URL twice on PageSpeed Insights. Field data and lab data can vary slightly between individual tests. Use the average as your baseline.

Step 2: Install Health Check and Enable Troubleshooting Mode

Install the Health Check and Troubleshooting plugin from WordPress.org. It is free and maintained by the WordPress.org meta team.

After installing, go to Tools > Site Health in your admin dashboard. Click the Troubleshooting tab, then click Enable Troubleshooting Mode.

What troubleshooting mode does:

• Disables all other plugins for your admin session only.
• Visitors continue to see the site normally with all plugins active.
• You can re-enable individual plugins from a floating toolbar that appears at the top of every page.
• You can also switch your session to the default WordPress theme without affecting visitors.

This is the right way to test plugin isolation on a live site. Disabling plugins directly from the Plugins menu would affect all visitors immediately, which you want to avoid.

Stay logged in during testing. If you log out, troubleshooting mode ends automatically and all plugins return to their normal state for everyone.

Step 3: Test with All Plugins Disabled

While in troubleshooting mode (all plugins disabled for your session), run PageSpeed Insights again on the same pages from Step 1.

Compare the two scores.

Clear your cache before each test. If you have a caching plugin, disable it in your testing session or purge it manually. Also test in an incognito window to avoid browser cache affecting results.

Step 4: Isolate the Slow Plugin

With a confirmed improvement in Step 3, you now need to find which plugin caused it.

You have two approaches. Choose based on how many active plugins you have.

Approach A: Binary isolation (faster, works best with 10 or more plugins)

1. In the troubleshooting toolbar, re-enable half of your plugins.
2. Run PageSpeed Insights again.
3. If the score drops, the culprit is in the group you just re-enabled. Disable them again, then re-enable the other half.
4. Keep halving the group until you narrow it to one plugin.

Approach B: One by one (slower but precise, best for fewer than 10 plugins)

1. In the troubleshooting toolbar, re-enable one plugin at a time.
2. After each re-enable, run PageSpeed Insights or reload the page and check load time.
3. When the score drops or the page slows noticeably, you have found your plugin.

Important steps for both approaches:

• Clear the site cache and reload in an incognito window after enabling each plugin. Otherwise you may be reading cached results, not the plugin's actual impact.
• Test the same public-facing page each time. Do not switch between pages mid-test.
• Keep a simple note of which plugins you have enabled at each stage, so you can track which combination caused the drop.

Step 5: Use Query Monitor for Backend or Admin Slowdown

If the troubleshooting mode approach does not isolate one plugin, or if the slowdown is in the WordPress admin area rather than on public pages, use Query Monitor.

Query Monitor is a free debugging plugin with over one million active installs. It shows:

• All database queries, including how many ran, how long each took, and which plugin or file triggered them
• PHP errors and notices
• WordPress hooks and actions
• HTTP API calls to external services
• Slow queries (flagged when over 50ms)
• Memory usage per request

How to use it:

1. Install and activate Query Monitor from WordPress.org.
2. Load the page where the slowdown occurs.
3. The Query Monitor toolbar appears at the top of the page.
4. Click Queries to see all database queries sorted by execution time.
5. Check the Caller column to see which plugin or file triggered each query.
6. Click HTTP API Calls to see whether a plugin is making slow external requests.

What to look for:

• One plugin responsible for 30 or more queries on a single page load
• Any query taking 200ms or longer
• Repeated identical queries from the same plugin (a caching problem inside the plugin)
• HTTP API calls to external services adding several hundred milliseconds

Important: Query Monitor is a diagnostic tool. Remove it or deactivate it after you finish debugging. It is not meant to run on a production site continuously.

If you want to check background scheduled tasks, install WP Crontrol (free). It shows all WP-Cron events and which plugin registered them. A plugin that runs a cron task every few minutes can add unexpected server load.

Step 6: Distinguish Frontend Slowdown from Admin Slowdown

Not all plugin slowdowns look the same. Some plugins only slow the public-facing site. Others only slow the WordPress admin area. A few slow both.

Signs of frontend slowdown:

• PageSpeed score is low on public pages.
• Visitors report the site loads slowly.
• The GTmetrix waterfall chart shows extra scripts, stylesheets, or third-party requests loading on every page.
• The slowdown exists across multiple browsers and devices.

Signs of admin slowdown:

• The Posts list, Plugins page, or plugin settings pages take several seconds to load.
• The frontend loads normally for visitors.
• The admin slowdown started after activating a specific plugin.

For frontend slowdown, look for plugins that load assets on public pages where they are not needed. Common offenders include:

• Slider and carousel plugins loading scripts on every page, not just pages with a slider
• Social sharing plugins with external API calls
• Chat widget plugins that load third-party scripts site-wide
• Contact form plugins that inject CSS and JavaScript on pages with no forms

For admin slowdown, PageSpeed Insights is not useful since it measures public pages. Use Query Monitor in the admin area instead. Load the slow admin page and check which queries or hooks are running.

If your slowdown started after a specific plugin update, you can often roll back. On WordPress.org, go to the plugin's page and click the Advanced tab to find previous versions available for download.

If This Does Not Work

You disabled all plugins and the site is still slow. The problem is likely your theme, server resources, unoptimized images, or external CSS and font files. Run Lighthouse in Chrome DevTools (F12, then the Lighthouse tab) to see which specific factors are reducing your score. FS Code's WordPress speed optimization guide covers these additional layers in detail.

You cannot isolate a single plugin because the score changes with different combinations. This suggests a combined load problem or a plugin conflict rather than one clear culprit. Consider auditing your full plugin stack for overlap and redundancy. FS Code's guide on how many WordPress plugins are too many walks through how to identify load overlap and unnecessary duplication.

The slow plugin is one you cannot remove. Some plugins handle essential functions. In this case, check the plugin's settings for options to disable asset loading on pages where the plugin is not active. Many well-maintained plugins include an asset loading toggle. If the plugin lacks this option, check whether a premium version addresses performance, or contact the plugin vendor directly.

The slowdown only appears under real traffic, not during your manual tests. Single-user testing will not replicate this. You need server-level profiling or hosting performance dashboards. Contact your host's support team for this type of investigation. Shared hosting plans are also more likely to throttle resources under traffic than managed WordPress hosting.

Common Mistakes to Avoid

• Disabling plugins directly from the Plugins menu during testing. This takes the plugins offline for all visitors. Use Health Check troubleshooting mode instead.
• Not clearing the cache between tests. A cached page will make it look like disabling a plugin had no effect, even when it did. Always purge the cache and test in an incognito window.
• Only testing the homepage. Some plugins load only on specific post types or page templates. Test on the page type where visitors are experiencing the slowdown.
• Assuming the most recently installed plugin is always the problem. An older plugin may have added a slow feature in a recent update, or a conflict may have appeared after a WordPress core update.
• Installing a speed plugin before diagnosing. Adding a caching or optimization plugin on top of a slow stack can mask the real issue without fixing it. Find the problem first.
• Forgetting to re-enable all plugins after testing. When you exit troubleshooting mode, all plugins return to normal. But if you disabled a plugin permanently from the Plugins menu during testing, verify it is re-enabled if it is still needed.
• Removing a plugin without checking what data it stores. Some plugins leave database tables, option entries, or uploaded files behind after deletion. Note what the plugin stores before a full removal.

When to Ask for Help

Stop and contact your host or a WordPress developer when:

• The site returns a white screen or a 500 error during testing.
• Your host's dashboard reports high CPU or memory usage that does not match your site's traffic level.
• The slowdown only appears under real traffic load, not during manual single-user tests.
• Query Monitor shows expensive queries but you do not recognize the plugin or function triggering them.
• You have already isolated and removed the slow plugin but the performance score has not improved.
• Your site handles live bookings, payments, or orders and requires zero downtime during testing.

A developer can use server-level profiling tools (New Relic, hosting APM dashboards, or MySQL slow query logs) to find bottlenecks that are not visible at the WordPress admin layer.

Final Checklist

Before closing the issue:

• Baseline speed score recorded before any changes
• Backup created before testing started
• Health Check troubleshooting mode used throughout (not direct live-site disabling)
• Cache cleared between each test
• Frontend and admin area tested separately if relevant
• Slow plugin identified and removed, reconfigured, or replaced
• All plugins confirmed back in correct active/inactive state after testing
• Final speed score confirmed better than the baseline
• Site tested on the frontend for broken layouts, missing elements, or errors after all changes

If you found and removed the slow plugin and now need a lighter replacement, FS Code's guide on how to choose WordPress plugins covers performance as part of the evaluation criteria. If the goal is broader speed improvement beyond removing one plugin, FS Code's roundup of free WordPress speed optimization plugins is a practical next step.