Wp Performance

A solid backend-only approach to WordPress performance that assumes you can't click around wp-admin. It walks through WP-CLI profiling (doctor, profile stage/hook), Query Monitor's headless REST headers, and the usual suspects: autoloaded options, object cache misses, N+1 queries, remote HTTP calls, and cron pileups. The workflow is measure first, pick one bottleneck, fix it, then verify with the same tooling. It knows about WordPress 6.9's on-demand CSS and zero render-blocking improvements for block themes. Useful if you're debugging TTFB or slow admin screens via SSH and need a checklist that respects production guardrails.

skills.sh installs: 411
GitHub stars: 211
last updated: Jun 3, 2026

View on GitHub

Install

$ npx -y skills add automattic/agent-skills --skill wp-performance --agent claude-code

Installs into .claude/skills of the current project.

Files

WP Performance (backend-only)

When to use

Use this skill when:

a WordPress site/page/endpoint is slow (frontend TTFB, admin, REST, WP-Cron)
you need a profiling plan and tooling recommendations (WP-CLI profile/doctor, Query Monitor, Xdebug/XHProf, APMs)
you’re optimizing DB queries, autoloaded options, object caching, cron tasks, or remote HTTP calls

This skill assumes the agent cannot use a browser UI. Prefer WP-CLI, logs, and HTTP requests.

Inputs required

Environment and safety: dev/staging/prod, any restrictions (no writes, no plugin installs).
How to target the install:
- WP root --path=<path>
- (multisite/site targeting) --url=<url>
The performance symptom and scope:
- which URL/REST route/admin screen
- when it happens (always vs sporadic; logged-in vs logged-out)

Procedure

0) Guardrails: measure first, avoid risky ops

Confirm whether you may run write operations (plugin installs, config changes, cache flush).
Pick a reproducible target (URL or REST route) and capture a baseline:
- TTFB/time with curl if possible
- WP-CLI profiling if available

Read: