Optimize web performance for faster loading and better user experience. Use when asked to "speed up my site", "optimize performance", "reduce load time", "fix slow loading", "improve page speed", or "
Install
The skill file stays in the publisher's repository.
Paste the copied command in a terminal. It installs this SKILL.md into that agent.
npx skills add addyosmani/web-quality-skills --skill performance -a cursor -y
Optimize web performance for faster loading and better user experience. Use when asked to "speed up my site", "optimize performance", "reduce load time", "fix slow loading", "improve page speed", or "performance audit".
Questions
How do I install performance?
Download skills/performance/SKILL.md from the publisher, or copy the path and open the repository. PlugMCP lists the skill and does not host the file.
Where does performance live?
The publisher keeps it at https://github.com/addyosmani/web-quality-skills.
Which agents can use performance?
Claude, Cursor, and Codex can read a SKILL.md you add from the publisher's repository.
Optimize web performance for faster loading and better user experience. Use when asked to "speed up my site", "optimize performance", "reduce load time", "fix slow loading", "improve page speed", or "performance audit".
name: performance
description: Optimize web performance for faster loading and better user experience. Use when asked to "speed up my site", "optimize performance", "reduce load time", "fix slow loading", "improve page speed", or "performance audit".
license: MIT
metadata:
author: web-quality-skills
version: "2.0"
Performance optimization
Evidence-led performance optimization using real-user signals for prioritization and browser traces for diagnosis. Focuses on loading speed, runtime responsiveness, and resource delivery.
How it works
If a page can run, read the measurement workflow and establish a field-plus-lab baseline before editing.
Prioritize poor real-user Core Web Vitals. Use a DevTools performance trace and its focused insights to find the cause.
Inspect and change only the code or assets connected to measured bottlenecks.
Re-run equivalent lab measurements and report before/after values, conditions, and uncertainty. Field verification remains pending until enough new user data arrives.
When no runnable page exists, perform static inspection but call findings hypotheses, not measured regressions. Include the command or browser workflow that can verify each high-impact hypothesis.
Prefer a browser tool that records a performance trace and exposes focused insights. With Chrome DevTools MCP, use performance_start_trace and performance_analyze_insight; do not route performance through lighthouse_audit, which covers non-performance Lighthouse categories.
Starting performance budget
Budgets must reflect the product's target devices, networks, page types, and user journeys. The values below are initial guardrails for a typical content or commerce page, not universal pass/fail criteria. Preserve an existing project budget when one is already defined.
Resource
Budget
Rationale
Total page weight
< 1.5 MB
Bounds transfer time and data cost on constrained target networks; calibrate with representative pages
JavaScript (compressed)
< 300 KB
Protect parse and execution cost
CSS (compressed)
< 100 KB
Limit render-blocking work
Images (above-fold)
< 500 KB
Protect likely LCP resources
Fonts
< 100 KB
Limit critical font transfer
Third-party
< 200 KB
Bound code outside product control
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.
Consider Early Hints (HTTP 103) for measured document latency. If a trace shows slow HTML generation and stable critical subresources, send an interim 103 with Link headers before the normal final response from the same request. Use HTTP/2 or later. A CDN may synthesize the 103 from Link headers on an earlier 200, or the origin/edge handler can emit it directly. Unsupported clients continue to the final response, but confirm current browser and infrastructure support. Limit hints to proven critical preloads or preconnects: inaccurate hints waste bandwidth. Cloudflare reported a 20–30% LCP improvement in an artificial, image-heavy test; treat that as a vendor case study, not an expected saving, and measure your result. See MDN's 103 implementation example and the Cloudflare study.
Preload only resources whose late discovery is visible in the trace. Each preload competes for bandwidth and an unnecessary high-priority request can delay LCP.
moderate waits for a stronger intent signal than eager modes. Measure prediction hit rate, transferred bytes, and server cost; a wrong prerender is roughly an unused navigation. See core-web-vitals → LCP for the tradeoffs and the prerenderingchange gating needed for analytics.
// ❌ May cause jank
setInterval(animate, 16);
// ✅ Synced with display refresh
function animate() {
// Animation logic
requestAnimationFrame(animate);
}
requestAnimationFrame(animate);
Virtualize long lists
// For lists > 100 items, render only visible items
// Use libraries like react-window, vue-virtual-scroller, or native CSS:
.virtual-list {
content-visibility: auto;
contain-intrinsic-size: 0 50px; /* Estimated item height */
}
Smooth navigations with View Transitions
The View Transitions API lets the browser cross-fade (or custom-animate) between two DOM states using a single GPU-composited snapshot — no double-render, no layout thrash, and the snapshot doesn't count toward CLS.
Same-document (SPA-style) — Baseline 2026:
// Wrap the DOM mutation that swaps the view
function navigate(newView) {
if (!document.startViewTransition) return swapDOM(newView);
document.startViewTransition(() => swapDOM(newView));
}
/* On both source and destination pages */
@view-transition { navigation: auto; }
That's the entire integration — same-origin navigations now fade automatically. To opt specific elements into shared-element transitions (e.g. a thumbnail expanding into a hero), give them a matching view-transition-name:
Use the measurement workflow whenever a URL is runnable. It defines Chrome DevTools MCP routing, CrUX and fallback sources, repeatable lab conditions, and a compact evidence format.
Metric
Kind
Interpretation
LCP, INP, CLS at p75
Field
User-outcome Core Web Vitals; use for pass/fail prioritization
LCP, CLS in a trace
Lab
Reproducible diagnostic values for one navigation
TBT
Lab
Main-thread blocking diagnostic and a rough INP proxy, not field INP
FCP, Speed Index
Lab
Loading diagnostics, not Core Web Vitals
Raw PerformanceObserver snippets are useful for the current browser session but are not real-user data by themselves. When the user wants production telemetry, read the first-party RUM reference and prefer web-vitals over a hand-rolled metric implementation.
References
For Core Web Vitals specific optimizations, see Core Web Vitals.
How do I install performance?
Download skills/performance/SKILL.md from the publisher, or copy the path and open the repository. PlugMCP lists the skill and does not host the file.
Where does performance live?
The publisher keeps it at https://github.com/addyosmani/web-quality-skills.
Which agents can use performance?
Claude, Cursor, and Codex can read a SKILL.md you add from the publisher's repository.