wp-performance

Use this skill when: This skill assumes the agent cannot use a browser UI. Prefer WP-CLI, logs, and HTTP requests. Read: Run: This detects: If you have WP-CLI access, prefer: It catches common production foot-guns (autoload bloat, SAVEQUERIES/WP_DEBUG, plugin counts, updates). Read: Preferred order: Read: Query Monitor is normally UI-driven, but it can be used headlessly via REST API response headers and _envelope responses: Read: Use the profile output to pick one primary bottleneck category: Be aware of these 6.9 changes when profiling: On-demand CSS for classic themes: Block themes with no render-blocking resources: Inline CSS limit increased: Reference: - 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 - Environment and safety: dev/staging/prod, any restrictions (no writes, no plugin installs). - How to target the install: - WP root --path= - (multisite/site targeting) --url= - The performance symptom and scope: - which URL/REST route/admin screen - when it happens (always vs sporadic; logged-in vs logged-out) - Confirm whether you may run write operations (plugin installs, config changes, cache flush). - Pick a reproducible target...