Server-Side Rendering und Hydration richtig nutzen

Beim Server-Side Rendering führt der Server die Anwendungslogik aus und erzeugt vollständiges HTML, bevor die erste Antwort an den Browser geht. Der Nutzer sieht dadurch sehr früh Inhalte: Der Largest Contentful Paint (LCP) profitiert, weil das sichtbare Markup nicht erst im Browser zusammengebaut werden muss. Im Gegensatz dazu liefert eine reine Single-Page-Application (Client-Side Rendering) zunächst nur ein leeres Gerüst und einen JavaScript-Bundle, der den Inhalt erst nach dem Download aufbaut. SSR verschiebt diese Arbeit auf den Server und liefert ein fertiges Bild.

Der Haken folgt unmittelbar danach. Das ausgelieferte HTML ist statisch: Buttons reagieren nicht, Formulare senden nicht, Dropdowns öffnen sich nicht. Um die Seite zum Leben zu erwecken, lädt der Browser denselben Komponenten-Code, der bereits auf dem Server lief, führt ihn erneut aus und verbindet die vorhandenen DOM-Elemente mit Event-Handlern und dem Reaktivitätsmodell. Dieser Prozess der nachträglichen Verkabelung ist die Hydration. Standardmäßig hydriert ein klassisches Framework die gesamte Seite in einem Durchgang auf dem Hauptthread, und Interaktivität entsteht erst, wenn der komplette Bundle heruntergeladen und ausgeführt wurde.

