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".

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 1. If a page can run, read [the measurement workflow](references/MEASUREMENT.md) and establish a field plus lab baseline before editing. 2. Prioritize poor real user Core Web Vitals. Use a DevTools performance trace and its focused insights to find the cause. 3. Inspect and change only the code or assets connected to measured bottlenecks. 4. 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](https://developer.mozilla.org/en US/docs/Web/HTTP/Reference/Status/103) and [the Cloudflare study](https://blog.cloudflare.com/early hints performance/). Resource loading Preconnect to required origins: Preload critical resources: 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. Prerender likely next navigations with the [Speculation Rules API](https://developer.chrome.com/docs/web platform/prerender pages): 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](../core web vitals/SKILL.md lcp largest contentful paint) for the tradeoffs and the prerenderingchange gating needed for analytics. Defer non critical CSS: JavaScript optimization Defer non essential scripts: Code splitting patterns: Tree shaking best practices: Image optimization Format selection Format Use case Browser support AVIF Photos, best compression 92%+ WebP Photos, good fallback 97%+ PNG Graphics with transparency Universal SVG Icons, logos, illustrations Universal Responsive images LCP image priority Font optimization Loading strategy Preloading critical fonts Variable fonts Caching strategy Cache Control headers Service worker caching Runtime performance Avoid layout thrashing Debounce expensive operations Use requestAnimationFrame Virtualize long lists Smooth navigations with View Transitions The [View Transitions API](https://developer.chrome.com/docs/web platform/view transitions) 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: Cross document (MPA style) — Chromium stable, progressive enhancement elsewhere: 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 : Pair this with Speculation Rules (above) for instant + animated navigations. Third party scripts Load strategies Facade pattern Measurement Use [the measurement workflow](references/MEASUREMENT.md) 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](references/RUM.md) and prefer web vitals over a hand rolled metric implementation. References For Core Web Vitals specific optimizations, see [Core Web Vitals](../core web vitals/SKILL.md).