Wer eine Website oder Web-App baut, steht früher oder später vor einer grundsätzlichen Frage: Wann und wo soll das HTML eigentlich entstehen? Drei Antworten haben sich etabliert und werden gern mit drei Kürzeln abgekürzt: CSR (Client-Side Rendering), SSR (Server-Side Rendering) und SSG (Static Site Generation). Sie unterscheiden sich nicht im Ergebnis – am Ende sieht der Nutzer immer eine Seite – sondern im Zeitpunkt und Ort der Erzeugung. Genau das hat aber spürbare Folgen für Ladezeit, Suchmaschinen-Sichtbarkeit, Serverkosten und die Frage, wie aktuell die Inhalte sind. Dieser Ratgeber erklärt die drei Methoden in eigenen Worten, zeigt ihre Stärken und Schwächen und hilft bei der Entscheidung für das eigene Projekt.
Was hinter den drei Kürzeln steckt
Der Kern des Unterschieds lässt sich in einem Satz zusammenfassen: Es geht darum, wo aus Daten und Vorlagen fertiges HTML wird – und wann das passiert.
- CSR – Rendering im Browser: Der Server liefert nur ein nahezu leeres HTML-Grundgerüst plus JavaScript aus. Erst im Browser des Besuchers baut das JavaScript die eigentliche Seite zusammen und holt die Inhalte per API nach. Klassisch bei Single-Page-Applications.
- SSR – Rendering auf dem Server: Bei jeder Anfrage erzeugt der Server das vollständige HTML frisch und schickt es an den Browser. Der Nutzer sieht den Inhalt sofort, JavaScript übernimmt danach nur noch die Interaktivität (Hydration).
- SSG – Rendering zur Build-Zeit: Das HTML wird bereits beim Veröffentlichen (dem "Build") einmal erzeugt und als fertige Dateien abgelegt. Jeder Besucher bekommt dieselbe vorgefertigte Datei, oft direkt aus einem CDN.
Performance und Erstladezeit
Für das gefühlte Tempo ist entscheidend, wie schnell der Besucher den ersten sinnvollen Inhalt sieht. Hier liegen statische und serverseitige Ansätze meist vorn, weil das HTML schon mitkommt. Bei CSR muss der Browser dagegen zuerst JavaScript laden, ausführen und die Daten nachholen – das kann auf schwächeren Geräten oder mit langsamer Verbindung zu einer sichtbaren Verzögerung und einem kurzen weißen Bildschirm führen.
SSG ist beim reinen Ausliefern kaum zu schlagen: Eine fertige Datei aus einem CDN landet sehr schnell beim Nutzer und belastet den Server praktisch nicht. SSR ist ebenfalls schnell beim ersten Eindruck, erzeugt aber pro Anfrage Rechenlast auf dem Server. CSR verschiebt die Arbeit auf das Endgerät – das entlastet den Server, kann aber das Erlebnis auf dem Client verlangsamen.
SEO: Was Suchmaschinen sehen
Suchmaschinen bewerten am liebsten Inhalte, die sofort im ausgelieferten HTML stehen. SSG und SSR spielen das in die Karten, weil der Text bereits vollständig vorhanden ist, wenn der Crawler die Seite abruft. Bei reinem CSR ist der erste HTML-Abruf nahezu leer; der Inhalt entsteht erst durch JavaScript. Moderne Crawler können JavaScript zwar ausführen, tun das aber oft verzögert und nicht immer zuverlässig – ein Risiko, gerade bei großen oder häufig wechselnden Seiten.
Für inhaltsgetriebene Projekte wie Blogs, Magazine, Dokumentationen oder Shops, bei denen organische Reichweite zählt, sind SSG und SSR daher in der Regel die sicherere Wahl. CSR eignet sich besser für abgeschirmte Bereiche hinter einem Login, wo SEO ohnehin keine Rolle spielt.
Aktualität und Dynamik der Inhalte
Hier zeigt sich die Kehrseite von SSG. Weil das HTML zur Build-Zeit entsteht, ist es genau so aktuell wie der letzte Build. Ändert sich der Inhalt häufig oder ist er pro Nutzer verschieden, müsste man entweder ständig neu bauen oder Teile clientseitig nachladen. Bei wenigen tausend Seiten ist ein voller Rebuild noch handhabbar, bei Millionen von Produktseiten wird er aufwendig.
SSR glänzt genau dort: Jede Anfrage kann frische, personalisierte Daten enthalten – etwa den eingeloggten Warenkorb oder tagesaktuelle Preise. CSR holt Aktualität ebenfalls problemlos nach, weil es ohnehin live mit APIs spricht; der Preis ist die schwächere Ausgangslage bei SEO und Erstladezeit.
Hybride Ansätze: ISR und partielle Hydration
In der Praxis sind die drei Methoden längst keine Entweder-oder-Entscheidung mehr. Moderne Frameworks mischen sie gezielt, um die jeweiligen Schwächen abzufedern.
- Incremental Static Regeneration (ISR): Eine Mischung aus SSG und SSR. Seiten werden statisch ausgeliefert, aber im Hintergrund nach einer festgelegten Zeitspanne oder bei Bedarf neu erzeugt. So bleibt das Tempo von SSG, ohne dass die Inhalte beliebig veralten.
- Partielle Hydration / Islands: Statt die ganze Seite mit JavaScript zu beleben, werden nur einzelne interaktive "Inseln" hydriert. Der Großteil bleibt statisches HTML, was Datenmenge und CPU-Last im Browser senkt.
- Streaming-SSR: Der Server schickt das HTML in Teilen, sobald es fertig ist, statt auf die komplette Seite zu warten – der Nutzer sieht früher etwas.
- Edge-Rendering: SSR wird nicht zentral, sondern an verteilten Standorten nahe am Nutzer ausgeführt, was die Latenz reduziert.
Viele Seiten kombinieren das ohnehin: Eine statische Startseite, serverseitig gerenderte Kategorieseiten und clientseitig nachgeladene Filter sind ein völlig üblicher Mix.
Methoden im direkten Vergleich
Die folgende Übersicht stellt die Kernunterschiede gegenüber. Die Bewertungen sind Daumenwerte für typische Projekte und keine festen Gesetze – konkrete Ergebnisse hängen stark von Umsetzung, Caching und Infrastruktur ab.
| Methode | Renderort & Zeitpunkt | SEO-Eignung | Performance (Erstladezeit) | Typischer Anwendungsfall |
|---|---|---|---|---|
| SSG | Build-Zeit, vorab erzeugt | Sehr gut | Sehr schnell (CDN) | Blogs, Doku, Marketing-Seiten, Landingpages |
| SSR | Server, pro Anfrage | Sehr gut | Schnell, aber Serverlast | Shops, personalisierte & aktuelle Inhalte |
| CSR | Browser, nach dem Laden | Eingeschränkt | Langsamer Start, flott danach | Dashboards, Web-Apps hinter Login |
| ISR (hybrid) | Build + Neuerzeugung bei Bedarf | Sehr gut | Sehr schnell | Große Kataloge mit moderater Aktualisierung |
Wie man die richtige Methode wählt
Eine pauschal beste Lösung gibt es nicht. Drei Fragen führen meist schnell zur passenden Strategie:
- Wie oft ändern sich die Inhalte? Selten und für alle gleich spricht für SSG. Ständig oder pro Nutzer verschieden spricht für SSR oder CSR.
- Wie wichtig ist organischer Traffic? Hängt die Reichweite an Google & Co., sollte der Inhalt serverseitig oder statisch im HTML stehen.
- Wie hoch ist die Personalisierung? Login-Bereiche, Warenkörbe und individuelle Ansichten brauchen dynamisches Rendering oder gezieltes Nachladen.
Eine bewährte Faustregel: So viel statisch wie möglich, so viel dynamisch wie nötig. Inhaltsseiten profitieren von SSG oder ISR, Funktionsbereiche von SSR oder CSR. Wer ein Werkzeug zum Strukturieren und Testen von Markup, JSON oder URLs sucht, findet auf der Webtools-Sammlung von kotsch.tech nützliche Helfer. Weitere Beiträge rund um Webentwicklung gibt es in den News, und einen Überblick über alle Projekte bietet die Startseite.
Häufige Fragen
Was ist der grundlegende Unterschied zwischen SSG, SSR und CSR?
Es geht um Zeitpunkt und Ort der HTML-Erzeugung. SSG baut die Seite einmalig zur Build-Zeit, SSR bei jeder Anfrage auf dem Server, CSR erst im Browser des Besuchers. Das Ergebnis sieht ähnlich aus, die Auswirkungen auf Tempo, SEO und Aktualität unterscheiden sich aber deutlich.
Welche Methode ist am besten für SEO?
SSG und SSR sind in der Regel im Vorteil, weil der Inhalt schon im ausgelieferten HTML steht und Crawler ihn sofort erfassen. Reines CSR ist riskanter, da der Inhalt erst per JavaScript entsteht und nicht immer zuverlässig indexiert wird.
Ist SSG immer die schnellste Option?
Bei der reinen Auslieferung ja, da fertige Dateien aus einem CDN sehr schnell ankommen. Der Haken: Bei häufig wechselnden oder personalisierten Inhalten wird der wiederholte Build-Aufwand groß, und manche Aktualität muss dann doch clientseitig nachgeladen werden.
Was bedeutet Hydration?
Hydration ist der Schritt, bei dem JavaScript ein bereits vorhandenes, serverseitig oder statisch erzeugtes HTML "zum Leben erweckt" und interaktiv macht – etwa Klick-Handler und dynamische Bereiche aktiviert. Partielle Hydration beschränkt das auf einzelne Komponenten, um Ressourcen zu sparen.
Kann ich mehrere Methoden in einem Projekt mischen?
Ja, das ist heute der Normalfall. Moderne Frameworks erlauben es, pro Seite oder sogar pro Komponente zu entscheiden – etwa eine statische Startseite, serverseitig gerenderte Detailseiten und clientseitig geladene Interaktionen. Hybride Verfahren wie ISR verbinden die Vorteile gezielt.
Welche Methode sollte ich für eine Web-App hinter einem Login wählen?
Für abgeschirmte Bereiche ohne SEO-Bedarf ist CSR oft eine gute Wahl, weil Interaktivität und Datenaktualität im Vordergrund stehen. Wo ein schneller erster Eindruck wichtig ist, kann auch SSR mit anschließendem clientseitigem Nachladen sinnvoll sein.