Server-Side Rendering vs. Static Site Generation: Der Vergleich
Zur Bauzeit erzeugen oder bei jeder Anfrage rendern? Der Unterschied entscheidet über Ladezeit, Betriebskosten und wie schnell Änderungen sichtbar werden.
Statische Erzeugung (SSG) baut jede Seite einmal beim Deployment und liefert danach fertige Dateien aus. Serverseitiges Rendern (SSR) erzeugt die Seite bei jeder Anfrage neu. Beides liefert fertiges HTML an den Browser — der Unterschied liegt im Zeitpunkt, und daraus folgt fast alles andere.
##Was SSG so schnell macht
Eine vorgebaute Seite kann aus einem Zwischenspeicher am Netzrand ausgeliefert werden, geografisch nahe am Nutzer, ohne dass ein Server rechnet oder eine Datenbank antwortet. Die Antwortzeit liegt dadurch typischerweise im zweistelligen Millisekundenbereich, unabhängig von der Besucherzahl. Ein Lastspitze durch einen Presseartikel ist damit kein Ereignis mehr.
Der Preis ist die Bauzeit: Bei tausenden Seiten dauert jedes Deployment entsprechend, und eine inhaltliche Änderung ist erst nach dem nächsten Bau sichtbar — sofern nicht gezielt nachgeregelt wird.
##Wann SSR die richtige Wahl ist
Sobald der Seiteninhalt vom Betrachter abhängt — angemeldeter Bereich, Warenkorb, personalisierte Preise — oder sich im Minutentakt ändert, ist SSR richtig. Ebenso bei sehr großen, sich ständig verändernden Katalogen, bei denen ein vollständiger Neubau unwirtschaftlich wäre. Der Preis sind Rechenzeit je Anfrage, laufende Serverkosten und eine Antwortzeit, die von Datenbank und Netzwerk abhängt.
- ›Blog, Leistungsseiten, Dokumentation, Landingpages — statisch.
- ›Konto, Kasse, Dashboard, Suchergebnisse — serverseitig.
- ›Produktseiten mit stabilem Inhalt und dynamischem Preis — statisch mit nachgeladenem Preisbaustein.
- ›Personalisierung nie über die ganze Seite lösen, wenn ein einzelner Baustein genügt.
Inkrementelle Regeneration (ISR) liefert statische Seiten aus und baut sie nach Ablauf einer Frist oder auf Zuruf im Hintergrund neu. Damit bekommt man die Geschwindigkeit von SSG und Aktualität nahe SSR — für die meisten Firmenwebsites die richtige Voreinstellung.
##Was das für die Redaktion bedeutet
Bei rein statischer Erzeugung ist die entscheidende Frage: Wie kommt eine Korrektur schnell live? Ohne gezielte Invalidierung wartet die Redaktion auf den nächsten Bau. Richten Sie deshalb einen Weg ein, der beim Speichern im Redaktionssystem genau die betroffenen Pfade neu bauen lässt — inklusive der Übersichts- und Feedseiten, die den Beitrag listen. Genau dieser zweite Teil wird regelmäßig vergessen, weshalb ein gelöschter Beitrag noch tagelang in der Liste steht.
##Kosten und Betrieb
Statisch: Auslieferung über ein Verteilnetz, Kosten praktisch nur für Datenvolumen, kein Server, der ausfallen kann. Serverseitig: laufende Rechenkosten, Skalierung bei Lastspitzen, Datenbankverbindungen als Engstelle, dazu ein Zwischenspeicher, den jemand verstehen und pflegen muss. Bei kleinen Projekten ist der Unterschied zweistellig im Monat, bei größeren dreistellig — und der Betriebsaufwand fällt stärker ins Gewicht als der Rechnungsbetrag.
##Wie Sie entscheiden
Gehen Sie die Seitentypen einzeln durch, nicht das Projekt als Ganzes. Moderne Frameworks erlauben pro Route eine eigene Entscheidung, und genau so sollte sie getroffen werden: statisch als Standard, serverseitig dort, wo der Inhalt vom Betrachter abhängt, und inkrementelle Regeneration für alles, was regelmäßig, aber nicht sekundengenau aktuell sein muss.
##Der versteckte Kostenfaktor: der Zwischenspeicher
Sobald mit Zwischenspeichern gearbeitet wird — und bei SSG und ISR ist das der Kern — verschiebt sich die Fehlerklasse: Nicht mehr „die Seite ist kaputt“, sondern „die Seite ist alt“. Ein zurückgezogener Beitrag, der noch ausgeliefert wird, oder ein Preis von gestern sind schwerer zu bemerken als ein Absturz, weil nichts sichtbar fehlschlägt. Deshalb gehört zu jeder statischen Auslieferung eine bewusste Antwort auf die Frage, wer wann was ungültig macht.
Praktisch heißt das: kurze Gültigkeitsdauern für HTML, lange für versionierte Dateien wie Skripte und Bilder, und ein gezielter Auffrischbefehl beim Veröffentlichen. Wer HTML mit derselben langen Dauer zwischenspeichert wie ein Bild, hat nicht ein Performanceproblem gelöst, sondern ein Redaktionsproblem geschaffen.
##Ein Vorgehen für die Migration
Wenn eine bestehende Seite umgestellt werden soll, beginnen Sie mit den Seitentypen, die den meisten Verkehr haben und sich am seltensten ändern — meist Blog und Leistungsseiten. Der Gewinn ist dort am größten und das Risiko am kleinsten. Alles, was mit Anmeldung oder Warenkorb zu tun hat, bleibt zunächst unverändert; diese Bereiche zuletzt anzufassen erspart die meisten Überraschungen im laufenden Betrieb.
Wir bauen das für Sie
Vom Artikel zur Implementierung — sprechen Sie mit uns.