---
title: WP Deep Performance Analyzer
description: Deep WordPress performance profiling — hook analysis, autoloaded options audit, asset graph, HTTP/AJAX monitoring, and object-cache diagnostics. Runs as a regular plugin or mu-plugin.
tagline: 12 profiling tabs for WordPress — from PHP lifecycle checkpoints to autoloaded bloat, render-blocking assets, and outbound HTTP calls.
category: Performance
status: wip
version: 3.0.4
date: 2026-05-18
requires:
  php: '8.0'
  wp: '6.0'
license: GPL-2.0-or-later
screenshot: /plugins/wdpa/screenshot.png
screenshotAlt: WP Deep Performance Analyzer admin dashboard with profiling tabs
keywords:
  - WordPress performance profiler
  - autoloaded options audit
  - wp_filter hook analyzer
  - WordPress render-blocking assets
  - wp-admin object cache diagnostics
tags:
  - performance
  - profiling
  - wordpress
  - diagnostics
outcomes:
  - 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
faq:
  - q: Is this safe to run on production?
    a: "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)."
  - q: What's the difference between mu-plugin and regular install modes?
    a: "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."
  - q: When is the full writeup coming?
    a: "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."
---

## 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](/#contact) 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`)