Comparison
HydrationvsIslands architecture
Hydration
the page looks finished but clicking a button does nothing for another two seconds.
Attaching client-side behaviour — event listeners and component state — to server-rendered HTML that is already on screen. It is the price of server rendering in a component framework: the browser downloads the same component code, runs it again, and walks the existing DOM to match it up. Because it is one large synchronous chunk of work, it is the classic cause of a page that is visible long before it is interactive.
Full entry →Islands architecture
most of the page is plain HTML that never hydrates, and only the three interactive widgets ship JavaScript.
Rendering the page as static HTML and hydrating only the specific components that need behaviour, each independently. It cuts hydration cost roughly in proportion to how much of your page is actually static, which for content sites is nearly all of it. The constraint is that islands cannot easily share client state with each other, so anything genuinely global has to live outside the model.
Full entry →