How to fix WordPress slow after a plugin install

The pattern is specific. Yesterday the site was fine, today you installed or activated a plugin, and now something is slower. Maybe wp-admin feels sluggish. Maybe the public homepage takes an extra second to render. Maybe both. The job in this article is to confirm that the new plugin is actually the cause and to figure out what to do about it without playing whack-a-mole with deactivations.

What you will end up with

A clear answer to one question: is the plugin you just installed the actual cause of the slowdown, and if so, which of three actions resolves it: keep and tune, replace with a lighter alternative, or remove entirely. The procedure works for both front-end slowness and admin slowness.

Before you start

This procedure assumes you can do all of the following on the affected site:

• Log in to wp-admin as an administrator. If the slowdown locked you out of the admin entirely, the critical error article covers the path back in first.
• Install and activate two free plugins from the WordPress.org repository: Health Check & Troubleshooting and Query Monitor. Both are maintained by trusted contributors and ship under GPL.
• Open browser developer tools in a Chromium-based browser. The Network panel and the Performance panel are the only ones used here.
• Reach a staging copy of the site if the production site is busy enough that profiling under load is impractical. A staging copy is not required, but it removes the worry that troubleshooting mode briefly hides plugins from real visitors.
• Know which plugin you just installed or updated. The "I just installed something" framing is the entire premise of the procedure. If you cannot point at a specific plugin, the better starting point is the general slow WordPress site article.

Step 1: Confirm the plugin is actually the cause

The first job is to rule out coincidence. Plugins are not the only thing that can change the performance picture on a Tuesday afternoon. A traffic spike, a backup window, an external API outage, or a cron job firing on the hour will all produce a slowdown that lines up with whatever you happened to do five minutes earlier. Health Check's Troubleshooting Mode is the cleanest way to isolate the variable, because it turns the active plugin set off for your session only, and lets you turn one plugin back on at a time.

1. In wp-admin, go to Tools : Site Health : Troubleshooting.
2. Click Enable Troubleshooting Mode. The page reloads and a banner appears at the top of the admin: "You are in Troubleshooting Mode."
3. The site now runs the default theme (currently Twenty Twenty-Four) with all plugins disabled, but only for your logged-in session. Public visitors still see the live site with all plugins active.
4. From the same Site Health screen, click Plugins. Re-enable only the plugin you suspect, by clicking Enable while troubleshooting next to its name.
5. Reload the front end of the site in an incognito window where you are not logged in, then reload the admin in your normal browser.

Expected output. With only the suspect plugin active and a default theme, the page is now running approximately the WordPress core code path plus that one plugin. If the site is fast, the suspect plugin alone is not the cause. If the site is still slow, you have just isolated the cause to that single plugin and the comparison is unambiguous. The Health Check plugin documentation describes the mechanism in detail.

If the plugin is innocent in isolation but the live site is still slow with everything turned back on, the cause is an interaction with one of the other active plugins. Repeat the procedure: enable the suspect plus one other plugin at a time, in order of likelihood, until the slowdown reproduces. This is slower than blanket deactivation but it is the only method that will not lie to you on a complex site.

When you are done, click Disable Troubleshooting Mode in the admin banner. The original plugin set comes back exactly as it was. Troubleshooting mode is per-session and does not touch the database state of any plugin.

Step 2: Profile what the plugin is doing on every request

Once you know which plugin is responsible, the next question is what it actually does to make a page slower. The honest answer is almost always one of four things: it runs database queries that nothing was running before, it loads PHP and assets that nothing was loading before, it makes an HTTP call to an external service that did not happen before, or it adds work to a hook that fires on every request. Query Monitor surfaces all four directly.

