Hydration.

Modern websites built with React or similar JavaScript frameworks are often generated as HTML on the server or at build time, using server-side rendering or static generation. The browser can display this HTML straight away. For buttons, menus and forms to respond, however, the framework then has to load its JavaScript in the browser, rebuild the component tree and connect it to the existing HTML. This process is called hydration, because a 'dry' HTML page is 'watered' with logic.

Hydration is a compromise. It combines the advantages of server-rendered HTML, fast display and good readability for search engines, with the interactivity of a single page application. The price: the browser has to download, parse and execute the code of every interactive component. On large pages this blocks the main thread. During that time the page looks finished but responds to clicks with a delay, which shows up in the INP (Interaction to Next Paint) metric.

A well-known problem is the hydration mismatch. It occurs when the HTML from the server does not match what React expects in the browser, for example when a date is formatted in a different time zone or a value depends on chance. React then issues a warning and rebuilds parts of the page, which can cause visible jumps and extra work.

Developments in recent years aim to hydrate less. Partial hydration and islands architectures bring only individual interactive areas to life instead of the whole page. React Server Components, as used in the App Router of Next.js, render components exclusively on the server and send no JavaScript for them to the browser at all. Only the parts explicitly marked as client components, such as a form or a menu, are still hydrated.