Server-Side Rendering (SSR) bedeutet, dass der Server das HTML einer Seite bei jeder Anfrage selbst erzeugt und fertig an den Browser schickt, statt dem Browser nur JavaScript zum Aufbauen der Seite zu geben. web.dev definiert es als „Rendering an app on the server to send HTML, rather than JavaScript, to the client“.
Ablauf
- Der Browser ruft eine URL auf.
- Der Server holt die benötigten Daten aus Datenbank oder API.
- Er rendert die Vorlage mit den Daten zu HTML.
- Der Browser zeigt das HTML an.
- Bei Frameworks lädt danach JavaScript nach und macht die Seite interaktiv. Dieser Schritt heißt Hydration.
Vor- und Nachteile
web.dev beschreibt die Eigenschaften so: SSR liefert schnell den ersten sichtbaren Inhalt (FCP) und spart dem Browser JavaScript-Arbeit. Weil der Server für jede Anfrage rendert, steigt jedoch die Wartezeit bis zum ersten Byte (TTFB) gegenüber statisch ausgelieferten Seiten. Zwischen dem Anzeigen und der Interaktion kann außerdem eine Lücke entstehen, in der die Seite fertig aussieht, aber nicht reagiert.
Weitere Nachteile nennen Zweitquellen: höhere Serverlast und mehr Komplexität in der Entwicklung.
SSR und SEO
Das erste HTML enthält den Inhalt bereits. Suchmaschinen müssen dafür kein JavaScript ausführen. Google rät, Server-Side oder Pre-Rendering weiterhin einzusetzen, weil es die Website für Nutzer und Crawler schneller macht. Dynamic Rendering, bei dem Crawlern eine vorgerenderte Version ausgeliefert wird, bezeichnet Google als Workaround, nicht als empfohlene Lösung. Als Alternativen nennt Google Server-Side Rendering, Static Rendering und Hydration.
| Art | Wo und wann entsteht das HTML? | Inhalt schon im ausgelieferten HTML? | Einordnung durch Google |
|---|---|---|---|
| Client-Side Rendering (CSR) | im Browser per JavaScript; Daten, Templates und Routing laufen auf dem Client | nein, erst nach Ausführen von JavaScript | Google rendert Seiten mit Status 200 in einem eigenen Schritt nach dem Crawlen und empfiehlt Server-Side- oder Pre-Rendering, weil nicht alle Bots JavaScript ausführen |
| Server-Side Rendering (SSR) (dieser Begriff) | auf dem Server, bei jeder Anfrage | ja | von Google als Lösung empfohlen (statt Dynamic Rendering) |
| Static Site Generation (SSG, statisches Rendering) | beim Build; meist vorab eine HTML-Datei je URL | ja | von Google als Lösung empfohlen (statt Dynamic Rendering) |
| Incremental Static Regeneration (ISR) | beim Build vorgerendert; nach Ablauf der Revalidierungszeit erzeugt der Server die Seite im Hintergrund neu (Framework-Funktion, z. B. Next.js) | ja, aus dem Cache; bis zur Neuerzeugung wird die ältere Version ausgeliefert | keine eigene Angabe von Google |
| Prerendering | beim Build; die clientseitige App wird ausgeführt und ihr Startzustand als statisches HTML gespeichert | ja (Startzustand) | Google nennt Server-Side- oder Pre-Rendering weiterhin „eine gute Idee“, weil es Seiten für Nutzer und Crawler schneller macht |
| Dynamic Rendering | ein Rendering-Server erzeugt HTML nur für erkannte Crawler; Nutzer erhalten die clientseitig gerenderte Version | nur in der Version für Crawler | laut Google ein Workaround und keine dauerhafte Lösung; gilt nicht als Cloaking, solange Nutzer und Crawler ähnliche Inhalte sehen |
Als Ersatz für Dynamic Rendering nennt Google Server-Side Rendering, statisches Rendering und Hydration. Der ältere web.dev-Artikel „Rendering on the Web“ bezeichnet Dynamic Rendering noch als erwägenswerte Option; die Tabelle folgt der aktuellen Google-Search-Central-Doku. ISR ist kein Webstandard, die Beschreibung stammt aus der Next.js-Dokumentation. Prerendering hat im Sprachgebrauch weitere Bedeutungen; hier ist die Definition von web.dev gemeint. Quellen: web.dev: Rendering on the Web; Google Search Central: Understand JavaScript SEO basics (last updated 2026-03-04); Google Search Central: Dynamic rendering as a workaround (last updated 2025-12-10); Next.js Docs: How to implement Incremental Static Regeneration (ISR). Stand: .
Beispiel
<!-- Antwort des Servers bei SSR -->
<h1>Laufschuhe</h1>
<p>Unser Sortiment für Straße und Trail …</p>
<script src="/client.js"></script>
Bei reinem Client-Side Rendering enthielte dieselbe Antwort nur ein leeres <div id="app"></div>.
Häufige Fehler
- Wartezeit bis zum ersten Byte übersehen: Rendert der Server jede Seite bei der Anfrage, kann sich laut web.dev die TTFB erhöhen.
- Hydration-Lücke ignorieren: Die Seite sieht fertig aus, reagiert aber erst, wenn die Skripte der Komponenten geladen und die Event-Handler angehängt sind.
- Daten doppelt ausliefern: Bei SSR mit Rehydration schickt der Server die Oberfläche und zusätzlich die Quelldaten sowie eine vollständige Kopie der Implementierung. web.dev nennt das als Nachteil.
- Mit Dynamic Rendering gleichsetzen: Dynamic Rendering liefert nur erkannten Crawlern eine eigene Version. SSR liefert allen dieselbe Antwort.
Häufige Fragen
Was bedeutet Server-Side Rendering? Der Server erzeugt das HTML einer Seite und schickt es fertig zum Browser.
Ist React CSR oder SSR? Beides ist möglich. React kann im Browser rendern oder, etwa mit Next.js, auf dem Server.
Quellen
- Rendering on the Web – web.devweb.dev
- Dynamic rendering as a workaround – Google Search Centraldevelopers.google.com
- JavaScript SEO Basics – Google Search Centraldevelopers.google.com
Stand: