A WordPress update slows a site down when the new code adds database queries, runs fresh HTTP calls to outside services, or simply exposes a problem a cache had been hiding. The fix is to isolate which plugin, theme, or core component changed behavior, rather than guessing from the symptom alone. The diagnosis follows a fixed order: measure what changed, isolate the component causing it, and confirm the fix against a defined standard. Each step uses a specific, free tool, and skipping the isolation step is the most common reason a site owner reverts the wrong plugin.
Table of Contents
- Confirm What Actually Slowed Down
- Isolate the Plugin or Theme With Troubleshooting Mode
- Read the Database Queries and HTTP Calls Directly
- Know That the Update Itself Can Be the Bug
- Confirm the Fix
- Frequently Asked Questions
Confirm What Actually Slowed Down
Before touching any plugin, establish a baseline using Google's Core Web Vitals, the metrics PageSpeed Insights reports for real-world page experience. Google defines "good" performance as a 75th-percentile Largest Contentful Paint (LCP) of 2.5 seconds or less, an Interaction to Next Paint (INP) of 200 milliseconds or less, and a Cumulative Layout Shift (CLS) of 0.1 or less — scores worse than 4 seconds, 500 milliseconds, or 0.25 are rated "poor," according to Google's web.dev documentation on Core Web Vitals thresholds. Run a PageSpeed Insights check now and compare it to any past report you have. If LCP jumped specifically, the cause is usually a slow server response or a heavier asset.
If INP got worse, a script added by the update is likely blocking the browser's main thread. This distinction narrows where to look next, before any plugin is touched. An update is harder to diagnose than a slow new install because it changes code already running across files that were previously stable, and because an update can simply clear a cache that had been quietly masking an already-slow query, according to a WordPress knowledge-base guide from Jorijn.com. That means the update may not be the direct cause — it may have just removed the thing that was hiding an existing problem.
Isolate the Plugin or Theme With Troubleshooting Mode
The standard isolation method, recommended across WordPress plugin support forums, is to back up the site, clear every cache, deactivate all plugins, switch to a default theme, then reactivate plugins one at a time, retesting after each, until the slowdown returns — that reactivation is what names the culprit, according to a support thread on WPML.org. This is deliberate, binary-search-style elimination, not a guess based on which plugin "feels" heavy. Doing this on a live site risks showing visitors a broken, half-configured page mid-test.
The WordPress.org Health Check & Troubleshooting plugin solves that: its "Troubleshooting Mode" disables every other plugin and switches to a default theme only for the logged-in admin's own session, leaving the site visitors see completely unchanged, according to the Health Check & Troubleshooting plugin page on WordPress.org. You can test and retest without taking the live site offline for anyone else. Work through plugins in a deliberate order rather than alphabetically:.
- Reactivate the plugin or plugins that were actually updated first, since that is the most likely source.
- Reactivate anything that touches the database heavily (SEO plugins, caching plugins, forms, e-commerce) next.
- Reactivate the rest last, since they are less likely to be the cause.
Read the Database Queries and HTTP Calls Directly
Elimination by reactivation tells you which plugin is responsible; it doesn't tell you why. The Query Monitor plugin, available on WordPress.org, flags slow, duplicate, and erroneous database queries and lets you filter them by the specific plugin, theme, or core component responsible — which makes it the standard tool for isolating the exact code behind an update that's causing a slowdown, according to the Query Monitor plugin page. Query Monitor also lists PHP errors with their responsible component and full call stack, and critically, every outgoing HTTP API request the page makes.
New or slower external calls — a license check, a stock feed, a tracking pixel — added by an updated plugin are a common post-update cause of added load time, per the same Query Monitor documentation. A plugin update doesn't have to touch your database at all to slow the page down; it only has to add a call to a remote server that responds slowly. GreenGeeks documents a concrete case of this: Query Monitor traced a site slowdown to database queries generated by the Broken Link Checker plugin, showing the measurable cause was the plugin's background scanning, not the page template or theme, according to GreenGeeks' glossary entry on Query Monitor. The lesson generalizes — a plugin that scans, syncs, or checks something in the background can slow every page load even when it never appears in the visible page content.
Know That the Update Itself Can Be the Bug
Sometimes the plugin isn't misconfigured — the new version shipped with a genuine performance regression. The hosting provider wpcharged.nz reported that Yoast SEO version 7.0.2 raised server time-to-first-byte by roughly 50% in its own testing, a regression that was corrected in the following 7.1 release, according to wpcharged.nz's writeup.
That is a documented instance of a widely used plugin's update itself being the defect, not a conflict with the rest of the site. This matters for how you respond once Query Monitor or troubleshooting mode names a culprit. Check the plugin's changelog and support forum for other reports of the same version before assuming your site is uniquely misconfigured — if others report the identical symptom tied to the identical version number, the fastest fix is often waiting for or forcing the next point release, not reconfiguring anything on your own site.
- If the slowdown traces to one plugin version specifically, search that plugin's support forum for the version number plus "slow" before changing settings.
- If a fix is already released in a newer version, updating again may resolve the issue the previous update caused.
- If no fix exists yet, temporarily rolling back to the prior version (via the plugin's WordPress.org advanced view or a staging backup) restores performance until a patched release ships.
Confirm the Fix
Once you've deactivated, reconfigured, or rolled back the responsible plugin, rerun the same PageSpeed Insights check from Section 1 and compare LCP, INP, and CLS against the same "good" thresholds — 2.5 seconds, 200 milliseconds, and 0.1 respectively, as defined in Google's Core Web Vitals documentation. Matching the before-and-after numbers to the same metric is what confirms the fix, rather than a general impression that the site "feels faster." Keep the Query Monitor report from before the fix alongside the one after it. If the same plugin updates again later, that comparison becomes the fastest way to tell whether the new version repeats the same query or HTTP-call pattern that caused the problem the first time.
Frequently Asked Questions
Can caching alone hide a real performance problem after an update?
Yes — an update can clear a cache that was masking an already-slow query or script, so the slowdown was present before the update and only became visible once the cache reset, according to Jorijn.com's WordPress performance guide.
Does Query Monitor only check database queries?
No — it also reports PHP errors with their call stack and every outgoing HTTP API request the page makes, so it catches slowdowns caused by external services as well as the database, according to the Query Monitor plugin page.
Will testing in Troubleshooting Mode affect what visitors see?
No — the Health Check & Troubleshooting plugin's Troubleshooting Mode only changes the view for the logged-in admin running the test; the live site stays exactly as visitors see it, according to the Health Check & Troubleshooting plugin page.
