Wp Performance
Profile and fix slow WordPress sites using WP-CLI, Query Monitor, and database or cache tuning without relying on a browser UI.
Overview
WP Performance is an agent skill most often used in Operate (also Ship) that profiles and optimizes WordPress backend performance via WP-CLI, logs, and HTTP—without a browser UI.
Install
npx skills add https://github.com/wordpress/agent-skills --skill wp-performanceWhat is this skill?
- Measure-first guardrails: confirm write permissions and reproducible URL or REST targets before changes
- WP-CLI doctor/profile, Server-Timing, and Query Monitor via REST headers for backend-only profiling
- Targets DB queries, autoloaded options, object cache, WP-Cron, and remote HTTP API latency
- Explicit inputs for dev/staging/prod safety, multisite `--url`, and logged-in vs logged-out symptoms
- Compatibility called out for WordPress 6.9+ and PHP 7.2.24+ with CLI-preferred workflows
Adoption & trust: 2.1k installs on skills.sh; 1.6k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your WordPress site, admin screen, or REST route is slow and you need a safe measurement plan and concrete DB, cache, and cron fixes from the terminal.
Who is it for?
Solo builders or indie agencies maintaining live WordPress installs who can use WP-CLI and want agent-guided performance triage on staging first.
Skip if: Teams that only need frontend Core Web Vitals in Chrome DevTools with no server or WP-CLI access, or sites where the agent is forbidden from any diagnostic HTTP or CLI calls.
When should I use this skill?
A WordPress site, page, endpoint, admin screen, or WP-Cron path is slow and you need profiling, measurement tooling, and safe DB, cache, cron, or HTTP optimization from a backend-only agent.
What do I get? / Deliverables
You get a reproducible profiling path, prioritized optimizations, and verification steps that improve TTFB and backend latency without unauthorized writes.
- Profiling and measurement plan
- Prioritized optimization recommendations
- Verification checklist after changes
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Production slowdowns and TTFB issues are addressed after launch when the site is live and measurable. Performance work maps to infrastructure and runtime tuning (caching, cron, HTTP, autoloaded options) rather than greenfield feature build.
Where it fits
Run a pre-launch TTFB and query audit on staging before traffic spikes.
Diagnose sporadic admin slowness tied to autoloaded options or object cache misses.
Correlate Server-Timing and REST headers with Query Monitor signals after a deploy.
Validate that a new REST endpoint does not add N+1 queries before merge.
How it compares
Use instead of ad-hoc plugin shopping or blanket cache plugins when you need measured, backend-first WordPress tuning.
Common Questions / FAQ
Who is wp-performance for?
WordPress maintainers and agent users who optimize live or staging installs from the shell when pages, REST routes, admin, or cron feel slow.
When should I use wp-performance?
During Ship perf hardening before a big launch, in Operate when TTFB regresses, when REST or admin latency spikes, or when you need WP-CLI doctor/profile and Query Monitor guidance without opening a browser.
Is wp-performance safe to install?
Review the Security Audits panel on this Prism page and treat production writes, plugin installs, and cache flushes as explicit approvals—the skill is designed to measure first and respect environment guardrails.
SKILL.md
READMESKILL.md - Wp Performance
# 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 1. Confirm whether you may run write operations (plugin installs, config changes, cache flush). 2. Pick a reproducible target (URL or REST route) and capture a baseline: - TTFB/time with `curl` if possible - WP-CLI profiling if available Read: - `references/measurement.md` ### 1) Generate a backend-only performance report (deterministic) Run: - `node skills/wp-performance/scripts/perf_inspect.mjs --path=<path> [--url=<url>]` This detects: - WP-CLI availability and core version - whether `wp doctor` / `wp profile` are available - autoloaded options size (if possible) - object-cache drop-in presence ### 2) Fast wins: run diagnostics before deep profiling If you have WP-CLI access, prefer: - `wp doctor check` It catches common production foot-guns (autoload bloat, SAVEQUERIES/WP_DEBUG, plugin counts, updates). Read: - `references/wp-cli-doctor.md` ### 3) Deep profiling (no browser required) Preferred order: 1. `wp profile stage` to see where time goes (bootstrap/main_query/template). 2. `wp profile hook` (optionally with `--url=`) to find slow hooks/callbacks. 3. `wp profile eval` for targeted code paths. Read: - `references/wp-cli-profile.md` ### 4) Query Monitor (backend-only usage) Query Monitor is normally UI-driven, but it can be used headlessly via REST API response headers and `_envelope` responses: - Authenticate (nonce or Application Password). - Request REST responses and inspect headers (`x-qm-*`) and/or the `qm` property when using `?_envelope`. Read: - `references/query-monitor-headless.md` ### 5) Fix by category (choose the dominant bottleneck) Use the profile output to pick *one* primary bottleneck category: - **DB queries** → reduce query count, fix N+1 patterns, improve indexes, avoid expensive meta queries. - `references/database.md` - **Autoloaded options** → identify the biggest autoloaded options and stop autoloading large blobs. - `references/autoload-options.md` - **Object cache misses** → introduce caching or fix cache key/group usage; add persistent object cache where appropriate. - `references/object-cache.md` - **Remote HTTP calls** → add timeouts, caching, batching; avoid calling remote APIs on every request. - `references/http-api.md` - **Cron** → reduce due-now spikes, de-duplicate events, move heavy tasks out of request paths. - `references/cron.md` ### 6) Verify (repeat the same measurement) - Re-run the same `wp profile` / `wp doctor` / REST request. - Confirm the performance delta and that behavior is unchanged. - If the fix is risky, ship behind a feature flag or staged rollout when possible. ## WordPress 6.9 performance improvements Be a