Сүрөттөө

Every slow WordPress site raises the same question: which plugin is doing this? Dragon Speed Doctor answers it with measurements, not guesswork.

Install the measurement loader, press Run diagnosis, and the doctor times your site over a few minutes of internal test requests, with each plugin briefly left out of those test requests only, then tells you what each plugin actually costs:

Per-plugin timing, front-end and wp-admin: “Adds about 180–260ms to page loads.” Real measured ranges, never invented precision. When results are too noisy to trust, it says so instead of making a number up.
Asset audit: every script and stylesheet on your pages, attributed to the plugin that ships it, with sizes and render-blocking flags. Sometimes a plugin’s PHP is fast but it sends 900KB of JavaScript to every visitor, and the doctor catches that too.
Database signals: autoloaded-option weight (a common hidden slowdown) with probable owners.
Plain-English verdicts with Low / Medium / High impact badges, sorted worst first, and an Inconclusive badge when the timings cannot support an answer.
Before/after comparison: run a scan before updating plugins and another after, and see what changed.
Speed monitoring (optional, off until you turn it on): a scan weekly or daily at a quiet hour, plus a follow-up scan 10 minutes after a plugin, theme or WordPress update. When a scan finds the site or a plugin slower than the scans before it, a second scan an hour later has to show the same before anything is reported. A confirmed slowdown is emailed to the addresses you choose (the site’s admin email until you change it), naming the plugin that got slower, or saying that pages as a whole got slower, with roughly how many milliseconds were added and the plugin, theme or WordPress update that coincides with it.
12-month history: every diagnosis, run by hand or automatically, is kept for a year. The History tab charts front-end and wp-admin page times week by week with markers where plugins, the theme or WordPress changed, lists the biggest movers between the newest scan and any earlier one, and keeps the confirmed slowdowns.
Site Health: Tools > Site Health says whether speed monitoring is off, keeping up, blocked (and why) or stopping before it finishes, and reports a slowdown confirmed in the last two weeks.
Dependency awareness: plugins that declare they need another plugin (a WooCommerce payment gateway, say) are measured together and labelled honestly; a plugin the site cannot run without is reported as “could not be measured”, never as harmless.
WP-CLI: wp speed-doctor scan.

Visitors are never affected: plugin loading is only altered for the doctor’s own internal, cryptographically signed test requests. Your live traffic always sees the site exactly as configured.

Features

Per-Plugin Timing – What each plugin costs on the front end and in wp-admin, as honest measured ranges
Asset Audit – Every script and stylesheet on your pages, attributed to the plugin that ships it, with render-blocking flags
Database Signals – Autoloaded-option weight and probable owners, a common hidden slowdown
Plain-English Verdicts – Low, Medium, High and Inconclusive badges, sorted worst first, no jargon
Before & After – Scan before updating plugins and again after, and see exactly what changed
Scheduled Scans – Weekly or daily at a quiet hour, and after every update, once you switch them on
Confirmed Slowdown Emails – Sent only after a second scan agrees, naming what changed and how much it costs
12-Month History – Weekly trend charts, biggest movers and every confirmed slowdown on one tab
Site Health Check – Monitoring off, overdue or blocked, and recent confirmed slowdowns, in Tools > Site Health
Dependency Awareness – Plugins that cannot be separated are measured together and labelled honestly
Honest Confidence – Rates a plugin Low only when the top of every measured range stays at or below 100ms, never calls a difference smaller than the server’s own noise a cost, and says “inconclusive” when the server is too noisy, or when a small cost on one page sits next to a page that was not measured, instead of inventing a number
WP-CLI – wp speed-doctor scan for scripted or scheduled diagnosis
No External Services – Everything runs on your own server; nothing is sent to Dragon Core or anyone else, and slowdown emails go only to the addresses you enter

Everything above is free, fully functional and unlimited.

How it measures

The method is built for noisy shared hosting: repeated interleaved timings, medians with confidence bands, warmup passes discarded, early stopping when a result is already clear, retries for passing server errors, and honest “inconclusive” verdicts when server noise wins. Script and stylesheet weight counts towards a plugin’s badge only for what it loads on front-end pages; wp-admin-only assets are listed on the Assets tab but never described as shipped to visitors. A pre-scan check verifies your site can be measured (loopback requests allowed, no page cache serving the test requests, no background jobs adding noise) before anything runs.

The measurement loader

Timing a plugin’s absence requires briefly loading the site without it, for signed internal requests only. A small helper file in mu-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:

