Hydration

The server sends finished markup, the browser paints it, and the reader can read the page immediately. What they cannot yet do is use it. The behaviour lives in a script that has to be fetched, parsed and run, and hydration is that run: it walks the markup the server produced, attaches the event listeners, and rebuilds in memory the component state the server only serialised. Until it finishes, every control on the page is a picture of a control.

That gap is the whole reason the word matters to designers rather than only to framework authors. Nothing on screen says which side of it the page is on, so a reader presses a button that looks perfectly ordinary and nothing happens, then presses it again, and the second press often lands after the pass has swapped the element underneath them, which is one of the ways a ghost click is made. The same ordering explains the theme flicker in flash of inaccurate color theme: a preference read after hydration is read after the wrong colours have already been painted. The honest answers are all about the pre-hydration state rather than about the pass itself. Make the server-rendered version genuinely work where it can, as a real link or a real form post, so a press is not lost. Where it cannot work, say so: a control that is visibly busy or disabled for 400 ms is a smaller insult than one that silently swallows input. Queueing the press and replaying it after the pass is the third option, and the one that goes wrong most interestingly, because a queued press can arrive at a control that has since moved.

Hydration is the mirror image of a skeleton screen, and the pair is worth keeping straight: a skeleton is paint arriving late, hydration is behaviour arriving late. It is also not server-side rendering, though the two are always discussed together. Server rendering is what produced the HTML; hydration is the price the client pays to take that HTML over, and the price is real, since the tree is effectively shipped twice, once as markup and once as the serialised props the script needs to agree with it. Disagree with it and you get a hydration mismatch, where the framework finds markup it would not have produced and either patches or discards the server’s work.

Most of the interesting work in this area is about shrinking the pass rather than speeding it up. Progressive hydration defers whole subtrees until they are needed, selective hydration lets the framework prioritise the part the reader just touched, islands architecture ships behaviour only for the few regions that have any, and resumability tries to abolish the pass altogether by serialising enough state that the client can carry on rather than start again. They are different bets on the same observation: the cheapest hydration is the one you never run.