Wp Performance

Use when investigating or improving WordPress performance (backend-only agent): profiling and measurement (WP-CLI profile/doctor, Server-Timing,

What Is This?

Overview

Wp Performance is a backend-focused skill for investigating and improving WordPress site performance. It covers the full diagnostic and optimization workflow, from profiling and measurement through to database query tuning, object caching, and HTTP API call analysis. The skill targets WordPress 6.9 and later running on PHP 7.2.24 or higher, and it prefers WP-CLI when available for command-line profiling tasks.

The skill draws on a set of established tools and techniques: WP-CLI profile and doctor commands, Server-Timing headers, Query Monitor via REST headers, autoloaded options auditing, object cache configuration, WP-Cron inspection, and safe verification steps. Each of these addresses a distinct layer of the WordPress stack, allowing engineers to isolate bottlenecks precisely rather than applying broad, speculative fixes.

Because this is a backend-only skill, it does not cover front-end asset optimization, image compression pipelines, or CDN configuration. Its scope is the PHP execution layer, the database, and the WordPress application internals.

Who Should Use This

  • WordPress backend developers who need to diagnose slow page generation times or high server load
  • Site reliability engineers responsible for maintaining performance SLAs on WordPress installations
  • DevOps engineers configuring server environments and caching layers for WordPress
  • Plugin and theme developers who want to verify that their code does not introduce unnecessary database queries or slow hooks
  • Agencies managing multiple WordPress sites who need a repeatable, systematic performance audit process
  • Technical leads reviewing pull requests for performance regressions before deployment

Why Use It?

Problems It Solves

  • Unidentified slow database queries that inflate time-to-first-byte without obvious symptoms in application logs
  • Excessive autoloaded options that bloat every page load by pulling large data sets from the database on every request
  • Misconfigured or absent object caching that forces repeated database round-trips for data that could be served from memory
  • Runaway WP-Cron events that accumulate and execute during user-facing requests, adding unpredictable latency
  • Unthrottled external HTTP API calls made synchronously during page generation, blocking PHP execution until a remote server responds

Core Highlights

  • Uses WP-CLI profile and doctor commands for non-invasive, command-line profiling without modifying production code
  • Reads Server-Timing response headers to measure hook and query execution time at the HTTP layer
  • Accesses Query Monitor data via REST API headers, enabling analysis without a logged-in browser session
  • Audits autoloaded options size and identifies candidates for removal or lazy loading
  • Evaluates object cache configuration and verifies that persistent caching backends are functioning correctly
  • Inspects the WP-Cron schedule for overdue or duplicated events that may be degrading request performance
  • Provides safe verification steps to confirm that optimizations have taken effect without introducing regressions
  • Targets WordPress 6.9 and PHP 7.2.24 or higher, covering all currently supported production environments

How to Use It?

Basic Usage

Start a performance investigation with the WP-CLI doctor command to get a rapid health summary:

wp doctor check --all

Then run a profile of a specific URL to see hook and query timing broken down by stage:

wp profile url https://example.com --fields=hook,time,query_count --order=time

To inspect autoloaded options and identify oversized entries:

wp db query "SELECT option_name, LENGTH(option_value) AS size FROM wp_options WHERE autoload='yes' ORDER BY size DESC LIMIT 20;"

Specific Scenarios

Diagnosing slow admin requests. Run wp profile stage --all against the admin URL to isolate which WordPress load stage, bootstrap, main query, or template, is consuming the most time. Combine this with Query Monitor REST headers by sending an authenticated request and reading the X-QueryMonitor-* response headers.

Auditing object cache effectiveness. Check whether a persistent cache is active with wp cache type, then use wp cache flush followed by a warm-up request to measure cold-cache versus warm-cache response times using Server-Timing header values.

Real-World Examples

A site experiencing 4-second admin load times was found to have 8 MB of autoloaded options from an abandoned plugin. Removing those entries reduced load time to under 800 ms.

A WooCommerce store had 200 overdue cron events queued. Running wp cron event list revealed a stuck scheduled action. Clearing the queue and fixing the underlying hook reduced checkout page latency by 600 ms.

Important Notes

Requirements

  • WordPress 6.9 or later with PHP 7.2.24 or higher on the server
  • WP-CLI installed and accessible on the server for profile and doctor commands
  • Database user permissions sufficient to run SELECT queries against the options table
  • Query Monitor plugin installed if REST header-based analysis is required