The problem
A WordPress site has slowed down. The owner sees it. The host blames the plugins; the plugins blame the host; the developer asks for SSH access that nobody can give. The actually-useful question — which hook, query, or asset is responsible for the slowdown right now — gets buried under generic advice.
WDPA answers that question without leaving wp-admin. Twelve specialized tabs, each focused on one diagnostic axis: hook fan-out, autoloaded options, render-blocking assets, outbound HTTP calls, AJAX hot-paths, object-cache hit ratio.
What it does today
Twelve tabs, and it is easier to read them as four questions than as a list.
Where did the time go? The Profiler records time and memory at each stage of the WordPress lifecycle, so a slow request shows up as a delta between two checkpoints rather than as one total you cannot act on. Installed as an mu-plugin it starts at muplugins_loaded, the earliest hook there is, which means every other plugin's boot cost is inside the measurement.
Which code is responsible? The $wp_filter tab dumps every registered hook grouped by where it came from — core, plugin, theme, or mu-plugin — so a hook with forty callbacks stops being anonymous. Two further analyzers sit behind it: one resolves where each callback was defined, the other correlates hooks against the checkpoints the Profiler recorded.
What is the database carrying? Separate tabs for autoloaded options (top twenty by size, plus the total autoload weight that loads on every single request), transients, and post meta. These three are where WordPress installs quietly accumulate weight that no page-speed tool will ever attribute correctly.
What does the front end pull in? Every enqueued CSS and JS file with its size and dependency chain, a render-blocking tab that names the offenders, an outbound HTTP log built on pre_http_request and http_response, an AJAX monitor for admin-ajax hot paths, and object-cache diagnostics covering Redis, Memcached, APCu, LiteSpeed and Relay. A System Info tab collects the environment with a status verdict per item.
Everything runs inside wp-admin. No SSH, no APM agent, no external service — which is the entire point when the person who can see the slowdown is not the person with server access.
Build details
- mu-plugin and regular-plugin modes, with double-load protection when it ends up installed in both
- 13 namespaced classes, typed properties, final classes, singleton via
get_instance() - Inline admin CSS scoped under a
.wdpa-prefix so it cannot leak into other admin screens - Snapshot transients carry frontend, HTTP and AJAX data through to the admin view
- Self-hosted updates via Plugin Update Checker v5
- Requires the
manage_optionscapability
Where it stands
Shipped and stable at v3.0.4. The long-form case study — walking a real slowdown from the first checkpoint to the responsible hook — is not written yet. If you want the plugin before that exists, get in touch.
Stack
- WordPress 6.0+, PHP 8.0+
- 13 namespaced classes under
WP_Deep_Performance_Analyzer\ - Snapshot transients for frontend / HTTP / AJAX → admin
- Native WP filter hooks for outbound HTTP capture (
pre_http_request,http_response)
FAQ
Is this safe to run on production?
Yes, but it's designed for diagnostics — the admin pages do real work (DB queries, hook walking) and are intended for staging or during scheduled production audits. Profiler runtime overhead is minimal (microtime + memory_get_usage per checkpoint).
What's the difference between mu-plugin and regular install modes?
As a mu-plugin (wp-content/mu-plugins/), profiling starts at muplugins_loaded — the earliest hook available — so the timing of every other plugin is measured. As a regular plugin, profiling starts at plugins_loaded, missing early boot.
Which object-cache backends does it recognise?
Redis, Memcached, APCu, LiteSpeed and Relay. The Object Cache tab reports which backend is active, whether a persistent drop-in is actually in place, and the hit ratio — which is the number that tells you whether the cache is doing anything or just sitting there.
What access does a user need to open the analyzer?
The manage_options capability, so administrators on a single site and super-admins on multisite. There is no lower-privilege read-only mode: the tabs run real queries and walk the hook graph, which is not something to hand to a subscriber.