A scan runs weekly or daily, starting within 20 minutes after the quiet hour you pick, whenever WP-Cron next runs. It runs in small steps through WP-Cron, so it needs no open browser tab.
With “After an update” ticked, a follow-up scan runs 10 minutes after a plugin, theme or WordPress update. A run of updates (automatic updates often come one after another) shares one scan, booked no later than an hour after the first.
Automatic scans time the front end only: WP-Cron runs with no one logged in, so wp-admin cannot be measured there. Run a diagnosis from the Doctor tab to time wp-admin.
Each automatic scan is compared with up to four earlier automatic scans. A slowdown is only reported when a second scan, about an hour later, flags the same page and the same plugin against the same earlier scans; one slow scan on its own never sends anything. Manual and WP-CLI diagnoses are kept in the history but never compared or alerted on.
The email says which plugin got slower (or that pages as a whole got slower), by about how much, and since when, and names the plugin, theme or WordPress update, or the new plugin, that coincides with it. It goes to the addresses saved in Settings (the site’s admin email until you save your own list, at most ten), through your site’s own email set-up. Use “Send a test email” to check that it arrives.
The measurement loader is never installed by an automatic scan. Without it, scheduled scans are skipped and the History tab and Site Health say why.

External services

None. The doctor measures your site by requesting your own pages from your own server. Nothing is sent to Dragon Core or any third party. No telemetry, no accounts, no cloud. If you turn on speed monitoring, slowdown emails are sent with WordPress’s own wp_mail() to the addresses you save; what happens to an email after that depends on your site’s email set-up.

Credits