1. With the live plugin set restored and the suspect plugin enabled, install Query Monitor if you have not already. Activate it.
2. Reload any page on the front end while logged in as an administrator. Query Monitor adds a black admin bar entry at the top right showing page generation time, memory peak, database query count, and database query time. A reference number for "normal" on a typical small WordPress page is roughly 30 to 80 queries and 20 to 80 ms of database time, with total page generation under 300 ms. Numbers well above that are the signal.
3. Click the admin bar entry to open the Query Monitor panel.
4. Open Queries : Queries by Component. Look for the suspect plugin in the component list. The number next to it is how many queries that plugin is running on every page load, and the time column is what those queries cost.
5. Open HTTP API Calls. WordPress's HTTP API is what plugins use to talk to remote services, and Query Monitor logs every call made during a request along with how long it took. A plugin making a remote call on every page load is a common cause of admin slowness, especially for paid plugins that phone home to a license server.
6. Open Hooks & Actions. The list of hooks the suspect plugin is attached to tells you whether the plugin runs only on rare events or on the main init, wp, wp_enqueue_scripts, or template_redirect path that fires on every page.
7. Open Scripts and Styles. Plugins that enqueue large JavaScript bundles or third-party fonts on every page load move the cost into the browser layer, where it shows up as a worse Largest Contentful Paint instead of a worse server response time. Query Monitor lists the file sizes and origins.

Expected output. You now have a measured profile: how many queries the plugin runs, how long they take, whether it makes external HTTP calls and how long those take, which hooks it runs on, and what scripts and styles it enqueues. That profile is the evidence you need for Step 4. The Query Monitor plugin page documents each panel.

A plugin doing a single 5 ms query on init is harmless. A plugin doing 80 queries totaling 400 ms on template_redirect is the entire problem. A plugin making one synchronous HTTP call to an external API on every admin page load is the entire problem. The numbers will tell you which case you are in.

Step 3: Look for performance toggles in the plugin's settings

Most plugins that produce a measurable slowdown have at least one setting that controls how often the expensive thing runs. The ones that do not have such a setting are usually replaceable. Open the plugin's settings page in wp-admin and look specifically for these patterns:

• Polling and refresh intervals. A plugin that fetches data from an external service on every page load will sometimes let you raise the cache interval to once an hour or once a day. Look for words like "refresh interval", "cache duration", "update frequency", "TTL".
• Built-in caching toggles. SEO plugins, schema plugins, related-posts plugins, and analytics plugins frequently ship with their own cache layer that is off by default. Turn it on.
• Background processing or cron settings. Backup plugins, security scanners, image optimizers, and analytics plugins can usually be moved off the request path and onto WP-Cron or a system cron, so they do not run on the user's request thread. Look for "schedule", "background", "queue", "cron".
• Logging verbosity. Security and debug plugins frequently log to the database on every page load at the default verbosity. Lowering the verbosity, or moving the log target to a file, removes a write per request from the database.
• Third-party endpoints. Payment, social, analytics, and chat plugins call out to vendor APIs on schedules you can usually configure. Find the endpoints in settings, lengthen the interval, or disable any calls you do not actually use.
• License check frequency. Premium plugins from EDD-, FastSpring-, or Paddle-style stores typically check the license on a schedule. Some let you change that interval. The license check is not load-bearing for the front end, only for the admin, so a slow check produces the very specific symptom of a slow wp-admin while the public site is fine.

Expected output. Either you found a setting that, in theory, should reduce the work the plugin does on each request, or you confirmed that there is no such setting and the plugin's expensive behavior is not user-configurable. Both outcomes feed Step 4.

After changing any setting, re-run the Query Monitor profile from Step 2 on the same page and check whether the query count, query time, HTTP API time, or memory peak dropped. The numbers either moved or they did not.

Step 4: Decide: tune, replace, or remove

You now have a measured profile and you know whether the plugin is configurable. The decision falls into one of three buckets.

Tune and keep, when: the plugin's settings let you cut its measured cost into the same range as the rest of the active plugins, the plugin provides functionality you actually need, and a quick search of the plugin's WordPress.org support forum shows that other users with the same complaint had it resolved by similar settings or by an update from the developer. Subscribe to the plugin's update channel and re-profile after every release.

Replace, when: the plugin's measured cost is significantly out of line with its peers, it has no settings that move the numbers, the functionality is genuinely valuable, and a lighter alternative exists in the same category. The replacement is only an improvement if you profile it the same way before committing. Do not assume "lighter" without measuring. Run Step 2 against the candidate replacement on the same page on a staging copy before swapping it on production.

Remove, when: the plugin's measured cost is significantly out of line, the functionality it provides is nice-to-have rather than load-bearing, or you cannot find a replacement that profiles meaningfully better. Removing a plugin is the only fix that is guaranteed to recover the cost the plugin was adding. Every other fix only reduces it.

