Incremental Static Regeneration in Nuxt: Statische Seiten im Hintergrund aktuell halten

1. Was Incremental Static Regeneration ist

Incremental Static Regeneration, kurz ISR, beschreibt eine Rendering-Strategie, bei der eine Seite zunächst wie eine ganz normale statische Seite ausgeliefert wird, im Hintergrund aber nach Ablauf einer festgelegten Zeitspanne automatisch neu generiert wird, sobald der nächste Nutzer sie anfragt. Der ursprungliche Nutzer, dessen Anfrage die Regeneration ausgelöst hat, bekommt dabei noch die zuvor gecachte Version ausgeliefert, während die frisch generierte Fassung erst für alle danach folgenden Anfragen greift. Das Konzept stammt ursprünglich aus dem Next.js-Ökosystem und wurde in ähnlicher Form von Nitro, der Server-Engine hinter Nuxt, übernommen.

Das eigentliche Ziel von ISR ist es, die Auslieferungsgeschwindigkeit einer vollständig vorgerenderten, statischen Seite zu behalten, ohne dabei die Aktualität komplett aufzugeben. Statt bei jeder inhaltlichen Änderung einen kompletten Neu-Build des gesamten Projekts anzustoßen, was bei tausenden Seiten mehrere Minuten dauern kann, wird nur die einzelne betroffene Seite regeneriert, sobald ihre Cache-Zeit abgelaufen ist. Das macht ISR besonders attraktiv für große Seitenbestände mit gelegentlichen, aber nicht ständigen inhaltlichen Änderungen.

2. Unterschied zu vollständigem SSG und klassischem SSR

Bei Static Site Generation, kurz SSG, werden sämtliche Seiten bereits während des Builds vollständig als HTML-Dateien erzeugt und danach unverändert ausgeliefert, bis ein neuer Build angestoßen wird. Das ergibt maximale Auslieferungsgeschwindigkeit, weil kein Server zur Laufzeit irgendetwas berechnen muss, hat aber den Nachteil, dass sich Inhalte erst nach einem neuen, vollständigen Build ändern, was bei sehr großen Projekten unpraktisch lange dauern kann.

Server-Side Rendering, kurz SSR, ist das genaue Gegenteil: jede einzelne Anfrage wird live auf dem Server gerendert, Inhalte sind dadurch immer maximal aktuell, allerdings auf Kosten von Serverlast und Antwortzeit, da für jeden Request tatsächlich Rechenarbeit anfällt. ISR positioniert sich bewusst dazwischen: Seiten werden wie bei SSG als statisches HTML ausgeliefert und dadurch schnell zugestellt, aber wie bei SSR bleibt der Inhalt nach Ablauf der Cache-Zeit automatisch aktuell, ohne dass ein manueller Rebuild nötig wäre.

3. routeRules mit isr und swr konfigurieren

In Nuxt 3 werden Rendering-Strategien pro Route zentral über das routeRules-Objekt in der nuxt.config gesteuert, statt für jede Seite einzeln Konfiguration im Code zu verteilen. Für echtes ISR mit persistentem, providerseitigem Cache trägt man bei der jeweiligen Route isr mit einer Zeitangabe in Sekunden ein, wobei zu beachten ist, dass echtes ISR im engeren Sinn nur auf Hosting-Plattformen funktioniert, die es nativ unterstützen, etwa Vercel oder Netlify Edge, während Nitro auf anderen Zielumgebungen automatisch auf eine SWR-basierte Auslieferung über den eigenen Cache-Storage zurückfällt.

Das folgende Beispiel zeigt eine typische Konfiguration für einen Shop: die Startseite wird beim Build vollständig vorgerendert, Produktseiten nutzen ISR mit fünf Minuten Gültigkeit, eine besonders traffic-starke Aktionsseite nutzt stattdessen SWR mit kürzerer Gültigkeit für schnellere Aktualisierung, während der personalisierte Account-Bereich komplett von SSR ausgenommen und clientseitig gerendert wird.

// nuxt.config.ts
export default defineNuxtConfig({
  routeRules: {
    '/': { prerender: true },
    '/produkte/**': { isr: 300 },
    '/produkte/aktion/**': { swr: 60 },
    '/account/**': { ssr: false },
    '/api/**': { cors: true }
  }
})

4. Unterschied zwischen SWR und ISR im Detail

Stale-While-Revalidate, kurz SWR, liefert bei einer Anfrage zunächst den zwischengespeicherten Wert aus dem Nitro-Storage der aktuell laufenden Server-Instanz aus und stößt parallel im Hintergrund eine Neuberechnung an, deren Ergebnis für die nächste Anfrage zur Verfügung steht. Der Cache lebt dabei typischerweise im Speicher oder im konfigurierten Storage-Treiber der jeweiligen Instanz und ist damit an deren Lebenszyklus gebunden, bei mehreren parallel laufenden Instanzen kann es deshalb kurzzeitig zu leicht unterschiedlichen Antworten kommen.

ISR im engeren Sinn geht einen Schritt weiter und persistiert die regenerierte Seite auf Plattformebene, oft direkt am CDN-Edge, sodass alle Instanzen und sogar alle Regionen denselben, konsistenten Cache-Stand sehen. Wo diese providerseitige Persistenz nicht existiert, führt Nitro isr intern als SWR-Verhalten mit demselben Zeitparameter aus, funktional ist der Unterschied für viele Projekte deshalb kleiner als der Namensunterschied vermuten lässt, wichtig bleibt aber, welches konkrete Hosting-Ziel zum Einsatz kommt.

5. Praktischer Anwendungsfall: Produktseiten mit gelegentlichen Preisänderungen

