Performance
Hydration
Hydration is making server-rendered HTML interactive by attaching event listeners and rebuilding component state in the browser. The page looks ready before it can respond.
How it is measured
Measure the gap between First Contentful Paint and the point where clicks work. In a trace, look for a long scripting block after the HTML has painted, and for Total Blocking Time in the lab and INP in the field.
Cost grows with the amount of component code shipped and the size of the DOM it must walk. A mismatch between server and client output forces extra work or a full re-render.
Worked example
A React storefront paints its product grid at 1,300 ms. The framework bundle finishes at 2,400 ms, and hydration runs a 620 ms task from 2,400 to 3,020 ms. A tap on Add to Cart at 2,000 ms sits in the queue until 3,020 ms and gets an INP of about 1,020 ms.
Moving the footer and reviews list to server-only components reduces hydrated code, and the same tap completes in 380 ms.
How it differs
Hydration activates server HTML. Islands architecture limits hydration to the parts that need it. Code splitting reduces how much code must load before hydration can start. Full-page hydration treats every element as interactive whether it needs to be or not.
Common errors
Assuming a fast paint means a usable page. Hydrating static content like footers. Different server and client output causing mismatch warnings and rework. Loading third-party widgets on top of hydration. Measuring only desktop, where the main thread is faster.
In practice
Test a tap on the first screen during load on a throttled mid-range profile. If it stalls, reduce hydrated code with server components, islands, or lazy hydration for below-the-fold sections.