performance
Lighthouse-based performance optimization with budgets, critical rendering path guidance, and Core Web Vitals alignment.
- Defines resource budgets (1.5 MB total, <300 KB JS, <100 KB CSS) and provides server response optimization (TTFB <800ms, HTTP/2, edge caching)
- Covers resource loading strategies: preconnect/preload directives, deferred CSS, script deferral patterns, and code splitting techniques
- Includes image optimization (AVIF/WebP selection, responsive markup, LCP prioritization) and font strategies (variable fonts, font-display swap, subsetting)
- Addresses runtime performance: layout thrashing prevention, debouncing, requestAnimationFrame, and list virtualization for large datasets
- Provides caching strategies (Cache-Control headers, service worker patterns) and third-party script management (async loading, interaction-based delays, facade patterns)
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.