Ein klassischer Anwendungsfall für ISR sind Produktseiten in einem Onlineshop: der große Teil des Inhalts, also Beschreibung, Bilder und technische Daten, ändert sich selten, während der Preis gelegentlich, aber nicht bei jedem einzelnen Request, angepasst wird. Eine Cache-Zeit zwischen sechzig und dreihundert Sekunden ist für die meisten Shops ein guter Kompromiss, weil Preisänderungen dann innerhalb weniger Minuten sichtbar werden, während die große Mehrheit der Anfragen weiterhin aus dem Cache bedient wird.

Wichtig ist dabei, die ISR-Zeit nicht als einzige Absicherung zu betrachten, sondern sie mit der tatsächlichen Änderungsfrequenz der Preise abzugleichen: bei täglichen Preisupdates aus einem ERP-System reicht ein Zeitfenster von wenigen Minuten meist locker aus, während bei Flash-Sales mit minutengenauen Preisänderungen zusätzlich eine gezielte, manuelle Invalidierung nötig wird, die im nächsten Abschnitt beschrieben ist.

6. On-Demand-Invalidierung außerhalb des normalen Cache-Zyklus

Neben der zeitgesteuerten Regeneration unterstützt Nitro auch das gezielte Löschen einzelner Cache-Einträge über die Storage-API, sodass sich eine Seite sofort nach einer bekannten Änderung neu generieren lässt, statt auf den Ablauf der Cache-Zeit zu warten. In der Praxis löst dazu ein Webhook aus dem Backend, etwa beim Speichern eines neuen Preises im PIM oder ERP, eine eigene, geschützte Serverroute aus, die den betreffenden Cache-Eintrag per storage.removeItem entfernt.

Nach dem Entfernen des Eintrags wird die nächste eingehende Anfrage für diese Seite automatisch wieder frisch gerendert und der Cache damit neu befüllt, ganz ohne dass ein Nutzer eine veraltete Version zu sehen bekommt, die länger als nötig im Cache verbleibt. Diese Kombination aus zeitbasiertem ISR als Grundabsicherung und gezielter, ereignisgesteuerter Invalidierung für bekannte Änderungen deckt in der Praxis fast alle Anforderungen an Aktualität ab.

7. Caching-Ebenen im Zusammenspiel

In einem produktiven Setup wirken typischerweise mehrere Cache-Ebenen gleichzeitig zusammen: der Nitro-eigene Storage-Treiber, der je nach Zielumgebung Dateisystem, Redis oder ein Cloud-KV-Backend nutzen kann, eine vorgelagerte CDN-Ebene, die HTML-Antworten anhand von Cache-Control-Headern zusätzlich näher am Nutzer zwischenspeichert, sowie der Browser-Cache des Endnutzers selbst, gesteuert über dieselben oder zusätzliche Header.

Damit ISR wie erwartet funktioniert, müssen diese Ebenen aufeinander abgestimmt sein: ein CDN, das HTML-Antworten länger cacht als die konfigurierte ISR-Zeit, würde die Regeneration effektiv aushebeln, weil Anfragen den Nitro-Server gar nicht mehr erreichen. In der Praxis lohnt sich deshalb ein bewusster Blick in die Header-Konfiguration des jeweiligen Hosting-Providers, statt sich blind auf die Standardeinstellungen zu verlassen.

8. Monitoring und typische Fallstricke

Ein häufiger Fallstrick ist der sogenannte Cache-Stampede: läuft die Cache-Zeit für eine sehr populäre Seite ab und treffen kurz danach viele gleichzeitige Anfragen ein, könnten ohne geeignete Absicherung mehrere Regenerationen parallel gestartet werden und den Server unnötig belasten. Moderne Nitro-Versionen entschärfen das durch interne Locking-Mechanismen, dennoch lohnt sich bei sehr traffic-starken Seiten ein Blick auf tatsächliches Verhalten unter Last, statt sich rein auf die Theorie zu verlassen.

Ebenso wichtig ist es, ISR-Verhalten in einer Preview- oder Staging-Umgebung realistisch zu testen, da sich Hosting-Provider im Detail unterscheiden können und ein lokal im Dev-Modus getestetes Verhalten nicht zwangsläufig eins zu eins der Produktionsumgebung entspricht. Ein kurzer manueller Test nach jedem Deployment, bei dem gezielt eine Seite mit bekannter Cache-Zeit beobachtet wird, deckt solche Abweichungen frühzeitig auf.

9. Entscheidungshilfe: Wann welche Strategie sinnvoll ist

Für Inhalte, die sich praktisch nie ändern, etwa abgeschlossene Blogartikel oder rechtliche Seiten, bleibt vollständiges Prerendering beim Build die einfachste und schnellste Lösung. Für Inhalte mit gelegentlichen, aber vorhersehbaren Änderungen wie Produktpreise oder Lagerbestände ist ISR der naheliegende Mittelweg, während für stark personalisierte oder sicherheitskritische Bereiche wie den eingeloggten Account-Bereich klassisches SSR oder sogar reines Client-Side-Rendering weiterhin die richtige Wahl bleibt.

In der Praxis kombinieren die meisten größeren Nuxt-Projekte alle drei Strategien innerhalb derselben Anwendung, gesteuert über genau das routeRules-Objekt, das in diesem Artikel gezeigt wurde. Diese Granularität auf Routen-Ebene ist letztlich der größte Vorteil gegenüber einer projektweiten Entscheidung für nur eine einzige Rendering-Strategie.

10. Zusammenfassung

11. FAQ: ISR in Nuxt: Das Wichtigste auf einen Blick