Profile and Optimize Web Performance

Performance Profiling follows a strict measure, analyze, optimize order, run via scripts/lighthouse_audit.py <url> for automated Lighthouse auditing. Core Web Vitals targets: LCP (loading) good under 2.5s, poor over 4.0s; INP (interactivity) good under 200ms, poor over 500ms; CLS (stability) good under 0.1, poor over 0.25 - measured locally with Lighthouse during development, via Lighthouse CI in CI/CD, and via Real User Monitoring (RUM) in production.

Use it for a structured profiling workflow rather than guessing at problems:

1. BASELINE → Measure current state
2. IDENTIFY → Find the bottleneck
3. FIX → Make targeted change
4. VALIDATE → Confirm improvement

Tool selection follows the problem type: Lighthouse for page load, a bundle analyzer for bundle size, DevTools Performance for runtime issues, DevTools Memory for memory issues, and DevTools Network for network issues. Anti-patterns explicitly called out: guessing instead of profiling first, micro-optimizing instead of fixing the biggest issue, optimizing too early instead of when actually needed, and ignoring real users instead of using RUM data.

Bundle analysis looks for large dependencies at the top of the bundle, duplicate code across multiple chunks, unused code (low coverage), and missing code splits (a single large chunk) - addressed respectively by importing specific modules instead of whole libraries, deduping/updating dependency versions, code-splitting routes, and tree-shaking unused exports. Runtime profiling reads the Performance tab for long tasks (over 50ms, indicating UI blocking), many small tasks (a batching opportunity), and layout/paint versus script time (rendering versus JS execution bottlenecks), and the Memory tab for a growing heap (possible leak), large retained objects (check references), and detached DOM nodes (not cleaned up).

Common bottlenecks map to symptoms: slow initial load points to large JS or render blocking, slow interactions point to heavy event handlers, jank during scroll points to layout thrashing, and growing memory points to leaks or retained references. Five quick-win priorities are ranked by impact: enabling compression, lazy-loading images, and code-splitting routes (all high impact), then caching static assets and optimizing images (medium impact).

Frontend developers diagnosing and fixing web performance issues who want Core Web Vitals targets, a disciplined baseline-identify-fix-validate workflow, and symptom-to-bottleneck mapping rather than ad hoc optimization - guided by the principle that the fastest code is code that doesn't run, so removing work comes before optimizing it.