wp-performance

Overview of wp-performance skill

What wp-performance is for

The wp-performance skill helps you investigate and improve WordPress performance from the backend, without relying on a browser UI. It is built for cases where you need a practical path from “this site is slow” to a measured fix, especially for Performance Optimization work on WordPress 6.9+ environments.

Who should install it

Use the wp-performance skill if you work on slow frontend requests, admin pages, REST routes, or WP-Cron activity and want a guided workflow for profiling, diagnosis, and safe verification. It is especially useful when you can use WP-CLI, logs, and direct HTTP requests, but not a full browser-based debugging session.

What it covers best

The strongest parts of the wp-performance skill are measurement-first triage and backend fixes for database queries, autoloaded options, object caching, cron, and remote HTTP calls. It also points you toward the right tool for the job, including wp profile, wp doctor, Query Monitor via REST headers, and Server-Timing when available.

How to Use wp-performance skill

Install and scope it correctly

Run the wp-performance install flow in the WordPress/agent-skills collection with the skill slug wp-performance, then confirm the target site context before you ask for analysis. The skill works best when you provide --path=<path> for the WordPress root and, for multisite or routed installs, --url=<url> for the exact site or endpoint you want assessed.

Give the skill inputs it actually needs

A strong wp-performance usage prompt includes the symptom, the scope, and the environment. For example: “Staging site, no writes allowed, slow logged-in admin dashboard, use wp-performance to profile the main query path and suggest safe read-only checks first.” That is better than “site is slow” because it tells the skill what to measure and what constraints apply.

Read the right files first

Start with SKILL.md, then read references/measurement.md, references/database.md, references/autoload-options.md, references/object-cache.md, references/cron.md, and references/http-api.md depending on the symptom. If you need headless Query Monitor or command-driven checks, also inspect references/query-monitor-headless.md, references/wp-cli-profile.md, references/wp-cli-doctor.md, and scripts/perf_inspect.mjs for workflow cues.

Use a measurement-first workflow

The best wp-performance guide flow is: capture a baseline, test one reproducible URL or REST route, inspect the highest-cost layer, then verify after a targeted change. Keep the scenario fixed across runs, compare multiple samples instead of one spike, and avoid asking for destructive actions unless you explicitly allow them.

wp-performance skill FAQ

Is wp-performance only for backend agents?

Yes. This skill is designed for backend-only investigation using WP-CLI, headers, logs, and HTTP requests. If you need browser interaction, visual waterfall analysis, or click-path testing, wp-performance is not the right primary tool.

How is it different from a generic prompt?

A generic prompt may tell you to “optimize WordPress,” but wp-performance brings a constrained workflow for measurement, guardrails, and WordPress-specific fault domains. That matters because the fix depends on whether the bottleneck is DB queries, autoload bloat, cron, or remote HTTP calls.

Is it beginner-friendly?

Yes, if you can describe the symptom and provide the install context. The skill is helpful for beginners because it narrows the first checks, but you still need to supply a clear target URL or route and say whether writes, plugin installs, or cache flushes are allowed.

When should I not use it?

Do not use wp-performance if the issue is unrelated to WordPress execution, such as CDN routing, DNS failure, or a pure frontend JavaScript bottleneck. It is also a poor fit when you cannot access the server, cannot run WP-CLI, and have no way to inspect HTTP responses or logs.

How to Improve wp-performance skill

Give stronger starting evidence

The most useful input is a concrete target plus a symptom pattern: https://example.com/wp-json/..., “only slow for logged-in editors,” “TTFB spikes every 5 minutes,” or “admin page stalls after login.” That helps wp-performance choose between measurement paths instead of guessing.

Tell it what kind of change is allowed

If you want a safe first pass, say so. For example: “Read-only diagnostics only,” “no cache flush,” or “staging only, can change options.” This improves the wp-performance skill because the workflow can avoid risky checks and stay inside your operational limits.

Ask for the fix path, not just the diagnosis

The best wp-performance usage results come when you ask for both the bottleneck and the next verification step. For example: “Identify the slowest layer, name the likely cause, and give the exact follow-up command or request to confirm improvement.” That keeps the output actionable.

Iterate on the first report

If the first pass points to queries, feed back the slow table, hook, or route and ask for a narrower query plan. If it points to autoloaded options, object cache, cron, or HTTP API calls, ask for the smallest safe remediation and a before/after measurement plan. That is where the wp-performance skill adds the most value for Performance Optimization work.