SSR, SSG oder ISR? Die passende Rendering-Strategie für Next.js

Die Rendering-Strategie beeinflusst bei Next.js nicht nur die Ladezeit. Sie entscheidet auch, wann Daten abgefragt werden, wie aktuell Inhalte sind und wie viel Arbeit zur Laufzeit anfällt. Es gibt deshalb keine einzelne Methode, die für jedes Projekt die beste ist.

Static Site Generation (SSG)

Bei der statischen Generierung wird eine Seite beim Build erstellt und anschließend als fertiges HTML ausgeliefert. Das eignet sich für Inhalte, die sich selten ändern: Leistungsseiten, Dokumentation, Marketingseiten oder redaktionelle Artikel. Die Auslieferung ist schnell und benötigt für jede Anfrage keine erneute Datenbankabfrage.

Der Nachteil: Ändern sich Inhalte, müssen sie erneut gebaut oder über einen ergänzenden Aktualisierungsmechanismus erneuert werden. Für große Websites sollte deshalb die Build-Dauer mitgedacht werden.

Server-Side Rendering (SSR)

SSR erzeugt die Seite bei einer Anfrage auf dem Server. Das ist sinnvoll, wenn Inhalt vom Benutzer, von Berechtigungen oder von aktuellen Daten abhängt. Beispiele sind personalisierte Dashboards, Kontobereiche oder Verfügbarkeitsinformationen.

Der Preis ist zusätzliche Arbeit zur Anfragezeit. Langsame Datenquellen oder aufwendige Berechnungen wirken sich direkt auf die Antwortzeit aus. Caching kann helfen, sofern es die Anforderungen an Aktualität und Datenschutz berücksichtigt.

Incremental Static Regeneration (ISR)

ISR verbindet eine statische Auslieferung mit zeit- oder ereignisbasierter Aktualisierung. Seiten können zunächst aus dem Cache kommen und danach erneuert werden. Das ist oft ein guter Kompromiss für Produktkataloge, große Content-Websites und Seiten, deren Inhalte regelmäßig, aber nicht bei jeder Anfrage geändert werden.

Die genaue Umsetzung hängt von der eingesetzten Next.js-Version und der gewählten Cache-Strategie ab. Revalidierung sollte getestet werden: Wann wird ein neuer Inhalt sichtbar? Was passiert, wenn ein Backend nicht erreichbar ist? Welche Seiten dürfen öffentlich gecacht werden?

Eine pragmatische Entscheidungshilfe

• **SSG:** Inhalte sind weitgehend unveränderlich und sollen möglichst schnell ausgeliefert werden.
• **SSR:** Die Antwort muss bei jeder Anfrage aktuelle oder benutzerspezifische Daten berücksichtigen.
• **ISR:** Inhalte dürfen zwischengespeichert werden, sollen aber ohne vollständigen Neu-Build aktualisierbar sein.

Auch innerhalb eines Projekts dürfen verschiedene Seiten unterschiedliche Strategien verwenden. Die Startseite kann statisch sein, Produktseiten können regeneriert werden und der eingeloggte Bereich kann dynamische Daten benötigen.

Was vor dem Launch gemessen werden sollte

Prüfe die Antwortzeit, den Anteil gecachter Anfragen, die Aktualität der Inhalte und die Core Web Vitals auf mobilen Geräten. Kontrolliere außerdem Canonicals, Metadaten und Fehlerzustände. Ein hoher Lighthouse-Wert ersetzt keine Prüfung der fachlichen Aktualität.

Die richtige Strategie ist die einfachste, die Aktualität, Datenschutz und Performance-Anforderungen des Produkts erfüllt.

**Über den Autor:** Casian Blanaru entwickelt mit PixelCoda performante Websites und Webanwendungen mit modernen Frontend- und CMS-Architekturen.