Das Problem der vollständigen Hydrierung

Hydration bezeichnet den Vorgang, bei dem React serverseitig gerendertes HTML übernimmt und JavaScript-Ereignis-Listener daran anbindet. Der Server sendet zunächst das HTML (schnell). Anschließend lädt der Browser das JavaScript-Bundle herunter, und React „hydratisiert“ das statische HTML, damit es interaktiv wird. Bis die Hydration abgeschlossen ist, sieht die Seite interaktiv aus, ist es aber nicht.

Eine traditionelle Single-Page-Anwendung sendet das gesamte JavaScript-Bundle an den Browser. React muss es herunterladen, parsen und ausführen und anschließend an jede Komponente im Baum Ereignis-Listener anbinden. Bei großen Anwendungen kann dieser Vorgang auf mobilen Geräten der Mittelklasse mehrere Sekunden dauern.

Time to Interactive misst, wie lange es dauert, bis die Benutzer mit der Seite interagieren können. Hydration blockiert die TTI direkt: Die Seite kann bereits fertig aussehen, weil das serverseitig gerenderte HTML sichtbar ist, aber Schaltflächen und Formulare reagieren erst, wenn React die Ereignis-Listener vollständig angebunden hat. Eine hohe TTI bedeutet eine schlechte Benutzererfahrung.

Betrachten Sie eine Marketingseite: 80 % der Inhalte bestehen aus statischem Text, Bildern und Überschriften, die sich nie ändern. Nur 20 % umfassen interaktive Widgets wie ein Newsletter-Formular oder einen Videoplayer. Bei der traditionellen SPA-Hydration wird trotzdem die gesamte Seite verarbeitet, sodass statische Komponenten unnötig bearbeitet werden.

Das Performance-Profiling in den Chrome DevTools zeigt die Hydrationskosten. Im Wasserfalldiagramm des Hauptthreads können Sie die Aufgabe „React hydration“ als langen JavaScript-Ausführungsblock nach dem ersten Rendern erkennen. Je länger dieser Block ist, desto stärker ist der Hauptthread ausgelastet und desto weniger responsiv ist die Seite.

Je größer der React-Komponentenbaum ist, desto mehr Arbeit erfordert die Hydration. React muss jede Komponente besuchen, das serverseitig gerenderte HTML mit dem vergleichen, was die Komponente rendern würde, und Ereignis-Listener anbinden. Eine komplexe Seite mit Hunderten von Komponenten kann selbst auf schnellen Geräten messbare Hydrationskosten verursachen.

React 18 führte die nebenläufige Hydration ein. Dabei kann React die Hydration in kleinere Abschnitte aufteilen und zwischendurch an den Browser abgeben. Dadurch wirkt der Browser während der Hydration großer Bäume nicht vollständig eingefroren. Die nebenläufige Hydration verringert die Auswirkungen jedoch nur — sie beseitigt die grundlegenden Kosten nicht.

Die selektive Hydration (über Suspense) ermöglicht es React, Komponenten nach Priorität zu hydratisieren — Benutzerinteraktionen lösen die sofortige Hydration der betreffenden Komponente aus. Das verbessert die Reaktionsfähigkeit, findet aber weiterhin innerhalb eines einzigen React-Baums statt: Letztlich werden alle Komponenten in diesem Baum hydratisiert.

Die grundlegende Erkenntnis hinter der Islands-Architektur lautet, dass der größte Teil einer typischen Seite überhaupt kein JavaScript benötigt. Navigationsleisten, Hero-Bereiche, Footer-Links, Blogartikeltext und Produktbeschreibungen dienen ausschließlich der Darstellung. Eine Hydration dieser Elemente zu erzwingen, ist daher grundsätzlich ineffizient.

Studien von Teams für Web-Performance zeigen, dass das Parsen und Ausführen von JavaScript auf mobilen Geräten den größten Kostenfaktor darstellt. Ein JavaScript-Bundle mit 300 kB benötigt auf einem durchschnittlichen Android-Telefon 2–3 Sekunden zum Parsen. Eine Verringerung der an den Browser gesendeten JavaScript-Menge bringt im Vergleich zu Optimierungen innerhalb von React überproportional große Performancevorteile.

Jedes Kilobyte JavaScript, das Sie einer React-Anwendung hinzufügen, erzeugt zusätzliche Hydrationsarbeit. Auch wenn eine Komponente ausschließlich dekorativ ist, nimmt sie an der Hydration teil, sobald sie sich im React-Baum befindet. Diese „Hydrationskosten“ steigen mit der Größe der Anwendung und machen es zunehmend schwieriger, bei wachsenden Anwendungen gute TTI-Werte aufrechtzuerhalten.

In welchem Zusammenhang stehen die React-Hydration und Time to Interactive (TTI)?

Bei der traditionellen React-Hydration wird der gesamte Komponentenbaum verarbeitet, auch statische Inhalte, die kein JavaScript benötigen. Dadurch wird Time to Interactive blockiert, und die Kosten steigen mit der Größe der Anwendung. Die nebenläufige und selektive Hydration von React 18 verringert die Auswirkungen, beseitigt die grundlegenden Kosten jedoch nicht. Die zentrale Erkenntnis: Die meisten Inhalte einer Seite benötigen schlicht kein JavaScript, wodurch eine vollständige Hydration ineffizient ist.