rgoussu.dev
rgoussu@goussu: ~/library/frontend
❯ ~/library/frontend cat web-performance.md

Web performance

# Core Web Vitals and the loading/runtime budgets behind them — measuring real users, then fixing what the metrics actually point at.

Conceptsaved 2026-08-08 #frontend#performance#web-vitals#loading

Overview

Web performance has converged on a small set of user-centric metrics — the Core Web Vitals — that measure what users feel: how fast the main content shows (LCP), how soon interactions respond (INP), how much the page jumps around (CLS). The discipline mirrors backend performance engineering: measure real users first (lab tools flatter you), find the actual bottleneck, and treat budgets as regression tests rather than launch-week heroics.

Key points

  • The vitals and their levers: LCP (≤2.5s — server response, render-blocking resources, image priority/preload), INP (≤200ms — long main-thread tasks; break up JS, see browser internals), CLS (≤0.1 — reserve space: image dimensions, font fallback metrics, no late-inserted banners).
  • Field vs. lab: RUM (CrUX, your own beacons) is the truth — p75 across real devices/networks; Lighthouse is a controlled lab probe for debugging, not the score to optimize. The gap between the two is itself diagnostic (your users' devices are slower than your laptop).
  • JavaScript is the budget's biggest line: cost is parse+compile+execute, not just transfer — code-splitting by route, deferring the non-critical, and shipping less beat any minifier trick; hydration cost is why islands/server-components exist.
  • Loading tactics that matter: HTTP caching + CDN first (cache management applies verbatim), compression (Brotli), preload/preconnect for the critical path, fetchpriority on the LCP image, lazy-loading below the fold (never the LCP element), font-display strategies.
  • Images are usually the weight: modern formats (AVIF/WebP), responsive srcset, and correct sizing routinely halve page weight — the highest ROI fix on most sites.
  • Make it stay fast: performance budgets in CI (bundle size, Lighthouse assertions), RUM dashboards with alerts — performance is a regression class, not a project.
  • To explore: speculative loading (prefetch/prerender, Speculation Rules), edge rendering, the cost model of third-party scripts (tag managers as the usual culprit), bfcache eligibility.

Practice

  • Instrument real users (source) — add the web-vitals library to a site you run, beacon LCP/INP/CLS somewhere, and compare p75 field numbers against your Lighthouse score; the gap is the first lesson.
  • Fix a deliberately slow page (source) — take a heavy page (or sabotage one: unsized images, blocking scripts, a fat bundle), profile it with WebPageTest/Lighthouse, and drive all three vitals green — one metric at a time, measuring each fix.
  • Image pipeline overhaul (source) — convert a real site to AVIF/WebP with srcset and correct sizing, fetchpriority on the LCP image, lazy-loading below the fold; usually the single biggest before/after you'll get.
  • Budget in CI (source) — wire Lighthouse CI assertions and a bundle-size check into a project's pipeline, then try to break them; turns performance from a project into a regression class.

Related