Performance
Audit and fix slow web apps against Lighthouse-style budgets and Core Web Vitals before launch or after regressions.
Overview
Performance is an agent skill most often used in Ship (also Launch, Build) that audits and optimizes web loading and runtime efficiency against Core Web Vitals and explicit resource budgets.
Install
npx skills add https://github.com/addyosmani/web-quality-skills --skill performanceWhat is this skill?
- Prioritizes fixes by Core Web Vitals impact with before/after measurement
- Defines explicit performance budgets (page <1.5 MB, JS <300 KB, CSS <100 KB, above-fold images <500 KB)
- Covers critical rendering path: TTFB <800ms, Brotli/Gzip, HTTP/2–3, edge caching
- Targets trigger phrases: speed up site, reduce load time, performance audit
- Provides concrete code-level optimizations tied to Lighthouse-style audits
- Performance budget: total page weight <1.5 MB
- Compressed JavaScript budget <300 KB
- TTFB target <800ms
Adoption & trust: 14.3k installs on skills.sh; 2.2k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your site feels slow or fails speed checks, but you do not know which assets or server settings to fix first.
Who is it for?
Indie builders shipping Next.js or static sites who want Lighthouse-aligned budgets and ordered fixes before production traffic.
Skip if: Teams optimizing native mobile apps, pure backend API latency without a browser UI, or workloads where performance is already within budget and only monitored.
When should I use this skill?
User asks to speed up a site, optimize performance, reduce load time, fix slow loading, improve page speed, or run a performance audit.
What do I get? / Deliverables
You get prioritized, code-level performance changes aligned to budgets and Core Web Vitals, with a clear before/after measurement plan.
- Prioritized optimization list tied to Core Web Vitals
- Budget-aligned recommendations with code examples
- Before/after measurement notes
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Performance tuning is canonically a ship concern—measuring load time, JS weight, and LCP before users hit production traffic. Maps to the perf subphase where solo builders set budgets, optimize the critical path, and validate before/after metrics.
Where it fits
Run a budget pass on total JS and LCP images right before tagging a production release.
Align TTFB and compression fixes with search visibility goals after Search Console flags slow URLs.
Choose font and image strategies during implementation so above-fold weight stays under the documented caps.
How it compares
Structured performance audit playbook with budgets—not a one-click CDN toggle or generic “make it faster” chat.
Common Questions / FAQ
Who is performance for?
Solo and indie builders shipping web products who need faster loads, smaller bundles, and Core Web Vitals–aware fixes without hiring a performance specialist.
When should I use performance?
Use it in Ship when tuning perf before release, in Launch when page speed affects SEO or conversion, and in Build when frontend choices (images, JS, fonts) are still being finalized.
Is performance safe to install?
Review the Security Audits panel on this Prism page and the skill source before enabling it in your agent; the skill guides optimization and should not require credentials beyond what your project already uses.
SKILL.md
READMESKILL.md - Performance
# Performance optimization Deep performance optimization based on Lighthouse performance audits. Focuses on loading speed, runtime efficiency, and resource optimization. ## How it works 1. Identify performance bottlenecks in code and assets 2. Prioritize by impact on Core Web Vitals 3. Provide specific optimizations with code examples 4. Measure improvement with before/after metrics ## Performance budget | Resource | Budget | Rationale | |----------|--------|-----------| | Total page weight | < 1.5 MB | 3G loads in ~4s | | JavaScript (compressed) | < 300 KB | Parsing + execution time | | CSS (compressed) | < 100 KB | Render blocking | | Images (above-fold) | < 500 KB | LCP impact | | Fonts | < 100 KB | FOIT/FOUT prevention | | Third-party | < 200 KB | Uncontrolled latency | ## Critical rendering path ### Server response * **TTFB < 800ms.** Time to First Byte should be fast. Use CDN, caching, and efficient backends. * **Enable compression.** Gzip or Brotli for text assets. Brotli preferred (15-20% smaller). * **HTTP/2 or HTTP/3.** Multiplexing reduces connection overhead. * **Edge caching.** Cache HTML at CDN edge when possible. * **Send Early Hints (HTTP 103) for slow origins.** When the origin needs hundreds of milliseconds to assemble the final response, return a `103 Early Hints` with `Link: </hero.webp>; rel=preload; as=image` (and similar for critical CSS/fonts) so the browser starts fetching before the `200 OK` lands. Cloudflare reports [20–30% LCP improvements](https://blog.cloudflare.com/early-hints-performance/) on image-heavy pages. Requires HTTP/2+ and is supported by Chromium-based browsers; other browsers ignore the 103 and fall through to the 200 — safe to enable. CDNs (Cloudflare, Fastly, Akamai) can synthesize 103s automatically from prior responses; on your own origin, emit them from the same handler that issues the 200. ### Resource loading **Preconnect to required origins:** ```html <link rel="preconnect" href="https://fonts.googleapis.com"> <link rel="preconnect" href="https://cdn.example.com" crossorigin> ``` **Preload critical resources:** ```html <!-- LCP image --> <link rel="preload" href="/hero.webp" as="image" fetchpriority="high"> <!-- Critical font --> <link rel="preload" href="/font.woff2" as="font" type="font/woff2" crossorigin> ``` **Prerender likely-next navigations** with the [Speculation Rules API](https://developer.chrome.com/docs/web-platform/prerender-pages): ```html <script type="speculationrules"> { "prerender": [{ "where": { "href_matches": "/*" }, "eagerness": "moderate" }] } </script> ``` `moderate` triggers after a ~200ms hover — usually intent-correlated, rarely wasted. See [core-web-vitals → LCP](../core-web-vitals/SKILL.md#lcp-largest-contentful-paint) for the full discussion of eagerness tradeoffs and the `prerenderingchange` gating you'll need for analytics. **Defer non-critical CSS:** ```html <!-- Critical CSS inlined --> <style>/* Above-fold styles */</style> <!-- Non-critical CSS --> <link rel="preload" href="/styles.css" as="style" onload="this.onload=null;this.rel='stylesheet'"> <noscript><link rel="stylesheet" href="/styles.css"></noscript> ``` ### JavaScript optimization **Defer non-essential scripts:** ```html <!-- Parser-blocking (avoid) --> <script src="/critical.js"></script> <!-- Deferred (preferred) --> <script defer src="/app.js"></script> <!-- Async (for independent scripts) --> <script async src="/analytics.js"></script> <!-- Module (deferred by default) --> <script type="module" src="/app.mjs"></script> ``` **Code splitting patterns:** ```javascript // Route-based splitting const Dashboard = lazy(() => import