
wp-performance-review
Use when reviewing WordPress PHP code for performance issues, auditing themes/plugins for scalability, optimizing WP_Query, analyzing caching strategies, or detecting anti-patterns in database queries, hooks, object caching, AJAX, and template loading.
"Use when reviewing WordPress PHP code for performance issues, auditing themes/plugins for scalability, optimizing WP_Query, analyzing caching strategies, or detecting anti-patterns in database queries, hooks, object caching, AJAX, and template loading."
WP Performance Review
When to use
Use this skill when:
- Reviewing PR/code for WordPress theme or plugin
- User reports slow page loads, timeouts, or 500 errors
- Auditing before high-traffic event (launch, sale, viral moment)
- Optimizing WP_Query or database operations
- Investigating memory exhaustion or DB locks
Inputs required
- Files or directories to review.
- Context: dev/staging/prod environment.
- Any constraints: read-only access, no plugin installs.
- Symptoms: slow TTFB, specific URL, admin vs frontend.
Procedure
0) Identify scope and file types
- Identify file type and apply relevant checks
- Note hosting environment (managed, self-hosted, shared)
- Determine if this is admin-only or frontend code
1) Scan for critical patterns first
Run quick detection scans:
# Unbounded queries - CRITICAL
grep -rn "posts_per_page.*-1\|numberposts.*-1" .
# query_posts - CRITICAL
grep -rn "query_posts\s*(" .
# Session start - CRITICAL (bypasses page cache)
grep -rn "session_start\s*(" .
# Polling patterns - CRITICAL (self-DDoS)
grep -rn "setInterval.*fetch\|setInterval.*ajax" .
Read:
references/anti-patterns.md
2) Check warnings (inefficient but not catastrophic)
# DB writes on frontend
grep -rn "update_option\|add_option" . | grep -v "admin\|activate"
# Uncached expensive functions
grep -rn "url_to_postid\|attachment_url_to_postid" .
# External HTTP without caching
grep -rn "wp_remote_get\|wp_remote_post" .
# Cache bypass
grep -rn "cache_results.*false" .
3) Check file-type specific patterns
WP_Query / Database Code:
- Missing
posts_per_pageargument meta_querywithvaluecomparisons (unindexed)post__not_inwith large arraysLIKE '%term%'(leading wildcard)
AJAX Handlers:
- POST method for read operations (bypasses cache)
- Missing nonce verification
Template Files:
- Database queries inside loops (N+1)
wp_remote_getin templates
Read:
references/file-type-checks.md
4) Report findings with severity
Structure findings as:
## Performance Review: [filename]
### Critical Issues
- **Line X**: [Issue] - [Explanation] - [Fix]
### Warnings
- **Line X**: [Issue] - [Explanation] - [Fix]
### Recommendations
- [Optimization opportunities]
Read:
references/output-format.md
Verification
- All critical issues have been identified
- Line numbers are accurate
- Fixes are actionable and WordPress-specific
- Context is considered (admin vs frontend)
Failure modes / debugging
- False positive on admin-only code:
- Check context - admin, CLI, cron are lower risk
- Missing
session_start()in plugin:- Always grep across ALL code including plugins
- Ignoring JS polling patterns:
- Review
.jsfiles forsetInterval+ fetch
- Review
Read:
references/common-mistakes.md
WordPress 6.9 Performance Improvements
Be aware of these 6.9 changes when profiling:
On-demand CSS for classic themes:
- Classic themes now get on-demand CSS loading (previously only block themes)
- Reduces CSS payload by 30-65% by only loading styles for blocks actually used
- If profiling a classic theme, this should already be helping
Block themes with no render-blocking resources:
- Block themes without custom stylesheets (like Twenty Twenty-Three/Four) can now load with zero render-blocking CSS
- Styles come from global styles (theme.json) and separate block styles, all inlined
- Significantly improves LCP (Largest Contentful Paint)
Inline CSS limit increased:
- The threshold for inlining small stylesheets has been raised
- Reduces render-blocking resources
WP-CLI Profiling Commands
If WP-CLI is available, use these for deep profiling:
# See where time goes (bootstrap/main_query/template)
wp profile stage --url=https://example.com/page/
# Find slow hooks/callbacks
wp profile hook --url=https://example.com/page/
# Profile specific code path
wp profile eval 'do_action("init");'
# Run health checks
wp doctor check
Query Monitor Headless Usage
For backend-only debugging, Query Monitor works via REST API:
- Authenticate (nonce or Application Password)
- Request with
?_envelopeparameter - Inspect
x-qm-*headers orqmproperty in response
Escalation
- If production and no explicit approval, do NOT: install plugins, enable
SAVEQUERIES, run load tests, or flush caches during traffic - For system-level profiling (APM, PHP profilers), coordinate with ops/hosting
Consult:
You Might Also Like
Related Skills

fix
Use when you have lint errors, formatting issues, or before committing code to ensure it passes CI.
facebook
frontend-testing
Generate Vitest + React Testing Library tests for Dify frontend components, hooks, and utilities. Triggers on testing, spec files, coverage, Vitest, RTL, unit tests, integration tests, or write/review test requests.
langgenius
frontend-code-review
Trigger when the user requests a review of frontend files (e.g., `.tsx`, `.ts`, `.js`). Support both pending-change reviews and focused file reviews while applying the checklist rules.
langgenius
code-reviewer
Use this skill to review code. It supports both local changes (staged or working tree) and remote Pull Requests (by ID or URL). It focuses on correctness, maintainability, and adherence to project standards.
google-gemini
session-logs
Search and analyze your own session logs (older/parent conversations) using jq.
moltbot
