Performance

When to use it

Investigate and improve measured WordPress performance: slow queries, N+1 loads, autoloaded options, object/page cache correctness, cron and remote calls, hook cost, Core Web Vitals. Use for a slow or must-scale journey with workload context; ordinary code review alone does not select this skill.

Boundaries and hand-offs

Security of an endpoint to wp-devkit-security-review; WooCommerce HPOS order APIs to wp-devkit-woocommerce-dev; WP-CLI batch runbooks to wp-devkit-wpcli-and-ops; schema backfills to wp-devkit-migration-upgrade-review; accessibility of loading states to wp-devkit-wcag-review.

Ask Claude

With the plugin loaded, start a read-only review of a bounded target:

/wp-devkit:performance-review <target-path>

The short form /wp-devkit:performance requests a quick scan.

Ask Codex, ChatGPT or Antigravity

Name the installed skill and keep the request bounded. Replace the target with your files or journey.

$wp-devkit-performance-review
Review the target without editing files.
Read the project instructions and the skill's engineering contract first.
Separate confirmed findings from candidates and state the evidence and checks you could not run.

What it covers

The agent loads only the reference that matches the task:

• background-work-and-http.md : WP-Cron, Action Scheduler, remote HTTP, admin-ajax and Heartbeat, hook cost. Read when work happens on the request path or jobs back up.
• frontend-performance.md : LCP, INP, CLS, WordPress asset APIs, images, fonts, speculative loading. Read for browser metrics.
• performance-cache-coordination.md : object cache, transients, page cache privacy, invalidation, locks, counters. Read for stale or wrong cached data and stampedes.
• performance-review-workbook.md : Performance review workbook
• profiling-and-tooling.md : Query Monitor, wp profile , SAVEQUERIES , EXPLAIN, load tools, safe production sampling. Read before measuring.
• queries-and-options.md : WP_Query arguments, meta/taxonomy queries, N+1, autoload and options, indexes, HPOS, large tables. Read for slow queries or database load.

How a review runs

1. Define the journey and the symptom class: slow server response (TTFB), slow query, memory/timeouts, stale or wrong cached data, background backlog, or slow browser metrics. Different classes use different evidence.
2. Establish the measurement: same build, dataset, user and cache state before and after; enough repetitions to see variance; separate cold and warm cache. Read references/profiling-and-tooling.md for tools and commands.
3. Locate cost: database (count, duplicates, slow statements, EXPLAIN), hooks and filters, remote HTTP, cache miss rate, memory, then frontend (network waterfall, long tasks, layout shifts).
4. Judge the cause against the topic references; load only what applies (list below).
5. Check that a proposed change preserves the result contract: filters, order, visibility, pagination, totals, privacy and multisite scope. A faster query that changes results is not an optimization.
6. Rank by measured share of the request, not by how suspicious the code looks. Report estimated gain only with a basis; never invent a speedup from source reading. Read references/performance-review-workbook.md for severity rules, the finding template, false positives and acceptance checks.

What you get back

Lead with the verdict, journey and measurement basis. Per finding: severity, file:line, trigger (request/data volume), measured evidence (numbers, tool, run conditions), root cause, expected effect and its basis, minimal fix, regression or budget check. Keep hypotheses and missing measurements separate. End with executed checks (command, exit status), unexecuted checks (for example persistent cache, production-sized data, field data) and residual risk. For implementation add before/after numbers on the same dataset. A pass on a lab run does not prove field improvement.

Where to go next

Use review to fix for a bounded implementation and Doctor and reports for environment and evidence tooling.