frontend-performance

frontend-performance

A performance specialist that goes beyond what frontend-perfection already does. frontend-perfection runs Lighthouse + a couple of resource-hint checks and owns contrast/tokens/SEO/a11y. This skill owns performance depth: the network/header and built-asset layer that Lighthouse cannot see offline, plus a focused Core Web Vitals Lighthouse run.

Two engines, clearly split by what they can measure:

• perf_headers.py — PURE Python 3 stdlib, OFFLINE. Inspects response headers + protocol + transfer timing for a URL, and statically analyzes a built asset tree (page weight, largest bundles, duplicate libs, missing preloads, GIF→video, service worker, speculation rules, streaming, virtualization, third-party async). No network needed for the directory mode.
• audit.js — real Chrome via chrome-launcher + Lighthouse >= 13 (stable API, .default fallback). Measures the runtime metrics: LCP, FCP, INP, CLS, TTFB, critical request chains, render-blocking resources, compression, HTTP/2.

When to use

• User asks for a "performance audit", "page speed", "core web vitals", "bundle size", "optimize loading", "check HTTP/2 / compression / caching".
• User reports slow LCP/CLS/INP or a heavy bundle.
• frontend-perfection already passed but the user wants perf depth, or the orchestrator (/frontend, mobile-frontend) delegates the perf slice.

Composition

• For contrast/tokens/SEO/a11y/OG — load frontend-perfection (this skill does NOT reimplement those; it owns performance only).
• For SEO-layer breadth — load seo-toolkit.
• For a visual direction before building — load frontend-design-taste.

Workflow

1. Locate the target — a live URL, or a built asset directory (static HTML/CSS/JS or a bundled SPA).
2. Run the offline auditor (no Chrome needed) and capture evidence:

   python3 scripts/perf_headers.py --url https://example.com --out perf-url.json
   echo "perf_headers.py(url) exit=$?"
   python3 scripts/perf_headers.py --dir ./dist --out perf-dist.json
   echo "perf_headers.py(dir) exit=$?"
   

   Exit 0 = no fail checks; 1 = at least one fail; 2 = runner error. Keep the --out JSON and the printed fail lines — they are the evidence that the audit ran and what it found. Paste the exit status and the fail summary into the report; do not summarize from memory.
3. Run the Lighthouse CWV runner (real Chrome) for the runtime metrics, capturing evidence the same way:

   node scripts/audit.js --url https://example.com --mobile --out lh-perf.json
   echo "audit.js(mobile) exit=$?"
   node scripts/audit.js --url https://example.com --desktop --out lh-perf-d.json
   echo "audit.js(desktop) exit=$?"
   

   Default --threshold 90 on the performance category; exit 0 only when performance ≥ threshold. Add --only performance (default) or another category if iterating. Record the printed performance score and the failed weighted audits from each --out JSON as evidence.
4. Fix by audit id — every fix references the audit it closes (perf:http2-3, perf:page-weight, perf:lcp, perf:js-bundle-size, …).
5. Re-audit until green on both engines and both form factors.
6. Write the before/after report — input paths, exact commands, the captured exit statuses (0/1/2) for every engine run, the real fail lines and scores from each --out JSON, interpretation, and what was deliberately NOT done. Evidence over assertion: the report must show the command, its exit status, and the output — not a paraphrase.