Was ist serverseitiges Rendering?

Jede Webseite muss Daten und Vorlagen in HTML verwandeln. Die Frage ist, wo diese Umwandlung stattfindet und zu welchem Zeitpunkt. Geschieht die Arbeit auf der Maschine, die die Anfrage beantwortet, bekommt der Browser ein Dokument, das die Texte, die Verweise und die Struktur bereits enthält.

Das Gegenstück ist clientseitiges Rendering. Dort liefert der Server ein nahezu leeres HTML zusammen mit einem JavaScript-Paket aus, und der Browser baut die Oberfläche erst, nachdem er diesen Code geladen und ausgeführt hat. Der Nutzer sieht bis zum Ende dieses Vorgangs eine leere Fläche, und jeder Bot, der kein JavaScript ausführt, sieht genau dasselbe.

Zwischen beiden Extremen liegt das statische Rendering, auch Prerendering genannt. Das HTML entsteht ein einziges Mal beim Bauen und wird allen Besuchen identisch ausgeliefert. Der Unterschied zum SSR liegt nicht im Ergebnis, das beim Browser ankommt, sondern im Zeitpunkt der Erzeugung: Statisch entsteht das HTML, bevor die Anfrage existiert, beim SSR entsteht es während der Anfrage. Deshalb passt statisch zu Katalogen und Dokumentation, die sich selten ändern, während SSR zu Inhalten passt, die von der Person, vom Lagerbestand oder von der Uhrzeit abhängen.

Im Deutschen stehen drei Bezeichnungen für dieselbe Sache nebeneinander: serverseitiges Rendering, Rendering auf dem Server und das englische Kürzel SSR.

Der Weg beginnt mit einer HTTP-Anfrage. Der Server nimmt die URL entgegen, löst die Route auf, fragt die nötigen Datenquellen ab und führt denselben Komponentencode aus, den sonst der Browser ausführen würde. Das Ergebnis ist eine HTML-Zeichenkette, die als Rumpf der Antwort verschickt wird.

Der Browser kann dieses HTML zeichnen, sobald es ankommt, ohne auf das JavaScript zu warten. Danach folgt die zweite Hälfte des Vorgangs: Das Client-Paket wird geladen, und die Hydration verknüpft Zustand und Ereignis-Handler mit dem bereits vorhandenen HTML. Bis die Hydration abgeschlossen ist, sieht die Seite vollständig aus, reagiert aber nicht auf Klicks.

Der Unterschied im Dokument, das über die Leitung geht, zeigt sich im Vergleich beider Fälle:

<!-- Client: das HTML kommt leer an -->
<div id="app"></div>
<script src="/bundle.js"></script>

<!-- SSR: das HTML bringt Inhalt mit -->
<div id="app">
  <h1>Trailrunning-Schuhe</h1>
  <p>Preis: 119 Euro</p>
</div>
<script src="/bundle.js"></script>

Für Suchmaschinen verläuft der Weg anders. Die Dokumentation von Google beschreibt drei aufeinanderfolgende Phasen: Crawling, Rendering und Indexierung. Seiten, die mit Status 200 antworten, kommen in eine Rendering-Warteschlange, ein Chromium ohne Oberfläche verarbeitet sie, sobald Ressourcen frei sind, und das entstandene HTML ist dasjenige, das indexiert wird. Der Text weist selbst darauf hin, dass die Wartezeit in dieser Schlange meist einige Sekunden dauert, sich aber auch länger hinziehen kann. Kommt das HTML schon vom Ursprung, ist dieser Schritt nicht mehr die schwache Stelle, denn der Inhalt steckt bereits in der ersten Antwort.

Entschieden wird hier, welche Vorlage wo erzeugt wird. Die Wahl des Frameworks ist zweitrangig. Eine Produktseite mit wechselndem Preis und wechselnder Verfügbarkeit, eine Suche mit Filtern und eine Profilseite vertragen nicht dieselbe Antwort wie ein Blogartikel.

Der erste Effekt betrifft die Indexierbarkeit. Erscheint der Hauptinhalt erst nach der Ausführung von JavaScript, hängt sein Weg in den Index davon ab, dass das Rendering ohne Zwischenfall durchläuft. Ein Skript, das scheitert, eine in robots.txt gesperrte Ressource oder ein API-Aufruf, der in den Zeitablauf läuft, hinterlassen für die Suchmaschine eine leere Seite. Wird das HTML am Ursprung gebaut, entfällt dieses Risiko.

Der zweite Effekt betrifft die Geschwindigkeit. Fertig gerenderter Inhalt bringt das erste Zeichnen nach vorn und verbessert meist den LCP, weil das Hauptelement nicht auf ein JavaScript-Paket wartet. Im Gegenzug kostet die Erzeugung des HTML bei jeder Anfrage Serverzeit und verschlechtert den TTFB gegenüber einer vorab gespeicherten statischen Antwort.

Man sollte es ohne Umschweife sagen: SSR ist kein Rankingfaktor, und es gibt keine Dokumentation, die es als solchen darstellt. Belegt ist dagegen seine Wirkung auf die Indexierbarkeit und auf die Ladekennzahlen. Diese beiden Dinge bestimmen mit, wie eine Seite in den Ergebnissen abschneidet, und darin liegt der tatsächliche Zusammenhang.

• Entscheide die Strategie je Vorlage und nicht für die ganze Website: Was sich bei jedem Besuch ändert, verlangt SSR, Stabiles darf fertig erzeugt ausgeliefert werden.
• Lege alles, was indexiert werden soll, ins erste HTML: Titel, Haupttext, interne Verweise, Canonical-Angabe und Robots-Anweisungen.
• Vergleiche das Quell-HTML mit dem gerenderten HTML im URL-Prüftool der Search Console, und zwar mit je einer Vorlage pro Seitentyp, nicht nur mit der Startseite.
• Sperre in der robots.txt keine JavaScript- und CSS-Dateien, die die Seite zum Rendern braucht.
• Setze eine Cache-Schicht vor das Rendering (CDN, Seiten-Cache oder Daten-Cache), um die Kosten beim TTFB zu begrenzen.
• Behalte die Hydration im Blick, indem du den INP misst und das ausgelieferte JavaScript reduzierst, denn eine sichtbare Seite, die nicht auf Klicks reagiert, bleibt für den Nutzer langsam.

• Annehmen, die Suchmaschine führe kein JavaScript aus. Sie tut es, aber in einer späteren Phase und abhängig von freien Ressourcen, was jeden Skriptfehler zum Risiko für fehlenden Inhalt macht.
• Bots ein anderes HTML ausliefern als der Person am Bildschirm. Ist der Unterschied erheblich, ist es keine Rendering-Entscheidung mehr, sondern Cloaking.
• SSR ohne Cache auf alle Routen anwenden und die Kosten erst später bemerken, an der Serverrechnung und an einem TTFB, der zu Spitzenzeiten steigt.
• „Das HTML kommt vollständig an“ mit „die Seite ist bereit“ verwechseln. Die Hydration kann dauern und die Interaktion mehrere Sekunden lang blockieren.
• Dynamisches Rendering dauerhaft stehen lassen. Google beschreibt es als provisorische Behelfslösung, die es nicht empfiehlt, und schlägt stattdessen serverseitiges Rendering, statisches Rendering oder Hydration vor.