A useful rule from operating dozens of WordPress sites: the cost of a plugin is not what its readme advertises and not what the marketing page claims. The cost is what Query Monitor measures on your site, on your hosting, with your other plugins active, on the pages your visitors actually request. Make the decision on those numbers, not on intuitions about plugin quality.

Step 5: Verify the fix on the live site

Once you have tuned, replaced, or removed the plugin, the last step is to confirm that the slowdown is actually gone, not just hidden behind a fresh cache. The trap is that a full-page cache will make the front end feel fast for the first few minutes after any change, even if the underlying plugin cost is still there. You need to measure both a cached page (the path most visitors take) and an uncached path (the worst case).

1. Reload the same front-end page you profiled in Step 2 in an incognito window. Open the browser DevTools Network panel before the navigation so it captures the load. Note the value in the TTFB column for the document request and the time at which the largest hero image, headline, or block paints. Web.dev's LCP guidance places the "good" threshold at 2.5 seconds or less.
2. Reload the same page logged in as an administrator. Logged-in requests bypass the full-page cache by design and exercise the full PHP and database path on every request. This is the harder test. Compare the new Query Monitor numbers to what you saw in Step 2 on the same page.
3. If the slowdown only affected wp-admin, reload the dashboard pages where you originally felt the problem (Posts, Pages, Updates) and watch the Query Monitor admin bar for the page generation time. Compare against your Step 2 baseline.
4. Wait fifteen minutes and repeat the front-end test. A real fix stays. A fix that only appeared to work because something happened to be cached at the moment will visibly come back in this window.

Expected output. Lower query count, lower query time, lower HTTP API time, lower page generation time, or all four, on the same pages you measured in Step 2. The change is the verification. If the numbers did not move, the fix did not work, regardless of how the page subjectively feels.

Common things that go wrong

These are the recurring traps when running this procedure. Each one points to a related KB article.

• The slowdown does not reproduce in incognito. A logged-in browser session bypasses the full-page cache and exercises a heavier code path. Front-end visitors are seeing a faster site than you are, and the slowdown you feel is the admin slowness pattern covered above plus the broader admin path. If only the admin is slow, the procedure still applies but the verification target changes. The PHP-FPM worker pool can also be a contributing factor on busy sites; see the PHP workers exhausted article.
• The slowdown intermittently disappears after activating Troubleshooting Mode. Troubleshooting Mode is per-session, but its activation flushes object cache. If the site is fast for the first few requests after activation and then slows again, something is being repopulated into the cache that should not be there. Profile what gets cached on the first slow request after warming.
• The plugin profiles fine on the homepage but the site is still slow. Profile the actual page where you noticed the slowdown, not the homepage. Plugins frequently behave differently on archive pages, cart pages, search result pages, and admin list views than on the front page. Query Monitor's numbers are per-request.
• The plugin makes the server hit its CPU ceiling under load even though it profiles fine in isolation. A single page load profiles cleanly, but every additional concurrent visitor multiplies the cost. The cause is no longer just the plugin but the CPU ceiling the plugin is now pushing the site against. Address both: tune the plugin and check whether the hosting plan is appropriate for the actual concurrency.
• The slowdown persists after fully removing the plugin. A plugin can leave behind autoloaded options in wp_options that continue to be loaded on every request even after deactivation. Look in Tools : Query Monitor : Queries for autoloaded options from the removed plugin's prefix and remove them by hand if the uninstall did not. The general slow site framing is in the slow WordPress site article, and high server response times specifically are covered in the high TTFB article.
• The slowdown started after a plugin update rather than a plugin install. Same procedure, different sibling article. The slow after update concept article covers the temporary-versus-structural distinction that matters for updates and not for fresh installs.

Where to go next

If the procedure confirmed that the new plugin is the cause and the fix held in Step 5, you are done. If it confirmed the plugin and the fix did not hold, the cost is now in an interaction layer (caching, the database, or the worker pool) and the next read is the layer-specific article: high TTFB for slow server responses, PHP workers exhausted for slowdowns under concurrency, high CPU usage for hosting-quota saturation. If the procedure ruled out the plugin entirely, the cause is somewhere else on the site and the slow WordPress site article is the right starting point.