A streaming UI is an input-latency disaster unless you build it not to be. Tokens arrive faster than a person can blink, every one of them ends up in React state if you let it, and the main thread that is busy re-rendering the transcript is the same main thread that has to notice a click. So the one control a frustrated user reaches for — stop — is the control whose latency your own render loop is eating. This course is about measuring that, in milliseconds, before arguing about it.
Start lesson one: The metric your stream fails →
The whole spine is registered so the lesson numbers never move. The measurement module is ready; the two fix modules are written against numbers you have not recorded yet, which is the correct order. Ask your teaching agent for the next module once MEASUREMENTS.md has a real “before” column.
Getting a number before you get an opinion — and making sure it is the number your users are actually feeling.
Where the re-render cost actually lives, and which of the standard fixes are theatre.
What you ship into somebody else’s bundle, and what it costs to keep rendering once it is there.
Performance numbers go stale faster than most facts on this site — thresholds get retired, DevTools features move, browser support changes. Every claim here links to the page it came from and says when that page was last updated. If a source has moved on, check the resource list and tell your teaching agent — the course is meant to be corrected.