revalidate, On-Demand-Trigger und echte Fallstricke
Incremental Static Regeneration kombiniert die Geschwindigkeit statischer Seiten mit der Aktualität serverseitig gerenderter Inhalte, indem einzelne Seiten im Hintergrund neu generiert werden, ohne einen kompletten Rebuild auszulösen. Wer revalidate, revalidatePath und revalidateTag richtig einsetzt, vermeidet veraltete Inhalte, ohne die Cache-Vorteile zu verlieren.
Inhaltsverzeichnis
- 1. Was Incremental Static Regeneration löst
- 2. revalidate konfigurieren: Zeit- vs On-Demand-Strategie
- 3. On-Demand Revalidation mit revalidatePath und revalidateTag
- 4. Stale-While-Revalidate Verhalten im Detail
- 5. ISR und dynamische Routen mit generateStaticParams
- 6. Caching-Fallstricke bei ISR in der Praxis
- 7. ISR im Vergleich zu SSG und SSR
- 8. Monitoring und Debugging von ISR in Produktion
- 9. ISR im direkten Vergleich
- 10. Zusammenfassung
- 11. FAQ
1. Was Incremental Static Regeneration löst
Incremental Static Regeneration, kurz ISR, löst einen Zielkonflikt, der Teams vor Next.js oft zwang, sich zwischen Geschwindigkeit und Aktualität zu entscheiden. Rein statische Seiten sind extrem schnell, weil sie vorab gebaut und über ein CDN ausgeliefert werden, veralten aber, sobald sich die zugrunde liegenden Daten ändern, bis ein kompletter Rebuild läuft. Klassisches SSR liefert immer aktuelle Daten, kostet aber bei jedem Request Serverzeit. Incremental Static Regeneration verbindet beide Welten: Seiten werden wie bei SSG vorab statisch generiert, aber nach einer definierten Zeit im Hintergrund automatisch neu gebaut, ohne dass ein Nutzer auf diesen Rebuild warten muss.
Der entscheidende Vorteil von Incremental Static Regeneration gegenüber einem vollständigen Site-Rebuild ist die Granularität: Nur die tatsächlich angeforderte, veraltete Seite wird neu generiert, nicht die gesamte Website. Bei einem Onlineshop mit zehntausenden Produktseiten würde ein vollständiger Rebuild bei jeder Preisänderung Minuten oder Stunden dauern. Mit Incremental Static Regeneration wird nur die betroffene Produktseite neu gebaut, während alle anderen Seiten unverändert aus dem Cache bedient werden.
Next.js implementiert Incremental Static Regeneration über zwei komplementäre Mechanismen: eine zeitbasierte Revalidierung über den revalidate-Export, und eine ereignisgesteuerte On-Demand-Revalidierung über revalidatePath und revalidateTag. Beide Mechanismen werden in den folgenden Abschnitten im Detail behandelt und lassen sich in der Praxis auch kombinieren.
2. revalidate konfigurieren: Zeit- vs On-Demand-Strategie
Die einfachste Form von Incremental Static Regeneration ist die zeitbasierte Revalidierung über export const revalidate = 3600 in einer Server Component. Dieser Wert legt fest, dass eine Seite nach spätestens einer Stunde als veraltet gilt und beim nächsten Request im Hintergrund neu generiert wird, während der Nutzer, der die veraltete Version anfordert, sofort die noch gecachte Antwort erhält. Erst der übernächste Nutzer sieht die neu generierte Version.
Diese zeitbasierte Strategie eignet sich hervorragend für Inhalte mit vorhersehbarer Änderungsfrequenz, etwa Blogartikel, die selten nachträglich editiert werden, oder Produktkataloge mit planbaren Preisänderungen zu bestimmten Uhrzeiten. Für Inhalte, deren Änderungszeitpunkt nicht vorhersehbar ist, etwa ein Lagerbestand, der sich durch jeden Kaufabschluss ändert, ist eine reine Zeit-Strategie unzureichend: Zwischen zwei Revalidierungsintervallen können Nutzer veraltete Bestandsdaten sehen. Für solche Fälle ist On-Demand Revalidation, behandelt im nächsten Abschnitt, die bessere Wahl.