Das Ergebnis ist die sogenannte Uncanny Valley der Interaktivität: Die Seite sieht fertig aus, reagiert aber noch nicht. Nutzer klicken auf einen Button, und nichts passiert, weil der zugehörige Event-Handler noch nicht angebunden ist. Diese Lücke zwischen sichtbarem Inhalt und tatsächlicher Bedienbarkeit schlägt sich direkt im Interaction to Next Paint (INP) nieder, der seit März 2024 als Core Web Vital die Reaktionsfähigkeit einer Seite misst. Ergänzende Strategien dazu beschreibt unser Beitrag zur [INP-Optimierung1.

Hydration ist teuer, weil sie dieselbe Arbeit doppelt erledigt. Der Server hat die Komponenten bereits ausgeführt, um das HTML zu erzeugen. Der Browser führt denselben Code erneut aus, um Komponentengrenzen, Event-Listener und den Reaktivitätsgraphen wieder aufzubauen. Bei einer klassischen Vollhydration muss der Browser dazu das gesamte JavaScript-Bundle herunterladen, parsen, kompilieren und ausführen, bevor irgendein Teil der Seite interaktiv wird. Ein einzelner schwergewichtiger Codeabschnitt kann so verhindern, dass der Rest der Seite reagiert.

Diese Arbeit läuft fast vollständig auf dem Hauptthread und blockiert ihn. Jede Aufgabe, die den Hauptthread länger als 50 Millisekunden belegt, gilt als Long Task; die Zeit jenseits dieser 50 Millisekunden zählt als Blockierzeit. Die Total Blocking Time (TBT) summiert diese Blockierzeiten und korreliert eng mit dem INP. Für eine gute Bewertung empfiehlt web.dev eine TBT von unter 200 Millisekunden auf Mobilgeräten (Quelle: web.dev, 2024). Hydration-lastige Seiten reißen diesen Wert regelmäßig, weil die gebündelte Verkabelung in einem großen Long Task stattfindet.

Besonders deutlich wird die Belastung auf Mobilgeräten. Ein durchschnittliches Mittelklasse-Smartphone verarbeitet JavaScript um ein Vielfaches langsamer als ein Desktop-Rechner. Da die mittlere mobile Seite über 500 KB JavaScript ausliefert (Quelle: Web Almanac, 2024) und im Median 22 JavaScript-Requests absetzt (Quelle: Web Almanac, 2024), entstehen genau auf den Geräten lange Blockierphasen, auf denen ein großer Teil der Shop-Besucher unterwegs ist. Wer Hydration ignoriert, optimiert am realen Nutzer vorbei. Ein systematisches Vorgehen mit klaren Obergrenzen beschreibt unser Beitrag zu [JavaScript-Performance-Budgets1.

Die Islands-Architektur dreht die Standardannahme um. Statt die gesamte Seite als interaktive Anwendung zu behandeln, betrachtet sie die Seite als überwiegend statisches HTML mit einzelnen interaktiven Inseln. Der Server rendert die komplette Seite, fügt aber nur um die wirklich dynamischen Bereiche herum Platzhalter ein, die anschließend im Browser zu eigenständigen Widgets hydriert werden. Alles andere bleibt reines, unveränderliches HTML, das keinerlei JavaScript benötigt.

Der Effekt auf die JavaScript-Last ist erheblich. Da nur die Inseln Code mitbringen, sinkt der ausgelieferte JavaScript-Anteil drastisch. Praxisberichte zeigen, dass die Islands-Architektur den JavaScript-Footprint um bis zu 80 Prozent reduzieren kann, etwa von rund 1 MB auf etwa 200 KB (Quelle: Web Almanac, 2024). Weniger JavaScript bedeutet weniger Download, weniger Parsing und vor allem weniger Hydration-Arbeit auf dem Hauptthread. Genau diese Reduktion macht gute Core Web Vitals leichter erreichbar.

Für Online-Shops ist das Modell besonders gut geeignet, weil die meisten Seitenbereiche statisch sind. Produktbeschreibungen, Kategorietexte, Footer, Navigation und Markenbereiche brauchen keinerlei Hydration. Interaktivität konzentriert sich auf wenige Inseln: den Warenkorb-Button, die Variantenauswahl, die Mengeneingabe und die Suche. Eine durchdachte [Frontend-Optimierung1 trennt diese interaktiven Inseln sauber vom statischen Gerüst und liefert nur dort JavaScript aus, wo es wirklich gebraucht wird.

Partielle Hydration ist das Prinzip hinter der Islands-Architektur: Nur ausgewählte Komponenten werden hydriert, der Rest bleibt statisch. Progressive Hydration geht einen Schritt weiter und steuert, wann und in welcher Reihenfolge die Inseln aktiviert werden. Nicht jede interaktive Komponente muss sofort reagieren. Ein Warenkorb-Button braucht frühe Interaktivität, ein Bewertungs-Karussell weit unten auf der Seite hingegen kann warten, bis der Nutzer es überhaupt erreicht.

Daraus ergeben sich mehrere Hydration-Strategien, die sich pro Komponente festlegen lassen. Eine Komponente kann sofort hydriert werden (für kritische Interaktivität), beim Eintreten in den sichtbaren Bereich (Lazy bei Sichtbarkeit), während der Browser im Leerlauf ist (Idle) oder erst bei der ersten Nutzerinteraktion (On-Demand). Diese feingranulare Steuerung verteilt die Hydration-Arbeit über die Zeit, statt sie in einem einzigen blockierenden Block zu bündeln, und hält den Hauptthread für echte Nutzereingaben frei.

Die On-Demand-Hydration ist dabei besonders wirkungsvoll für schwergewichtige Widgets. Ein Chat-Widget, das beim ersten Seitenaufruf nicht benötigt wird, kann seinen Code erst laden, wenn der Nutzer tatsächlich auf den Chat-Button tippt. Damit verschwindet sein gesamter Hydration-Aufwand aus dem kritischen Pfad. Diese Technik ist verwandt mit Lazy Loading und Code Splitting, die wir in unserem Beitrag zu [Lazy Loading und Code-Splitting1 ausführlich behandeln.

Moderne Frameworks haben die starre Vollhydration aufgebrochen. Mit Streaming-SSR sendet der Server das HTML nicht mehr in einem Stück, sondern in Teilstücken, sobald sie fertig sind. Langsame Bereiche, etwa ein personalisierter Empfehlungsblock, halten nicht mehr die gesamte Seite auf. Der Browser zeigt die schnellen Teile sofort an und erhält die langsamen nachgeliefert, sobald die Daten verfügbar sind.

Die selektive Hydration ergänzt dieses Streaming. Statt zu warten, bis der komplette Bundle geladen ist, beginnt das Framework die Hydration, sobald der Code für eine einzelne Komponente verfügbar ist, und priorisiert dabei die Bereiche, mit denen der Nutzer gerade interagiert. Klickt jemand auf eine noch nicht hydrierte Komponente, wird genau diese bevorzugt aktiviert. Ein schwergewichtiger Codeabschnitt blockiert so nicht mehr die Interaktivität des restlichen Seiteninhalts.

Diese Kombination aus Streaming und priorisierter Hydration verbessert den INP in der Praxis spürbar, weil die Bereiche zuerst interaktiv werden, die der Nutzer wirklich braucht. Wichtig bleibt dennoch die Disziplin bei der Bundle-Größe: Selektive Hydration verteilt die Arbeit besser, reduziert aber nicht die Gesamtmenge an JavaScript. Eine durchdachte [Performance-Analyse1 deckt auf, welche Komponenten überhaupt von früher Hydration profitieren und welche getrost warten können.

Der konsequenteste Ansatz vermeidet Hydration vollständig. Resumability serialisiert den Zustand der Anwendung bereits auf dem Server, sodass der Browser die Ausführung dort fortsetzt, wo der Server aufgehört hat, ohne den Komponenten-Code erneut auszuführen. Wo Hydration die Anwendung vom Wurzelknoten an erneut durchläuft, um Komponentengrenzen, Event-Listener und den Reaktivitätsgraphen einzusammeln, überspringt Resumability diesen Schritt komplett, weil der Server diese Informationen bereits serialisiert hat.

Der entscheidende Vorteil liegt im Skalierungsverhalten. Klassische Hydration wächst mit der Komplexität der Seite: Mehr Komponenten bedeuten mehr Code, der heruntergeladen und ausgeführt werden muss, bevor Interaktivität entsteht. Resumability strebt eine nahezu konstante Startlast (O(1)) an, weil zunächst kein Anwendungscode ausgeführt wird. JavaScript wird erst geladen, wenn eine konkrete Interaktion es erfordert, und auch dann nur der dafür nötige Teil.

Resumability ist noch ein vergleichsweise junger Ansatz und nicht für jedes Projekt die richtige Wahl, da er ein passendes Framework und ein angepasstes Architekturdenken voraussetzt. Für sehr große, komplexe Shops mit vielen interaktiven Elementen kann er jedoch den entscheidenden Unterschied machen, weil die Startlast unabhängig von der Seitengröße niedrig bleibt. In der Praxis ist die Wahl zwischen partieller Hydration und Resumability eine Abwägung aus Reifegrad, Team-Erfahrung und konkreten Performance-Zielen.

Shopware im Open-Source-Umfeld setzt im Storefront auf serverseitig gerendertes HTML mit gezielt eingesetztem JavaScript für interaktive Bestandteile. Das ist eine gute Ausgangslage, weil der Großteil einer Produkt- oder Kategorieseite ohnehin statisch ist. Die Aufgabe besteht darin, den interaktiven JavaScript-Anteil sauber auf Inseln zu begrenzen und nicht versehentlich die gesamte Seite mit unnötigem Code zu beladen.

In der Praxis bedeutet das, Plugin-Funktionalitäten in separate Einstiegspunkte aufzuteilen, sodass etwa ein Konfigurator oder ein aufwändiges Filtermodul nur auf den Seiten geladen wird, auf denen es gebraucht wird. Schwergewichtige Drittanbieter-Skripte wie Chat oder Bewertungs-Widgets werden per On-Demand- oder Lazy-Strategie nachgeladen. So bleibt der kritische Pfad schlank, und die Hydration konzentriert sich auf die wenigen Komponenten, die der Nutzer sofort braucht. Eine begleitende [Shopware-Performance-Optimierung1 bringt diese Trennung systematisch in die Storefront-Architektur.

Der wirtschaftliche Hebel dahinter ist beträchtlich. Eine gemeinsame Studie von Deloitte und Google zeigt, dass bereits eine Verbesserung der Ladezeit um 0,1 Sekunden die Conversions im Einzelhandel um 8,4 Prozent und den durchschnittlichen Bestellwert um 9,2 Prozent steigern kann (Quelle: Deloitte, 2020). Da Hydration-Optimierung genau jene Verzögerung zwischen sichtbarem und bedienbarem Shop verkürzt, wirkt sie unmittelbar auf diese Kennzahlen. Begleitende Maßnahmen an der [Server-Infrastruktur1 sichern zusätzlich kurze Antwortzeiten beim serverseitigen Rendern.

SSR- und Hydration-Performance ist kein einmaliges Projekt. Jedes neue Feature, jedes Plugin-Update und jede zusätzliche interaktive Komponente kann die sorgfältig aufgebaute Balance verschieben. Deshalb gehören die relevanten Metriken in ein kontinuierliches [Monitoring1: Total Blocking Time und Long-Task-Anzahl aus synthetischen Lab-Tests sowie die INP-Verteilung aus echten Nutzersitzungen. Erst die Kombination beider Perspektiven zeigt das vollständige Bild.

Synthetische Tests unter kontrollierten Bedingungen erkennen Regressionen schnell und zuverlässig, etwa wenn ein neues Drittanbieter-Skript die Hydration-Last erhöht. Real User Monitoring zeigt dagegen die tatsächliche Erfahrung auf der breiten Gerätelandschaft. Besonders aufschlussreich ist die Segmentierung nach Gerätetyp, weil mobile Nutzer mit Mittelklasse-Smartphones die Hydration-Last um ein Vielfaches stärker spüren als Desktop-Nutzer. Diese Daten lenken die Optimierung auf die Stellen mit dem größten realen Effekt.

Eine nachhaltige Strategie verankert klare Schwellenwerte in der Entwicklungs-Pipeline. Wenn die ausgelieferte JavaScript-Menge oder die Total Blocking Time eine definierte Grenze überschreitet, sollte das Team automatisch benachrichtigt werden, bevor die Änderung in Produktion gelangt. Dieser Feedback-Loop aus messen, prüfen, warnen und beheben verhindert, dass sich Hydration-Last über Wochen und Monate unbemerkt aufbaut. Wie sich daraus konkrete Obergrenzen ableiten lassen, zeigt unser Beitrag zu [JavaScript-Performance-Budgets1.