Core Web Vitals engineering
One page, two builds, measured where it counts: p75.
This is a live before/after case study. The identical marketing page — same copy, same layout, same images — is shipped two ways. The /before route piles on every classic performance mistake; the /after route applies the fixes from the build roadmap (Server Components, next/image, deferred third-party scripts, a Web Worker, reserved layout space). A tiny web-vitals beacon reports the real LCP, INP and CLS of every visit to both, and the dashboard aggregates them at the 75th percentile — the same model Google ranks on.
The slow page
Client-rendered everything, render-blocking third-party scripts, an unsized full-size hero, a render-blocking web font with no font-display, a late banner that shifts layout, and heavy synchronous work on load and on every click.
The sub-second page
Server Components, a prioritized next/image hero, the system-font stack, explicit sizes on all media, third-party scripts on lazyOnload, heavy compute in a Web Worker, a dynamically-imported below-the-fold widget, and reserved space everywhere.
The shape of the proof
Illustrative p75 targets (the live figures are on the dashboard). A page passes only when all three metrics are good for at least 75% of real-user visits.
| Metric | Before (p75) | After (p75) | Good (p75) |
|---|---|---|---|
| LCP | 6.2s | 0.9s | ≤ 2.5s |
| INP | 420ms | 150ms | ≤ 200ms |
| CLS | 0.28 | 0.05 | ≤ 0.1 |
Field data is the headline; the lab (Lighthouse) score is only supporting evidence. Run the audit with npm run audit and see measurement/checklist.md for the reusable performance-audit checklist.