Performance & Web Vitals
Loading, interaction responsiveness and visual stability measured on real devices, with the main-thread and memory work behind each one. Measure before optimising, always.
Lab profiles and field data are two instruments answering two different questions. Which browser signal to reach for, and why a local recording is a hypothesis rather than evidence.
The main content has to be discovered, requested, delivered and unblocked before it can paint. Late is usually a discovery or a blocking problem, not a byte problem.
A slow tap is three separable delays: waiting for the thread, running the handler, and producing the frame that shows the result. Each has a different fix.
Content moves because something arrived after layout had already been decided. Reserve the space before the content exists, and the shift never happens.
Bytes are only the download. Parse, compile, execute and retain all cost more, they all scale with the device, and execution competes with rendering for the one thread that can paint.
The two heaviest things on most pages, and the two most often shipped at the wrong size, in the wrong format, discovered too late, and without any space reserved for them.
The app is fine on load and slow an hour later. Something is being retained on every interaction and released on none.
A hundred thousand rows of data, about thirty rows of DOM. It is the right answer for large lists and it costs you real things.
Trading recomputation for memory and an invalidation problem. Sometimes clearly worth it; applied everywhere, a net loss with extra bugs.