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. Since version 1.2.0 it can keep doing that on its own, free:

1. Run one diagnosis by hand from Tools, then Speed Doctor. It installs the measurement loader (automatic scans never install it themselves) and gives later scans something to compare against.
2. Open Settings and find Speed monitoring. Set Automatic scans to Weekly or Daily. Monitoring is off until you do.
3. Pick a Quiet hour: a time of day when traffic is low and backups are not running. Scheduled scans start within 20 minutes after it.
4. Leave After an update ticked. Ten minutes after a 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. Several updates in a row share one scan, and installing something new does not start one.
5. Under Slowdown emails to, enter up to ten addresses, or leave it to the site admin email. Send a test email checks the site can deliver them.

Site Health shows whether speed monitoring is on schedule, overdue or blocked, and why. 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 email on a single slow scan:

• A suspected slowdown is measured again first. When an automatic scan finds a page or a plugin slower than the scans before it, a second scan runs an hour later. The email 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 email names what changed: what got slower, by about how much and since when, and the update or newly added plugin that coincides with it.
• One email per slowdown. A confirmed slowdown is not reported again every week.

#Read the history

The History tab keeps a year of automatic scans, separate from your own diagnoses, so the Results, Assets and Doctor tabs keep showing the last one you ran. Weekly charts of page time are marked where plugins, the theme or WordPress changed; Biggest movers compares the newest scan with any earlier one you pick and ranks the plugins that changed most; plugins removed since are listed; and every confirmed slowdown is listed under Confirmed slowdowns.

When a plugin is flagged and you want to see why, a free profiler such as Query Monitor shows that plugin's database queries and outgoing HTTP calls on a real page. An update that added a slow query or a blocking call to a remote API shows up there 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 emails, so point them at a shared inbox. A slowdown email 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.