← Oleksii Turovskyi
Work in progressPerformancev3.0.4GPL-2.0-or-later

WP Deep Performance Analyzer

12 profiling tabs for WordPress — from PHP lifecycle checkpoints to autoloaded bloat, render-blocking assets, and outbound HTTP calls.

  • PHP lifecycle checkpoints with time and memory deltas
  • Top-20 autoloaded options + total autoload weight
  • $wp_filter dump grouped by source (core / plugin / theme / mu-plugin)
  • Outbound HTTP and AJAX request log
Not yet available — writeup in progress.Install instructions ↓
WordPress
6.0+
PHP
8.0+
Dependencies
None

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.

Full case-study writeup in progress. The plugin itself is shipped and stable at v3.0.4. Check back soon, or reach out via the contact form for early access.

What ships in v3.0.4#

  • 12 admin tabs (Profiler, $wp_filter, Database, Assets, WP-Cron, System Info, Transients, Post Meta, Object Cache, Render Blocking, HTTP Requests, AJAX Monitor)
  • mu-plugin and regular-plugin modes with double-load protection
  • PHP 8.1 typed properties, namespaced, final classes, singleton via get_instance()
  • Inline admin CSS scoped under .wdpa- prefix to avoid conflicts
  • Self-hosted updates via Plugin Update Checker v5

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.
When is the full writeup coming?
Soon — the plugin is shipped and stable at v3.0.4. The case-study writeup is being assembled now. Subscribe to the RSS feed to be notified when it lands.

View as Markdown · for AI agents and offline reading

Other plugins

Other tools

Not a WordPress site? I also ship Chrome extensions — small browser utilities for SEO, AI workflows, and research.