ISR (Incremental Static Regeneration) erklärt

Was ist ISR?

Statische Generierung (SSG) erzeugt alle Seiten beim Build als fertige HTML-Dateien. Das ist schnell und robust, hat aber einen Nachteil: Wenn sich ein Inhalt ändert, muss neu gebaut und deployt werden. Bei großen Webseiten mit tausenden Seiten oder bei Daten, die sich zwischen Deployments ändern, ist das umständlich. Server-Side Rendering löst das, indem jede Anfrage frisch gerendert wird, kostet aber Rechenzeit und Antwortgeschwindigkeit.

Incremental Static Regeneration liegt dazwischen. Seiten werden statisch ausgeliefert, aber nach einer festgelegten Zeit oder auf Anforderung erneuert Next.js sie im laufenden Betrieb. Die Next.js-Dokumentation nennt als Vorteile: statische Inhalte aktualisieren, ohne die gesamte Webseite neu zu bauen, geringere Serverlast durch vorgerenderte Seiten, automatische Cache-Control-Header und kurze Build-Zeiten bei vielen Seiten.

Wie funktioniert ISR?

Du legst für eine Seite oder Route eine Revalidierungszeit fest, zum Beispiel export const revalidate = 300 für fünf Minuten. Der Ablauf:

1. Beim Build oder bei der ersten Anfrage wird die Seite statisch erzeugt und im Cache abgelegt.
2. Alle Anfragen innerhalb der 300 Sekunden erhalten diese gecachte Version.
3. Die erste Anfrage nach Ablauf bekommt weiterhin die gecachte Seite, löst aber im Hintergrund eine Neugenerierung aus.
4. Ist die neue Version fertig, ersetzt sie den Cache; folgende Besucher sehen den neuen Stand.

Dieses Muster heißt stale-while-revalidate: Besucher warten nie auf die Erzeugung. Ergänzend lässt sich eine On-Demand-Revalidierung auslösen, etwa wenn ein Redakteur veröffentlicht. Dann wird die betroffene Seite sofort neu erzeugt, ohne das Zeitfenster abzuwarten. Seiten, die beim Build nicht vorgerendert wurden, kann Next.js bei der ersten Anfrage erzeugen und dann ebenfalls cachen.

Wann lohnt sich ISR, wann nicht?

Gut geeignet: Glossar- und Themenseiten, Studien-Auswertungen mit wiederkehrenden Daten, Referenzlisten, Produktkataloge mit seltenen Änderungen, große Archive. Hier zählt, dass die Seite schnell ausgeliefert wird und binnen Minuten aktuell ist, nicht auf die Sekunde.

Weniger geeignet: Personalisierte Seiten, Warenkörbe und alles, was pro Nutzer unterschiedlich ist. Dafür passt SSR oder clientseitige Interaktion. Sehr kleine Webseiten, die nur bei Deploy wechseln, brauchen ISR nicht. Auch bei Daten, die zwingend sofort stimmen müssen, etwa Lagerbestände mit Echtzeitanspruch, ist On-Demand-Revalidierung oder SSR die sicherere Wahl.

Welche Bedeutung hat ISR für GEO und SEO?

Crawler und KI-Abrufer erhalten bei ISR fertiges HTML, genauso wie bei SSG. Das ist gut für Extrahierbarkeit und Antwortzeiten. Zusätzlich bleiben Inhalte aktuell: Ein geänderter Preis, eine korrigierte Adresse oder eine neue Zahl in einer Studie erscheint nach kurzer Zeit, ohne dass jemand neu deployen muss. Aktualität ist ein Qualitätsmerkmal, das Assistenten bei der Auswahl von Quellen berücksichtigen können. Dazu passt, dass geänderte URLs per IndexNow gemeldet und im Sitemap-Eintrag mit Datum gepflegt werden.

Wie setzt Modern Stack ISR ein?

Unsere Glossar-, Themen- und Regionsseiten sowie die maschinenlesbaren Dateien wie llms.txt nutzen eine Revalidierung von fünf Minuten. So bleibt die Auslieferung statisch und schnell, und Änderungen an Inhalten oder Auswertungen sind kurz nach der Veröffentlichung sichtbar. Für Seiten mit klarer Versionsbindung genügt reines SSG. Wie wir die Strategien pro Seitentyp wählen, steht im Thema SSR/SSG-Stack. Die Auslieferung am Rand des Netzes erklärt Edge-Rendering.

Typische Fehler

• Zu kurze Revalidierung, sodass fast jede Anfrage neu rendert und der Vorteil entfällt.
• Personalisierte Inhalte in gecachten Seiten, die dann an falsche Nutzer gehen.
• Erwartung, dass Änderungen sofort sichtbar sind, obwohl das Zeitfenster noch läuft.
• ISR als Ersatz für ein Redaktionssystem zu betrachten.

Verwandte Themen

• SSG
• Next.js
• Vercel
• Edge-Rendering
• Webseite modernisieren
• SSR/SSG-Stack