The Full Hydration Problem

Hydration is the process where React takes server-rendered HTML and attaches JavaScript event listeners to it. The server sends the initial HTML (fast), then the browser downloads the JavaScript bundle and React "hydrates" the static HTML to make it interactive. Until hydration completes, the page looks interactive but is not.

A traditional single-page application sends the entire JavaScript bundle to the browser. React must download it, parse it, execute it, and then attach event listeners to every component in the tree. For large applications, this process can take several seconds on mid-range mobile devices.

Time To Interactive measures how long before the user can interact with the page. Hydration directly blocks TTI: the page may look ready (server-rendered HTML is visible), but buttons and forms do not respond until React finishes attaching event listeners. A high TTI score is a poor user experience.

Consider a marketing page: 80% of the content is static text, images, and headers that never change. Only 20% involves interactive widgets like a newsletter form or a video player. Traditional SPA hydration still runs for 100% of the page, processing static components unnecessarily.

Chrome DevTools performance profiling reveals the hydration cost. In the Main thread waterfall, you can identify the "React hydration" task as a long JavaScript execution block after the initial paint. The longer this block, the more the main thread is occupied and the less responsive the page is.

The larger the React component tree, the more work hydration requires. React must visit every component, compare the server-rendered HTML with what the component would render, and attach event listeners. A complex page with hundreds of components can have measurable hydration overhead even with fast devices.

React 18 introduced concurrent hydration, which allows React to break hydration into smaller chunks and yield to the browser between them. This prevents the browser from appearing completely frozen during hydration of large trees. However, concurrent hydration reduces the impact — it does not eliminate the fundamental cost.

Selective hydration (via Suspense) allows React to hydrate components in priority order — user interactions trigger immediate hydration of the relevant component. This improves responsiveness but still operates within a single React tree: all components in the tree are eventually hydrated.

The fundamental insight driving Islands Architecture is that most of a typical page simply does not need JavaScript at all. Navigation bars, hero sections, footer links, blog post text, and product descriptions are purely presentational. Forcing hydration on them is wasteful by definition.

Studies from web performance teams show that JavaScript parse and execution time is the dominant cost on mobile devices. A 300kb JavaScript bundle takes 2-3 seconds to parse on a median Android phone. Reducing the JavaScript sent to the browser has outsized performance benefits compared to any React-internal optimization.

Every kilobyte of JavaScript added to a React application adds hydration work. Even if a component is purely decorative, if it is in the React tree it participates in hydration. This "hydration tax" scales with application size and makes it progressively harder to maintain good TTI scores as applications grow.

What is the relationship between React hydration and Time To Interactive (TTI)?

Traditional React hydration processes the entire component tree, even static content that needs no JavaScript. This blocks Time To Interactive and scales poorly with application size. React 18's concurrent and selective hydration improvements reduce the impact but do not eliminate the fundamental cost. The root insight: most page content simply does not need JavaScript, making full hydration wasteful.