The WordPress.org listing icon is drawn with glyphs from Lucide (https://lucide.dev), ISC License. Copyright (c) for portions of Lucide are held by Cole Bemis 2013-2022 as part of Feather (https://feathericons.com, MIT License). All other copyright (c) for Lucide are held by Lucide Contributors 2022. The plugin itself does not include these icons.

Скриншоттор

The Doctor tab: install the measurement loader, then run a diagnosis. The latest verdicts are summarised at the top.

Results: plain-English verdicts with impact badges, worst first. Low-impact plugins are folded away. — The Doctor tab: install the measurement loader, then run a diagnosis. The latest verdicts are summarised at the top.

Орнотуу

Upload the dragon-speed-doctor folder to /wp-content/plugins/, or install via the Plugins screen.
Activate the plugin.
Go to Tools Speed Doctor, install the measurement loader, and run a diagnosis.

FAQ.KG

Why is my WordPress site slow?: 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.
Is it safe to run on a live site?: 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.
How is this different from Query Monitor?: 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.
Is this a profiler?: 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.
Why is a plugin measured together with others?: 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.
Why does a plugin say “could not be measured”?: 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.
Does it work on multisite?: 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.
How do scheduled scans and slowdown emails work?: 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.
Does speed monitoring slow my site down?: 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.
Can I close the tab during a diagnosis?: 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.
Does it work behind a reverse proxy or in a container?: 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.

Сын-пикирлер

There are no reviews for this plugin.

Contributors & Developers

“Dragon Speed Doctor – Find What Slows Your Site Down” is open source software. The following people have contributed to this plugin.

Dragon Core

Translate “Dragon Speed Doctor – Find What Slows Your Site Down” into your language.

Interested in development?

Browse the code, check out the SVN repository, or subscribe to the development log by RSS.

Өзгөртүүлөр

1.2.0

New: optional speed monitoring, off until you turn it on in Settings. Automatic scans run weekly or daily at a quiet hour you pick, and 10 minutes after a plugin, theme or WordPress update (a run of updates shares one scan). They run through WP-Cron in small steps, time the front end, and never install the measurement loader by themselves. Installing a new plugin or theme does not start one. Automatic scans are charted on the History tab; the Results, Assets, Database and Doctor tabs keep showing your newest diagnosis from the Doctor tab or WP-CLI.
New: slowdown emails. When an automatic scan finds a page or a plugin slower than the scans before it, a second scan an hour later must agree before anything is sent. The email names what got slower, by about how much and since when, and the update or new plugin that coincides with it. Recipients default to the site’s admin email; save up to ten addresses and send a test email from Settings.
New: History tab with a year of diagnoses: weekly charts of front-end and wp-admin page times with markers where plugins, the theme or WordPress changed, the biggest movers between the newest scan and any earlier one, plugins removed since, and every confirmed slowdown. Diagnoses older than the newest 20 keep a compact summary; diagnoses older than a year are deleted. The two newest diagnoses from the Doctor tab or WP-CLI always keep their full results.
New: Site Health test for speed monitoring: off (which passes), on schedule, overdue, blocked with the reason, stopping before it finishes, or a slowdown confirmed in the last two weeks.
The Dragon Speed Doctor Pro add-on is no longer offered, and the links to it are gone. If it is still active, the built-in monitoring stays off and the Speed Doctor screen asks you to deactivate it.

1.1.8

Every Speed Doctor action checks its security token and your permission itself, and request values are read through WordPress’s own sanitizers.
The measurement loader validates its request headers the same way. Scans measure exactly as before.
Fixed: uninstalling one copy of the plugin while another copy is active no longer stops with an error.

1.1.7

Multisite: network-activated plugins are measured only by a network administrator or by a scheduled or WP-CLI scan. A site administrator’s diagnosis covers the site’s own plugins, so it can never load the site without a plugin the network requires, and never lists what the network runs.
Once a page’s own time is known, each further request to it may take up to three times that (never less than 10 or more than 30 seconds), so a slow page does not hold a diagnosis for half a minute per request.

1.1.6

Verdicts are more honest on noisy hosts: a difference smaller than the server’s own noise is never reported as a cost, a result needs at least four timings on each side, and a plugin that looks costly but is not yet certain gets a few extra timings before the verdict. Large sites take four samples per plugin instead of three.
A page that fails with every plugin loaded no longer blames every plugin, and a page cache, a rate limit or a single hiccup no longer condemns a plugin or drops a page: only three failures in a row count.
The measurement loader is refreshed automatically after a plugin update, and a loader you removed on purpose stays removed. Measurement requests tell page caches not to store them, and cannot save rewrite rules or trigger a recovery-mode email.
Signed measurement requests are bound to the exact address and query they were signed for, accept GET only, expire within five minutes, and are signed with the site’s security keys as well as the stored secret.
A loopback base naming an IPv4-mapped IPv6 address of a public host is refused, and only http and https bases are accepted.
Sites whose stored address is http while pages are served over https, or whose WordPress address differs from the site address, are measured from WP-CLI and scheduled scans again.
Plugins that depend on several others are grouped with all of them. Assets inside noscript or template blocks, module preloads, data blocks and nomodule scripts are no longer counted as render-blocking; symlinked plugin folders are sized; a base href is honoured.
The Assets and Database tabs say when a page or the options table could not be read instead of showing a healthy zero, and the change column compares wp-admin as well.
A diagnosis that cannot be saved or read is reported as an error, two diagnoses cannot start at once, and a request the host cuts off replays at most one measurement.
Uninstall deletes data only when the opt-in really says yes.
Developers: 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.

1.1.5

A page failure is blamed on the plugin that was left out, so one plugin no longer spoils the results for others.
A missing loader stops the scan with a clear reason instead of reporting All clear.
Network-activated plugins are measured on multisite.
The Database tab attributes more options to the plugins that own them.
Uninstall runs per site on multisite.

1.1.4

Results the timings can’t settle are shown as Inconclusive instead of low impact, and a page that wasn’t measured is named.
Plugins that couldn’t be measured are retried and reported, not called harmless.
Scans can be resumed after a reload and cancelled.
Only assets loaded on your pages count toward the badge.
Some earlier verdicts may change when viewed after the update.

1.1.3

Every screen, email and alert is now translatable, so community translations from translate.wordpress.org cover the whole plugin. Counts use proper plural forms, and numbers and dates follow your site’s language.
Scan dates and owner labels follow your site’s language.

1.1.2

Added: an “Upgrade to Pro” link on the Plugins screen, a one-line pointer at the foot of the Speed Doctor screen, and a single dismissible note after three diagnoses (or one diagnosis at least three days old). All three disappear when Dragon Speed Doctor Pro is active; nothing in the free plugin is locked or changed.

1.1.1

Fixed: a diagnosis that did not measure wp-admin (for example when wp-admin kept failing to load) logged PHP warnings while working out the results. An unmeasured page is now simply treated as inconclusive.
Fixed: the measurement loader could fatal if another plugin asked it for measurement details on an ordinary request. It now answers “not a measurement request”.
Changed: the results summary no longer shows a “0 low impact” badge.

1.1.0

Fixed: a homepage that redirects to another page on the same site (for example / to /en/, or to a landing page) made the preflight check fail with a message about firewalls. The doctor now follows up to three redirects within the site and measures the page they lead to. A redirect to a different site, or to a page that errors, is reported with its own message.
Added: each diagnosis records the plugin, theme and WordPress versions it measured, and the site’s overall response time per page, so later diagnoses can be compared against them.
Developers: new 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.

1.0.7

Changed: the Doctor tab is now one guided card with two numbered steps. Step 1 installs the measurement loader; step 2, Run diagnosis, unlocks once the loader is in place. Installing or removing the loader no longer reloads the page.
Added: a summary of the latest diagnosis on the Doctor tab (impact counts and the plugins that need attention), and the same counts plus a Run again button at the top of Results.
Changed: on Results, plugins with low impact are grouped in a collapsible section so the ones worth acting on come first.
Fixed: a plugin rated High because of the scripts and styles it ships, but with only a small timing cost, showed no reason for the rating. The verdict now also states the asset weight whenever it is heavy enough to affect the rating.
Added: the Database tab marks the autoload total as Healthy or Above 800KB.
Added: live progress now shows the elapsed time, and the browser warns before you leave the page while a diagnosis is running.
Changed: preflight checks read OK, Warning or Blocked (translatable), and the Results, Assets and Database tabs link straight to the Doctor tab when there is no diagnosis yet.
Fixed: a loader install or removal that failed was not reported; the reason is now shown.
Fixed: if a request failed during a diagnosis, the Run diagnosis button stayed disabled until the page was reloaded, and a failed start left the screen on “Checking…”. A diagnosis interrupted by a dropped request now picks up where it left off when you click Run diagnosis again, instead of being refused as already running.
Fixed: the Dragon Core mark was missing from the page title.

1.0.6

Added: an occasional, dismissible request for a WordPress.org review once the doctor has produced results, shown only on its own screen.
Changed: listing title and tags for the WordPress.org directory.

1.0.5

Fixed: two active plugins whose Requires Plugins headers point at each other (or a longer loop of them) made the dependency grouping recurse until PHP ran out of memory before a diagnosis could start. Chains are now walked without recursion, and every plugin in such a loop is measured as one group.
Changed: readme wording tidied.

1.0.4

Fixed: asset sizes were reported as 0 for scripts and styles with a scheme-relative (//), http:// or document-relative address, for percent-encoded file names, on subdirectory installs, and when wp-content lives outside the WordPress folder. Every address is now resolved against the page it was found on, then located with the site path stripped and wp-content resolved to its real directory. Only files inside the WordPress and wp-content folders are ever read.
Fixed: the asset table could attribute a plugin’s scripts to “core/other” when the address differed from the site’s wp-content URL in scheme, letter case or a www. prefix, or used ../ segments. Attribution now matches on the resolved host and path.
Fixed: DRAGONSPEEDDOCTOR_LOOPBACK_BASE with a path (for example http://app-container/wp) doubled that path on subdirectory installs and timed 404 pages. The base is now used as an origin only; each request keeps its own path.
Security: the loopback base is validated more strictly. IP literals must be a full dotted IPv4 or bracketed IPv6 address in a loopback, private or link-local range (integer, shorthand and public IPv6 forms are refused), and a hostname is accepted only when every address it resolves to is in such a range. Unresolvable names are refused.
Fixed: activation recorded the install as complete even when the scans table or the signing secret had not been stored. Both are now verified first; an incomplete install is retried on the next admin load and shown as an admin notice until it succeeds. Existing sites are checked once on upgrade.
Fixed: a diagnosis that could not be started, saved or finished in the database is now reported as an error instead of appearing to start or finish without results.

1.0.3

Wording tidied across the readme and the plugin screens for clarity. No functional changes.

1.0.2

Readme: changelog and upgrade notice now cover 1.0.1, which shipped without entries.
Code comments reworded to describe the filter hooks they document.

1.0.1

Safety: during a measurement request the active-plugins list can no longer be written back to the database, so a probe can never deactivate your other plugins.
Reliability: an abandoned scan is reclaimed after 15 minutes so it cannot block future scans; the measurement loader is refreshed before each run.

1.0.0

Initial release: per-plugin timing attribution (front-end and wp-admin), asset audit, database signals, plain-English verdicts, before/after comparison, WP-CLI.

Сүрөттөө

Features

How it measures

The measurement loader

Speed monitoring

External services

Credits

Скриншоттор

Орнотуу

FAQ.KG

Why is my WordPress site slow?

Is it safe to run on a live site?

How is this different from Query Monitor?

Is this a profiler?

Why is a plugin measured together with others?

Why does a plugin say “could not be measured”?

Does it work on multisite?

How do scheduled scans and slowdown emails work?

Does speed monitoring slow my site down?

Can I close the tab during a diagnosis?

Does it work behind a reverse proxy or in a container?