frontend-performance

name	frontend-performance
description	Audit web performance depth beyond Lighthouse. Use when the user asks for a performance audit, Core Web Vitals (CWV) review, bundle-size analysis, or to optimize loading — including slow LCP/FCP/INP/CLS, a heavy JS/CSS bundle, or missing HTTP/2, text compression, browser caching, HSTS, resource hints, service worker, or speculation rules. Triggers (casual phrasings included): 'performance audit', 'perf audit', 'frontend perf', 'lighthouse', 'core web vitals', 'cwv', 'lcp', 'cls', 'inp', 'page speed', 'bundle size', 'optimize speed', 'why is my site slow', 'make it faster', 'speed up my page', 'check HTTP/2 and compression', 'проверь производительность', 'ускорь сайт'. Two engines: perf_headers.py (pure-Python stdlib, offline — headers, protocol, page weight, duplicate libs, hints, SW, streaming, virtualization) and audit.js (real Chrome + Lighthouse ≥13 — LCP/FCP/INP/CLS, critical chains, render-blocking). Maps Front-End-Checklist Performance (43 rules). Invoked by /frontend and mobile-frontend.
license	MIT
metadata	{"author":"best","version":"1.0.0"}
when_to_use	Use to audit/polish web performance depth: performance audit, Core Web Vitals (CWV) review, bundle-size analysis, or to optimize loading — slow LCP/FCP/INP/CLS, heavy JS/CSS bundle, or missing HTTP/2 / text compression / browser caching / HSTS / resource hints / service worker / speculation rules. Examples: 'audit my page for LCP/FCP/INP/CLS', 'why is my bundle so big', 'check HTTP/2 and compression headers', 'why is my site slow', 'make it faster'.

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 = no checks; = at least one ; = runner error. Keep the JSON and the printed lines — they are the evidence that the audit ran and what it found. Paste the exit status and the summary into the report; do not summarize from memory.