Web performance (umbrella)
How fast a web page loads and responds for real users, and the discipline of getting there by shipping less and executing less. This wiki’s umbrella concept, anchored on page-weight minimalism. Across the sources it decomposes into the byte layers, the measurement chain, and the discipline that ties them together:
- The bytes you author — page-weight (the founding concept and now-measured baseline: a ~2,600 KB median page) and its app-era successor bundle-size (ship less code, less runtime, tree-shakeable modules).
- The bytes you ship them as — the delivery layer: brotli for text, avif for images (the single highest-leverage saving, since images are the biggest slice).
- The bytes you don’t choose — third-party-resources: scripts on 92% of pages, arriving via deep inclusion chains; a governance problem first-party minimalism can’t reach.
- The measurement — core-web-vitals (LCP/INP/CLS), with inp the responsiveness metric that moves the binding constraint from transfer bytes to main-thread execution. Diagnose in the lab with lighthouse; judge in the field with crux (the only signal Search actually uses).
- The discipline — performance-budget: turning “ship fewer bytes” into a CI gate, at nested scopes (14 KB first packet → 170 KB critical path → whole page).
The through-line
Bytes are necessary but not sufficient: the chain runs author → deliver/execute → CrUX field metrics → ranking, and equal-byte pages post different real-user numbers depending on how they’re compressed and executed. That’s the live tension with the sibling static-site-wiki (architecture vs. payload), recorded not resolved. See synthesis.