Rendering-Strategien im Web

Was ist Server-Side Rendering?

SSR, serverseitiges Rendern

Server-Side Rendering bezeichnet das Erzeugen der fertigen HTML-Seite auf dem Server bei jeder Anfrage, sodass der Browser sofort Inhalt anzeigen kann und das JavaScript diesen erst danach interaktiv macht.

Wenn die erste Ansicht deiner Anwendung sekundenlang leer bleibt und Suchmaschinen im Quelltext nichts zu lesen finden, führt der Weg zum Rendern auf dem Server.

KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

Rendert: Bei jeder Anfrage auf dem Server
Danach: Hydration macht das HTML im Browser interaktiv
Abzuwägen gegen: Static Site Generation und Client-Rendering
Kostet: Rechenzeit und Antwortzeit pro Aufruf

Der Ablauf von der Anfrage bis zum Klick

Bei einer Anfrage führt der Server den Komponentenbaum aus, holt die nötigen Daten und schickt fertiges HTML. Der Browser zeichnet es, noch bevor das JavaScript-Bündel geladen ist. Danach läuft dieselbe Anwendung im Browser noch einmal an und übernimmt das vorhandene Markup, das ist die Hydration: Erst ab diesem Moment reagieren Klicks und Eingaben.

Zwischen Anzeige und Hydration liegt ein Fenster, in dem die Seite fertig aussieht, aber noch nicht auf Eingaben reagiert. Wer in der ersten Sekunde klickt, sieht nichts passieren. Streaming hilft dagegen, weil der Server die Seite stückweise sendet und wichtige Teile früher aktiv werden.

SSR, SSG und CSR nebeneinander

Bei der statischen Generierung entsteht das HTML einmal beim Bauen und liegt danach fertig im Ausliefernetz. Das ist die schnellste und billigste Variante, taugt aber nur, wenn der Inhalt für alle gleich ist und sich nicht ständig ändert. Für einen Ratgebertext oder eine Produktbeschreibung ist es die richtige Wahl.

SSR lohnt sich, wenn die Seite pro Anfrage anders aussieht, etwa weil sie den angemeldeten Zugang, Preise oder Verfügbarkeiten zeigt, und trotzdem indexierbar sein und schnell erscheinen soll. Der Preis ist ein Server, der bei jeder Anfrage arbeitet, mit allem, was dazugehört: Antwortzeiten, Skalierung, Caching.

Reines Client-Rendering liefert ein leeres Grundgerüst und baut alles im Browser auf. Für Anwendungen hinter einer Anmeldung, bei denen weder Suchmaschinen noch der erste Eindruck zählen, ist das völlig in Ordnung. In einem Next.js-Projekt mischst du die drei Varianten pro Route, statt dich global zu entscheiden.

Die typischen Stolpersteine

Der häufigste Fehler ist Code, der nur im Browser funktioniert und trotzdem auf dem Server ausgeführt wird. Ein Zugriff auf window oder localStorage im Rumpf einer Komponente bricht dort ab. Solche Zugriffe gehören in einen Effekt oder in eine Komponente, die ausdrücklich nur im Browser läuft.

Der zweite ist ein Hydration Mismatch: Server und Browser erzeugen unterschiedliches Markup, meist wegen Zufallswerten, Datumsformaten oder Zeitzonen. React verwirft dann das Ergebnis und baut neu auf, was den Geschwindigkeitsgewinn wieder auffrisst. Formatiere Datumsangaben deshalb mit fest gesetzter Zeitzone und Sprache.

Und schließlich das Datenholen: Wenn jede Komponente einzeln lädt, wird die Antwortzeit des Servers zur Summe aller Aufrufe. Deshalb lässt du Abfragen parallel laufen und cachst auf der Serverseite, wofür der App Router eigene Mechanismen mitbringt.

KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

Nicht verwechseln

Server-Side Rendering und was oft damit gleichgesetzt wird

Server-Side Rendering gegen Static Site Generation

SSG erzeugt HTML einmal beim Bauen, SSR bei jeder Anfrage. Dazwischen liegt die inkrementelle Neuerzeugung, bei der eine statische Seite nach einer festgelegten Zeit im Hintergrund erneuert wird.

Server-Side Rendering gegen React Server Components

Server Components laufen ausschließlich auf dem Server und schicken ihren eigenen Code nicht an den Browser. Sie sind ein Baustein, nicht dasselbe wie SSR: Auch eine Server Component kann in einer Seite stecken, die statisch erzeugt wurde.

Server-Side Rendering gegen Prerendering

Der Begriff wird für beides benutzt, gemeint ist meist das Vorabrendern zur Bauzeit. Wenn er in einer Diskussion fällt, lohnt die Rückfrage, ob Bauzeit oder Anfragezeit gemeint ist.

KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

In der Praxis

Der Server kennt weder Fenster noch Zeitzone des Besuchers

Code, der im Browser selbstverständlich ist, fällt auf dem Server sofort um. Ein Zugriff auf das Fenster-Objekt, auf den lokalen Speicher oder auf die Bildschirmbreite existiert dort nicht, und viele Bibliotheken zeigen das erst beim ersten Rendern. Solche Aufrufe gehören in den Teil, der erst nach dem Einhängen im Browser läuft.

Der zweite Klassiker ist der Unterschied zwischen dem, was der Server geschrieben hat, und dem, was der Browser daraus macht. Eine formatierte Uhrzeit, ein Zufallswert oder eine Anzeige nach Zeitzone fallen auf beiden Seiten verschieden aus, und dann wirft der Browser das gelieferte HTML weg und baut die Seite neu. Damit ist genau der Vorteil verspielt, für den du den Aufwand betrieben hast.

Jeder Aufruf kostet Rechenzeit, anders als bei vorgebauten Seiten. Für Inhalte, die sich selten ändern, lohnt sich deshalb eine Zwischenspeicherung mit einer klaren Regel, wann sie verfällt. Ohne die leistet der Server bei jedem Besuch dieselbe Arbeit ein zweites Mal.

Server-Side Rendering lernen

Wann welche Variante die richtige ist, gehen die Trainings zu React und dem App Router an einem echten Projekt durch.

Was dabei eine Ebene tiefer passiert, vom Event Loop bis zu Node.js, klären die Kurse zu JavaScript im Browser und auf dem Server .

Kurse, die Server-Side Rendering behandeln

Häufige Fragen

Brauche ich SSR für Suchmaschinen?

Nicht zwingend, aber es ist der sichere Weg. Suchmaschinen führen JavaScript inzwischen aus, das kostet allerdings Zeit und passiert nicht bei jedem Durchlauf. Für Seiten, deren Sichtbarkeit zählt, ist serverseitig erzeugtes HTML die verlässlichere Grundlage.

Wird meine Seite durch SSR schneller?

Der erste sichtbare Inhalt kommt früher, weil der Browser nicht auf das JavaScript warten muss. Die Bedienbarkeit kann sich sogar verzögern, wenn das Bündel groß ist. Deshalb lohnt der Blick auf zwei Kennzahlen: Largest Contentful Paint für den Moment, in dem der Hauptinhalt steht, und Interaction to Next Paint für die Reaktion auf Eingaben. Beide können in unterschiedliche Richtungen laufen.

Kann ich SSR und statische Seiten mischen?

Ja, und das ist der Normalfall. In Next.js entscheidest du pro Route: Die Marketingseiten liegen statisch vor, der Bereich hinter der Anmeldung wird pro Anfrage gerendert.

Persönlich für dich da