Hydration erklärt: HTML interaktiv machen

Was ist Hydration?

Wenn eine Webseite per Server-Side Rendering oder statischer Generierung erzeugt wird, schickt der Server fertiges HTML an den Browser. Besucher sehen Text und Layout sofort, aber Knöpfe, Menüs und Formulare reagieren noch nicht, weil die Programmlogik fehlt. Hydration schließt diese Lücke: Das JavaScript-Framework lädt, durchläuft das vorhandene HTML, ordnet es seinen Komponenten zu und hängt Event-Listener und Zustand an. Das DOM wird dabei nicht neu gebaut, sondern „befeuchtet“, daher der Name.

React beschreibt das in der Dokumentation zu hydrateRoot: Die Funktion übernimmt HTML, das von React-DOM-Servermethoden erzeugt wurde, und macht es interaktiv. Wichtig ist, dass Server-HTML und Client-Rendering übereinstimmen; Abweichungen führen zu Hydration-Fehlern und zusätzlichem Aufwand.

Warum kostet Hydration Performance?

Hydration verlagert Arbeit in den Browser. Das Bundle muss geladen, geparst und ausgeführt werden, anschließend muss das Framework die Komponentenstruktur durchlaufen. Das geschieht im Main Thread, demselben Thread, der auch Klicks verarbeitet. Während dieser Zeit können Eingaben verzögert werden. Web.dev beschreibt in „Rendering on the Web“, dass SSR schnellen ersten Inhalt liefert, die Seite aber bis zur Hydration nicht reagiert, eine Phase, die sich wie eine „Uncanny Valley“ anfühlt: Es sieht fertig aus, ist aber noch nicht bedienbar.

Das zeigt sich in INP, dem Maß für die Reaktionsgeschwindigkeit. Je mehr Komponenten hydriert werden und je größer die Bundles, desto länger blockieren Aufgaben den Thread und desto häufiger kommen träge Klicks vor. Bei mobilen Geräten mit schwächerer CPU fällt das besonders auf.

Wie begrenzt du den Hydration-Aufwand?

• Server-Komponenten nutzen: In modernen Next.js-Setups laufen Komponenten standardmäßig auf dem Server und schicken kein JavaScript an den Client. Nur Komponenten mit Interaktion werden als Client-Komponenten markiert.
• Interaktion isolieren: Ein Formular oder Menü ist eine kleine Client-Insel, der Rest bleibt statisches HTML.
• Bundles verkleinern: Abhängigkeiten prüfen, Code-Splitting, Lazy Loading für Elemente unterhalb des sichtbaren Bereichs.
• Third-Party-Skripte reduzieren: Tracking, Chat und Widgets zählen oft mehr als der eigene Code.
• Messen: Chrome DevTools und Lighthouse zeigen lange Aufgaben und ungenutztes JavaScript.

Hydration vs. JS-Shell

Beide Begriffe werden vermischt. Bei Hydration kommt der Inhalt als fertiges HTML an, JavaScript ergänzt Interaktivität. Bei einer JS-Shell (clientseitiges Rendering) liefert der Server ein fast leeres Dokument mit einem Container, und der Inhalt entsteht erst nach dem Ausführen des JavaScripts. Crawler und KI-Abrufer, die kein JavaScript ausführen oder nur eingeschränkt, sehen dann wenig bis nichts. Für Marketing- und Fachseiten ist die Shell daher eine schlechte Wahl; siehe Crawlability.

Wie handhaben wir das bei Modern Stack?

Wir liefern Inhalte als HTML aus und begrenzen JavaScript auf Stellen, an denen es nötig ist: Formulare, Navigation auf Mobilgeräten, Webseiten-Check. Fachtexte, Glossar und Studienseiten bleiben statisch oder serverseitig. Das senkt Bundle-Größe, verbessert Core Web Vitals und sorgt dafür, dass der Text auch ohne JavaScript lesbar bleibt. Die Architekturentscheidungen dazu stehen im Thema SSR/SSG-Stack.

Typische Fehler

1. Ganze Seiten als Client-Komponente markieren, obwohl nur ein Button interaktiv ist.
2. Inhalte erst nach einem Client-Fetch rendern.
3. Große Bibliotheken für kleine Effekte einbinden.
4. Unterschiede zwischen Server- und Client-Ausgabe, die Hydration-Warnungen auslösen.
5. Nur den Desktop messen, mobile Werte ignorieren.

Verwandte Themen

• SSR
• INP
• Next.js
• Core Web Vitals
• SSR/SSG-Stack