Bei einem Projekt mit mehreren tausend Produktseiten bin ich an den Punkt gekommen, an dem jedes Full-Build einfach nicht mehr praktikabel war. Die Buildzeit explodierte, Deploys dauerten ewig und kleine Inhaltsänderungen führten zu nervigen Wartezeiten. In diesem Artikel teile ich meine pragmatischen Ansätze, wie du mit Next.js Incremental Static Regeneration (ISR) so einsetzen kannst, dass tausende Produktseiten schnell, konsistent und kosteneffizient bleiben — ohne jedes Mal einen kompletten Rebuild zu fahren.

Was ist das Kernproblem?

Viele Shops oder Kataloge haben eine große Anzahl statisch gerenderter Seiten. Standard-SSG generiert alle Seiten zur Buildzeit — bei ~10.000 Seiten ist das schnell unpraktisch. Du willst:

  • kurze Deploy-Zeiten
  • aktuelle Inhalte
  • skalierbare Infrastruktur

    • ISR löst das auf Papier: Seiten werden statisch ausgeliefert und nach einer revalidate-Zeit im Hintergrund regeneriert. In der Praxis treten aber Skalierungsprobleme auf, wenn du naive Strategien anwendest.

    Grundkonzept: getStaticProps + revalidate + fallback

    Meine Basis-Strategie nutzt:

  • getStaticProps mit einer revalidate-Angabe
  • fallback: 'blocking' in getStaticPaths (oder dynamische Routen ohne Pfadvorbereitung)

    • Das bedeutet: populäre Seiten kannst du beim ersten Request statisch aufbauen lassen; veraltete Seiten werden nach der revalidate-Zeit im Hintergrund erneuert. Doch das reicht oft nicht, wenn plötzlich viele Seiten gleichzeitig ihre Revalidation brauchen.

    Strategien, um Build‑Zeit‑Explosion zu vermeiden

    Hier sind die Tricks, die ich in Produktivprojekten kombiniert habe.

  • Pre-render nur eine Auswahl. Vorab werden nur die Top-N Produkte (z. B. meistbesuchte oder bestverkaufte) beim Build statisch erzeugt. Der Rest wird on-demand generiert.
  • Fallback: 'blocking' nutzen. Seiten werden beim ersten Request serverseitig erstellt und anschließend gecached.
  • Progressive Regeneration. Nicht alle Seiten gleich oft revalidieren — setze variable revalidate-Werte je nach Produkt-Änderungsfrequenz.
  • On-Demand Revalidation (Webhook). Wenn ein Produkt aktualisiert wird, sende ein Trigger an Next.js (z. B. Vercel's on-demand ISR API) und regeneriere gezielt nur diese Seite.
  • Staggered Revalidation. Vermeide, dass tausende Seiten gleichzeitig zur selben Sekunde revalidiert werden — verteile Revalidations zufällig innerhalb eines Zeitfensters.

    • On‑Demand ISR: mein bevorzugter Hebel

    Das wichtigste Tool war für mich die On-Demand-Revalidation. Workflows, die ich einsetze:

  • Beim Edit in CMS (z. B. Strapi, Contentful) triggern Webhooks eine API-Route in Next.js, die /api/revalidate aufruft.
  • Die API-Route prüft Berechtigungen und ruft Next.js' res.unstable_revalidate(path) (oder bei Vercel die dokumentierte Methode) auf.
  • So regenerierst du nur die aktualisierte Produktseite — kein Full-Build nötig.

    • Wichtig: Authentifiziere den Webhook und schütze die Revalidate-Route gegen Missbrauch. Ich hänge ein geheimes Token in den Request-Header.

    Skalierung: Locks, Queues und Idempotenz

    Wenn mehrere Updates gleichzeitig revalidiert werden, können Race-Conditions entstehen oder dein System wird überlastet. Meine Lösungen:

  • Distributed Locking: Nutze Redis/Redlock um zu verhindern, dass dieselbe Seite mehrfach parallel regeneriert wird.
  • Queue: Schicke Revalidate-Jobs in eine Queue (z. B. BullMQ, RabbitMQ). Arbeiter verarbeiten Jobs mit Rate-Limiting.
  • Coalescing: Fasse mehrere Revalidate-Anfragen für dieselbe URL zusammen — nur ein Job regeneriert die Seite.

    • CDN-Strategien

    Ein CDN ist unerlässlich, um Lastspitzen zu puffern. Ich setze auf:

  • Stale-while-revalidate und passende Cache-Control-Header — das CDN liefert sofort die alte Seite und fordert im Hintergrund eine neue Version an.
  • Edge-Caching für statische Assets und Seiten, die selten wechseln.
  • Geographische Verteilung der Revalidations: Wenn deine Infrastruktur Edge- oder Region-spezifisch ist, berücksichtige das beim Locking/Queueing.

    • Edge Functions vs. Serverless

    Bei sehr großen Projekten habe ich Edge Functions für schnelle Responses und kleinere Serverless-Funktionen für Revalidation-Logik kombiniert. Vorteile:

  • Edge: niedrige Latenz für Endnutzer.
  • Serverless: umfangreiche Hintergrundarbeiten (DB-Zugriffe, komplexe Berechnungen).

    • Je nach Anbieter (Vercel, Cloudflare Workers, Netlify) unterscheiden sich die APIs — plane diese Abhängigkeit mit ein.

    Monitoring, Metriken und Debugging

    Ohne Metriken läuft nichts. Die Hinweise, die ich regelmäßig überprüfe:

  • Anzahl Revalidate-Aufrufe pro Minute
  • Fehlerquote bei Revalidations (Timeouts, 5xx)
  • Durchschnittszeit pro Revalidation
  • Cache-Hits vs. Misses

    • Ich logge Revalidate-Jobs mit Produkt-ID, Auslöser (CMS, manuell, cron) und Dauer. Wenn die Revalidation plötzlich ausfällt, löst das sofort Alerts aus (z. B. via PagerDuty oder Slack).

    Praktische Implementierungs-Pattern

    Einige Code-/Architektur-Patterns, die sich bewährt haben:

  • Revalidate nur, wenn nötig: Prüfe beim Webhook, ob sich relevante Felder geändert haben (Preis, Verfügbarkeit, Beschreibung). Kleine oder irrelevante Änderungen vermeiden Revalidations.
  • Batch-Revalidations: Wenn ein Collection-Update viele Seiten betrifft, weise die Queue an, staggered zu verarbeiten (z. B. 50 Jobs pro Minute).
  • Soft-Publish: Änderungen zuerst als "pending" markieren, dann in einem kurzen Fenster (z. B. nachts) ausrollen.

    • Beispiele für Fallstricke

    Aus meiner Erfahrung die häufigsten Fehler:

  • Zu kurze revalidate-Zeiten für stark frequentierte Seiten ⇒ many regen-Aufrufe.
  • Unzureichende Authentifizierung der Revalidate-Endpoint ⇒ Security-Risiko.
  • Keine Locking-/Coalescing-Mechanismen ⇒ unnötige Parallel-Revalidations.
  • Vertrauen allein auf CDN ohne Beobachtung ⇒ stale-content-Probleme.

    • Praxis-Tipps aus der Arbeit

    Ein paar konkrete Maßnahmen, die mir viel Zeit gespart haben:

  • Start klein: pre-render 200 Top-Artikel, rest on-demand. Beobachte und erweitere schrittweise.
  • Verteile Revalidate-Fenster zufällig: wenn revalidate=3600s, addiere ein zufälliges Offset von 0–300s, um Thundering Herd zu vermeiden.
  • Nutze Feature Flags für neue Revalidation-Strategien — so kannst du A/B-testen, ohne alles umzuschreiben.
  • Automatisiere Backfills: Für ältere Seiten, die nie angefragt werden, plane Backfill-Jobs in ruhigen Stunden.

    • ISR in Next.js ist sehr mächtig, aber nur in Kombination mit Webhooks, Queues, Locks und CDN-Strategien wirklich skalierbar. Ich baue meine Deploy-Pipelines immer so, dass normale Inhaltsänderungen keinen Full-Build mehr auslösen — stattdessen regeln On-Demand-Revalidations und smarte Caching-Strategien die Aktualität. Wenn du möchtest, kann ich dir gern ein konkretes Revalidate-Webhook-Pattern oder ein Beispiel-Setup mit Redis-Locks und BullMQ skizzieren.