web-perf

Overview

Measure-first performance optimization loop — measure baseline, identify the worst metric, fix ONE thing, re-measure. Prevents guessing and proves every optimization with before/after numbers.

Web Performance Optimization

Persistence

ACTIVE whenever performance is the goal. Never optimize without measuring first. Never declare "faster" without before/after numbers.

The Loop (never skip steps)

1. MEASURE — get baseline numbers (Lighthouse, bundle size, TTFB)
2. IDENTIFY — which metric is worst? (LCP? INP? CLS? TTFB?)
3. DIAGNOSE — what's causing THAT specific metric to be bad?
4. FIX ONE THING — smallest change that moves the needle
5. RE-MEASURE — did the number actually improve? By how much?
6. REPEAT — next worst metric. Never fix two things at once.

Why This Order Matters

Without measuring first: you optimize something that wasn't the bottleneck. Wasted work. Without re-measuring: you "optimized" but might have made it worse (happens more than you think). Fixing two things at once: you don't know which one helped (or hurt).

# Lighthouse CI (if available)
npx lighthouse https://your-site.com --output json --output-path ./lh-report.json

# Bundle analysis (Next.js / Vite / Webpack)
npx next build --analyze  # Next.js
npx vite-bundle-visualizer  # Vite
npx webpack-bundle-analyzer stats.json  # Webpack

Core Web Vitals Targets

Metric	Good	Needs Work	Poor	What It Measures
LCP	< 2.5s	2.5-4.0s	> 4.0s	Largest visible element render time
INP	< 200ms	200-500ms	> 500ms	Responsiveness to user input
CLS	< 0.1	0.1-0.25	> 0.25	Visual stability (layout shifts)

Fix by Metric

LCP (Largest Contentful Paint)

Most common causes and fixes:

1. Render-blocking resources

<!-- BAD: blocks render -->
<link rel="stylesheet" href="styles.css">
<script src="app.js"></script>

<!-- GOOD: non-blocking -->
<link rel="stylesheet" href="critical.css">
<link rel="stylesheet" href="styles.css" media="print" onload="this.media='all'">
<script src="app.js" defer></script>