Server-Side Rendering (SSR, deutsch: serverseitiges Rendering) ist ein Ansatz, bei dem der Webserver zu jeder Anfrage das fertige HTML einer Seite erzeugt und an den Browser ausliefert. Der Besucher sieht den Inhalt, sobald die Seite eintrifft – ohne dass erst JavaScript im Browser laufen muss.
Wie funktioniert SSR?
Der Browser schickt eine Anfrage an eine URL. Der Server führt die Anwendungslogik aus, liest bei Bedarf Daten aus einer Datenbank und rendert daraus eine komplette HTML-Seite. Diese Seite wird über HTTP übertragen und vom Browser direkt angezeigt.
SSR ist kein neues Konzept: Klassische Webanwendungen mit PHP, Java (JSP), ASP.NET oder Ruby on Rails arbeiten seit Jahrzehnten so. Im Kontext moderner JavaScript-Frameworks wie Next.js oder Nuxt bezeichnet SSR das Rendering derselben Komponenten auf dem Server; nach dem Laden übernimmt die Hydration – das Anbinden von Ereignissen – die interaktiven Teile. Moderne Ansätze wecken gezielt nur einzelne Komponenten auf – das beschreibt die Partial Hydration.
Vorteile und Nachteile
- Vorteile: Vollständiges HTML schon in der ersten Antwort – gut für Suchmaschinen (SEO) und schnelle erste Darstellung. Funktioniert ohne aktiviertes JavaScript, weil der Inhalt bereits im HTML steckt.
- Nachteile: Jede Anfrage kostet Server-Ressourcen, weil die Seite neu gerendert wird. Bei vielen Besuchern kann ein CDN oder Caching nötig sein, um die Last zu verteilen.
Abgrenzung zu anderen Rendering-Ansätzen
Beim Client-Side Rendering (CSR) entsteht die Seite erst im Browser; bei der Static-Site-Generation (SSG) wird sie bereits zur Buildzeit einmalig erzeugt und dann als statische Datei ausgeliefert. SSR rendert dagegen individuell und aktuell bei jedem Aufruf – der Preis dafür ist die Server-Arbeit.