Did that plugin update slow down WordPress? Catch performance regressions after updates

#Sites get slow one update at a time

Hardly any WordPress site is slow on launch day. It gets slow later, a bit at a time: a form plugin release that starts loading its scripts on every page, a page builder update with a new database query in its bootstrap, an analytics plugin that now calls home on every request. Each change adds 50 or 100 ms. Nobody notices any single one, and six months later the site is a second slower and nobody can say why.

By the time someone investigates, the evidence has gone. Dozens of updates have landed since, the changelogs say "performance improvements", and the only way to find the culprit is to measure every plugin from scratch. That works (the guide to finding which plugin is slowing down WordPress walks through it), but it tells you where the time goes today, not which update started it.

The fix is to measure continuously, close to each change, and to keep the numbers.

#Why checking by hand does not catch it

The usual advice is to test the site after updating. In practice:

• Updates happen when you are not looking. Auto-updates run overnight, and a client or colleague clicks Update all on a Friday afternoon.
• One reload proves nothing. A 100 ms regression is well inside the noise of a single page load. Catching it takes repeated, interleaved timings compared against a baseline measured the same way.
• Uptime monitors only check that the site is up. A site that answers in 1.4 seconds instead of 0.9 is up, so an uptime monitor stays green while visitors wait.
• "It got slower" is not actionable. You need to know what changed between the fast measurement and the slow one.

#Set a baseline, then scan on a schedule

Dragon Speed Doctor measures what each plugin costs by timing the site with each one left out of its own signed internal requests. Dragon Speed Doctor Pro keeps doing it:

1. Run one diagnosis by hand from Tools, then Speed Doctor, so there is a baseline to compare against.
2. Open the Monitoring tab and choose Weekly or Daily scans.
3. Pick a quiet hour: a time of day when traffic is low and backups are not running. Scheduled scans run around it.
4. Leave After an update ticked. Ten minutes after any plugin, theme or WordPress update, the doctor runs a follow-up scan, so a regression is measured next to the change that caused it and not a week later.
5. Add the alert recipients: email addresses, a Slack webhook, or a signed webhook for your own tooling.

Site Health shows whether the scheduled scan is actually running. If WP-Cron only fires when someone visits the site, a low-traffic site can miss its schedule, so a real system cron is worth setting up (the WP-Cron guide covers it).

#Alerts you can trust

An alert that cries wolf gets muted, and then the real regression is missed. So the doctor does not alert on a single slow scan:

• A suspected slowdown is re-measured first. When a scan looks slower than the baseline, a second scan runs to confirm it. The alert goes out only if both agree.
• Inconclusive measurements never alert. If the server was too noisy to measure cleanly, the scan says so and nothing is sent.
• The alert names what changed. Between the fast scan and the slow one, which plugins updated (and from which version to which), which were newly added, and whether the theme or WordPress changed. When the slower plugin did not change version, the alert says that too, which points at its settings or content.
• One alert per slowdown. After an alert, the new level becomes the baseline, so you are not told about the same slowdown every week.

#Read the history

The History tab keeps twelve months of scans. The chart shows front-end response time over time with a marker at each update; Biggest movers compares the newest scan with any earlier one you pick and ranks the plugins that changed most; and every confirmed alert is listed with what it found.

When a plugin is flagged, open Where the time goes on the Results tab. It lists the database queries and outgoing HTTP calls that plugin made on a real front-end page. An update that added a slow query or a blocking call to a remote API shows up here by name.

#What to do when an update is the culprit

• Roll back while you investigate. Reinstall the previous version (WP-CLI: wp plugin install <slug> --version=<x.y.z> --force), then scan again to confirm the time comes back.
• Tell the developer, with numbers. "Front-end pages are about 150 ms slower since 2.3.0; the new time is a query on wp_options in your bootstrap" gets a fix. "Your update made my site slow" gets closed.
• Check the settings. A new version sometimes turns on a feature by default: asset loading on every page, a remote font, live stats.
• Pause auto-updates for that one plugin until a fixed release lands, and leave them on for everything else.
• Scan again after the fix to confirm the site is back to its baseline.

#For agencies

Each client site runs its own schedule and sends its own alerts, so point them at a shared inbox or Slack channel. A slowdown alert that names the update is much easier to handle on a support call than a vague "the site feels slow" ticket, and the History tab shows the client that it has been fixed.