render pipeline
what happens between user and pixel. 4 steps are physics. 6 are choices.
| step | cost | culprit |
|---|---|---|
| DNS lookup | 20–200ms | nothing you did |
| TCP handshake | 1 RTT | physics |
| TLS negotiation | 1–2 RTT | security |
| HTTP request | 1 RTT | necessary |
| HTML parse | proportional to size | your HTML |
| render-blocking CSS | 1+ RTT each | your stylesheet decisions |
| render-blocking JS | 1+ RTT + parse + exec | your script tags |
| layout | proportional to DOM depth | your HTML structure |
| paint | proportional to complexity | your CSS effects |
| JavaScript hydration | proportional to framework | your framework choice |
the first 4 steps are the internet working correctly. the last 6 are you, working incorrectly. a document with no render-blocking resources reaches paint after exactly 4 steps. most pages take all 10.
what render-blocking means
a render-blocking resource forces the browser to halt all painting until the resource is downloaded, parsed, and executed. a stylesheet in <head> blocks render. a script without defer or async blocks render. every blocking resource adds at least one round trip to your first paint. the user sees white. they did not ask for white.
the hydration problem
server rendering sends HTML. the user sees content. then hydration runs: the framework re-processes every component, attaches event listeners, rebuilds internal state. the user sees the same content, but now it works differently. the gap between "looks interactive" and "is interactive" is called the time-to-interactive delay. it is caused by shipping a runtime to do something the browser already knows how to do.