| 开发者 | dragoncoreltd |
|---|---|
| 更新时间 | 2026年10月10日 12:51 |
| PHP版本: | 8.0 及以上 |
| WordPress版本: | 7.1 |
| 版权: | GPLv2 or later |
| 版权网址: | 版权信息 |
wp speed-doctor scan.wp speed-doctor scan for scripted or scheduled diagnosismu-plugins does this. It is installed only when you click Install loader on the Doctor screen (or run wp speed-doctor scan), shown there with its status, does nothing for any normal request, and is removed automatically when you deactivate the plugin. Once installed, it is brought up to date by itself after each plugin update, and a loader you removed stays removed.
Speed monitoring
Monitoring is off until you turn it on under Tools > Speed Doctor > Settings, because every automatic scan sends a few minutes of test requests to your own server. Once on:
dragon-speed-doctor folder to /wp-content/plugins/, or install via the Plugins screen.Usually one of four things: a plugin doing heavy work on every request, a plugin shipping large scripts to every page, bloated autoloaded options in the database, or slow hosting. The doctor measures the first three directly and tells you which plugin is responsible, so you fix the actual cause instead of guessing.
Yes, with one caveat. Visitors are never served a modified site. Plugin loading changes only for the doctor's own signed internal requests. The caveat: a scan sends a few hundred requests to your server over several minutes, which adds load. On a busy site, run it at a quiet time, or enable host-safe mode in Settings to slow it down further.
Query Monitor is a superb developer tool that inspects the current request in deep technical detail. The doctor answers a different question, namely which plugin to blame, by measuring whole pages with and without each plugin, and it answers in sentences rather than stack traces. Many people will want both.
Not in the function-call sense. It does not hook into PHP or list which functions ran. It measures whole page loads with and without each plugin, so the result is a per-plugin cost in milliseconds rather than a call tree. The asset and database audits are separate, single-pass checks.
Some plugins fatal when a plugin they depend on is missing, such as a WooCommerce extension without WooCommerce. When a plugin declares that dependency, the doctor measures the group as a whole, and the verdict names every plugin in it.
If the site keeps returning a server error whenever one plugin is left out of the test requests, something else on the site probably depends on it without declaring so. The same goes for a page that loads normally with every plugin active but answers not-found, another error, or nothing at all while that one plugin is left out. The doctor retries a few times in case the error was a passing hiccup, then reports the plugin as could not be measured, with the error code, rather than guessing at its cost. The page is still measured for every other plugin.
Yes. Each site runs its own diagnosis. Plugins activated for the whole network are measured along with the site's own when the diagnosis is run by a network administrator, by a schedule or from WP-CLI; a site administrator's diagnosis covers the site's own plugins. The measurement loader in mu-plugins is shared by the network, so deactivating the doctor on one site removes it until it is installed again from the Doctor screen; the preflight blocks a scan with that reason rather than reporting every plugin as harmless. Uninstalling removes the data of every site that opted in.
Turn on Automatic scans in Settings and pick weekly or daily and a quiet hour. Each automatic scan runs through WP-Cron in short steps, so on a site with little traffic it may take longer than a manual one. When a scan finds a page or a plugin conclusively slower than the scans before it, a second scan an hour later must show the same thing before anything is emailed. The email names what got slower, by how much, and what changed (an update, a new plugin, a theme switch or a WordPress update) around that time. Every confirmed slowdown is also listed on the History tab, and Site Health reports it for two weeks.
Each automatic scan sends a few hundred requests to your own server over several minutes, at the quiet hour you choose, the same as a manual diagnosis of the front end. Visitors still get the site exactly as configured. Turn on host-safe mode in Settings to pace the requests further apart.
A diagnosis started from the Doctor tab runs while that tab is open. If you reload or come back to the Doctor tab within 15 minutes, it carries on where it stopped; the Doctor tab also offers Cancel diagnosis while one is running.
Usually yes, automatically. If your server cannot reach its own public URL, define DRAGONSPEEDDOCTOR_LOOPBACK_BASE in wp-config.php with an address the server can reach (for example http://app-container or a private IP). Only the scheme, host and port are used; any path on the address is ignored because each request keeps its own path. The doctor keeps the correct Host header so WordPress routes normally. For safety the override is honoured only when the host is localhost, a loopback, private or link-local IP address written in full (dotted IPv4 or bracketed IPv6), or a hostname whose every DNS address is in one of those ranges. Anything else, including a name that does not resolve, is ignored, so measurement traffic never leaves your infrastructure.
dragonspeeddoctor_scan_stale_after filters how long a running diagnosis may go quiet before it is reclaimed; results carry extended, extra_requests, throttled and asset audited/failed counts; the loader's marker now ends with a tag tied to the request.dragonspeeddoctor_tool_plugins filter and dragonspeeddoctor_verdict_details action (under each verdict on Results); dragonspeeddoctor_page_set receives the scan source as a second argument; dragonspeeddoctor_scan_complete receives the scan's environment as a third argument; new dragonspeeddoctor_signed_request action on verified measurement requests.