| name | qa-perf |
| description | Application performance optimization. Trigger when the user wants to improve speed, reduce latency, or optimize resources. |
| allowed-tools | ["Read","Write","Edit","Bash","Glob","Grep"] |
| context | fork |
| model | sonnet |
| argument-hint | [page-or-endpoint] |
Performance Optimization (pointer)
Canonical thresholds, current Web Vitals (LCP/INP/CLS — note INP replaced FID in 2024), and Chrome perf-team remediation patterns are at:
addyosmani/web-quality-skills — github.com/addyosmani/web-quality-skills (MIT, 1.8k★, maintained by Addy Osmani — Chrome DevTools / Lighthouse engineering lead). Covers Core Web Vitals, perf, a11y, SEO.- web.dev/vitals — web.dev/vitals (Google's canonical Web Vitals reference)
- Vercel React best practices — see
vercel-react-best-practices skill (foundation-installed) for React-specific patterns
Foundation workflow (when to invoke this skill)
qa-perf is dispatched by qa-loop during the AUDIT phase, in parallel with qa-security / wcag-audit / qa-claudemd. It's a measurement workflow, not an optimisation cookbook:
- Measure first: run Lighthouse / WebPageTest / DevTools Performance against a known scope (the URL, page, or endpoint from
argument-hint).
- Compare to canonical thresholds (see table below).
- Identify the bottleneck axis: render-blocking JS? N+1 DB query? Image weight? Bundle size? Each axis has a dedicated vendor remediation guide.
- Recommend with quantified impact (e.g. "lazy-loading hero image saves ~400ms LCP per Lighthouse run #3").
- Re-measure after the fix — a perf change without before/after numbers is theatre.
Canonical Web Vitals thresholds (2024-2026)
| Metric | Good | Needs improvement | Poor | Tool |
|---|
| LCP (Largest Contentful Paint) | < 2.5s | 2.5–4s | > 4s | Lighthouse, web-vitals |
| INP (Interaction to Next Paint, replaces FID) | < 200ms | 200–500ms | > 500ms | web-vitals |
| CLS (Cumulative Layout Shift) | < 0.1 | 0.1–0.25 | > 0.25 | Lighthouse, web-vitals |
| TTFB | < 200ms | 200–600ms | > 600ms | DevTools Network |
Foundation discipline (keep across releases)
- No optimisation without measurement: profile before changing code. Guessed bottlenecks are wrong ~70% of the time.
- Before/after numbers mandatory: every perf PR must include the Lighthouse delta or equivalent. Without numbers, the work is unprovable.
- Cache invalidation > caching: adding a cache is easy; correctly invalidating it is the bug surface. Surface cache TTLs in code review.
- N+1 is the #1 backend perf bug: when an endpoint feels slow, instrument query count before optimising anything else.
See also
qa-chrome skill — DevTools manual review (paired layer)dev-react-perf skill — React-specific re-render audit + memoization patternsops-monitoring — production perf instrumentation (OTEL, RUM)vercel-react-best-practices skill (foundation-installed)- Audit pilot trace:
specs/marketplace-audit/qa-skills-pilot-2026-05-06.md
