Hydration

Hydration is the seam in server-rendered JavaScript applications, and it produces the specific and infuriating user experience of a page that has visibly finished loading but ignores clicks.

The cost is proportional to the amount of component code shipped and executed, and it runs on the main thread, so on a mid-range mobile device it can take several seconds during which the interface is inert. This is what the Interaction to Next Paint metric increasingly punishes, and it is why server-side rendering alone does not guarantee a good experience — it improves what the user sees and can make what the user can do worse.

The mitigations are all forms of doing less. Partial hydration or islands architecture hydrates only the genuinely interactive regions and leaves static content as plain HTML. Progressive hydration prioritises components in the viewport or on interaction. Server components keep component logic on the server so it is never shipped at all. And resumability serialises execution state so the client continues rather than re-executing.

The architectural read is that hydration cost is a direct function of how much of the page is treated as an application. Most pages are mostly document, and the frameworks that recognised this are the ones that improved the numbers.