wp-perf-audit

Audits live WordPress site performance and reports ranked findings with evidence.

2|1|Updated Aug 12, 2026
One-click install
npx skills add https://github.com/billylui/wordpress-performance-skills --skill wp-perf-audit-billylui
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: wp-perf-audit
Source: https://github.com/billylui/wordpress-performance-skills/tree/main/skills/wp-perf-audit
Command: npx skills add https://github.com/billylui/wordpress-performance-skills --skill wp-perf-audit-billylui

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes scripts (resource) and references (resource) components.

What problem does it solve? Diagnosing why a WordPress site is slow usually produces guesses or generic advice that ignores the site's actual stack, hosting restrictions, and what was never measured. This Skill performs a read-only, evidence-backed performance audit of a live WordPress site at whatever access level is available, separating origin from edge TTFB and stating plainly what could not be checked. ## Core Features & Use Cases - Stack fingerprinting: Detects page builder, theme, caching layers, CDN, host class, multilingual plugins, WooCommerce, and multisite, each with confidence levels and evidence. - Origin-versus-edge measurement: Measures TTFB at both layers, payload weight, request counts, and Core Web Vitals (LCP, INP, CLS) when a browser path exists, reporting unmeasured metrics explicitly rather than guessing. - Ranked findings with a defect catalog: Matches symptoms to a 20-entry catalog covering frontend, caching, backend, and platform issues, ranked by expected metric impact, and validates the final report against a fixed contract with a bundled checker. - Use Case: Point it at a slow WooCommerce store URL; it fingerprints the stack, measures cache behavior and page weight, identifies that render-blocking builder CSS is the top issue, and delivers a ranked report noting that LCP was unmeasured because no browser tool was available. ## Quick Start Audit the performance of my WordPress site at https://example.com and give me a ranked report of what is slowing it down.

Frequently Asked Questions about wp-perf-audit

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I audit WordPress site performance from just a URL?

Run the audit against the public URL with no credentials; tier 0 is a complete audit of the frontend and public cache layers. The bundled fingerprint and probe scripts measure stack signals, origin-versus-edge TTFB, payload weight, and request counts.

How to measure Core Web Vitals like LCP, INP, and CLS for WordPress?

Core Web Vitals require a browser-capable path such as Chrome DevTools MCP, Lighthouse CLI, or a PageSpeed Insights API key. If none is available in the session, the audit reports those metrics as unmeasured with the reason rather than estimating them.

Does this WordPress audit work on managed hosts like WP Engine or Kinsta?

Yes, and it respects host constraints: managed hosts publish disallowed-plugin lists and remove prohibited cache plugins, so recommendations are checked against a host-constraint table covering 17 host classes. Unresearched hosts are treated as unconfirmable rather than guessed.

Can the audit change anything on my production WordPress site?

No, the audit is strictly read-only and safe against production; it measures and explains but changes nothing. Applying fixes is handled by the separate wp-perf-fix skill with rollback for every change.

Why does the audit report say some metrics are unmeasured?

A metric is marked unmeasured when the session lacks the capability to measure it, such as no browser for paint timing or no WP-CLI for backend profiling. The report states the concrete reason and what access would unlock it, so absence of data is never read as a clean bill of health.

What access do I need for backend WordPress performance profiling?

Backend profiling such as slow queries, autoload bloat, and cron spikes requires tier 2 access, meaning working WP-CLI against the installation. The audit hands off deep backend profiling to the WordPress/agent-skills wp-performance skill rather than duplicating it.