ISR im großen Maßstab: Betrieb von 25.000+ Seiten mit Incremental Static Regeneration auf Vercel

Letztes Jahr haben wir eine Next.js-Website mit über 25.000 statisch generierten Seiten auf Vercel bereitgestellt. Produktseiten, Blogbeiträge, Landing Pages für Standorte, dynamische Kategoriefilter -- das volle Programm. Das Versprechen der Incremental Static Regeneration ist verlockend: die Geschwindigkeit von statischen Websites mit der Aktualität von Server-gerenderten Inhalten. Und ehrlich gesagt? Es funktioniert größtenteils. Aber bei 25.000+ Seiten verhält sich ISR anders als bei einer 50-Seiten-Marketing-Website. Die Edge Cases werden zu deinen Hauptfällen. Die Kosten steigen. Die Cache-Invalidierungsprobleme, die in der Dokumentation theoretisch wirkten, werden sehr, sehr real.

Dies ist der Artikel, den ich mir gewünscht hätte, bevor wir anfingen. Alles hier basiert auf Produktionserfahrung -- echte Kennzahlen, echte Abrechnungsüberraschungen und echte Architekturentscheidungen, die wir getroffen haben (und manchmal bereut haben).

ISR im großen Maßstab: Betrieb von 25.000+ Seiten mit Incremental Static Regeneration auf Vercel

Inhaltsverzeichnis

Was ISR unter der Haube wirklich tut

Bevor wir auf Skalierungsprobleme eingehen, stellen wir sicher, dass wir auf der gleichen Seite sind, was ISR ist. Wenn du revalidate: 60 auf einer Next.js-Seite setzt, hier ist der tatsächliche Ablauf:

  1. Erste Anfrage nach dem Deployment: Wenn die Seite zum Zeitpunkt des Builds vorgerendert wurde, serviert Vercel sie aus dem Edge-Cache. Wenn nicht (du hast fallback: 'blocking' zurückgegeben oder dynamicParams: true in App Router verwendet), wird sie serverseitig gerendert, das Ergebnis wird gecacht und dann serviert.

  2. Nachfolgende Anfragen innerhalb des Revalidierungsfensters: Aus dem Cache serviert. Schnell. Keine Berechnung.

  3. Erste Anfrage nach Ablauf des Revalidierungsfensters: Die veraltete Seite wird sofort serviert (das ist der "stale-while-revalidate"-Teil), und eine Hintergrund-Regeneration wird ausgelöst. Der nächste Besucher erhält die aktualisierte Seite.

Das ist konzeptionell einfach. Aber bei 25.000 Seiten wird dieser Hintergrund-Regenerationsschritt zu einem Ansturm.

// App Router (Next.js 14/15)
export const revalidate = 60; // Sekunden

export async function generateStaticParams() {
  // Bei 25k Seiten möchtest du wahrscheinlich nicht alle zurückgeben
  const topPages = await getTop500Pages();
  return topPages.map((page) => ({ slug: page.slug }));
}

export default async function ProductPage({ params }: { params: { slug: string } }) {
  const product = await getProduct(params.slug);
  return <ProductTemplate product={product} />;
}

Der Stale-While-Revalidate-Kompromiss

Das, was Leute verwirrt: ISR serviert immer veraltete Inhalte für die Anfrage, die die Regeneration auslöst. Das ist ein Feature, kein Bug -- es bedeutet, dass kein Besucher je auf einen Render warten muss. Aber es bedeutet auch, dass dein Inhalt immer mindestens eine Anfrage alt ist. Für eine 25.000-Seiten-Website, auf der einige Seiten nur einmal pro Woche besucht werden, könnte "eine Anfrage alt" bedeuten, dass jemand Inhalte sieht, die Tage alt sind, nachdem das Revalidierungsfenster abgelaufen ist, weil niemand die Regeneration ausgelöst hat.

Warum 25.000 Seiten alles verändert

Im kleinen Maßstab ist ISR praktisch Magie. Im großen Maßstab ändern sich drei Dinge:

Build-Zeiten werden zum Engpass

Wenn du versuchst, alle 25.000 Seiten zum Zeitpunkt des Builds vorzurendern, sprichst du von Build-Zeiten, die dich an deinen Lebensentscheidungen zweifeln lassen. Jede Seite muss ihre Daten abrufen, React zu HTML rendern und die statischen Assets generieren. Selbst bei 200 ms pro Seite (was optimistisch ist, wenn du eine CMS-API abfragst), sind das 5.000 Sekunden -- über 83 Minuten. Der Pro-Plan von Vercel hat ein Build-Timeout von 45 Minuten. Enterprise bekommt mehr, aber du verbrennst immer noch Compute-Credits.

Cache-Invalidierung wird zum echten Problem

Bei 25.000 Seiten kannst du nicht einfach "alles neu erstellen", wenn sich Inhalte ändern. Du brauchst chirurgische Invalidierung. Die revalidatePath()- und revalidateTag()-APIs von Vercel helfen, aber sie haben im großen Maßstab ihre eigenen Eigenheiten, die wir noch behandeln werden.

Hintergrund-Regenerations-Last-Spitzen

Stell dir vor, 5.000 Seiten haben alle revalidate: 60 und erhalten alle gleichzeitig Traffic. Das sind 5.000 Serverless-Funktionsaufrufe, die jede Minute im Hintergrund passieren. Deine CMS-API sollte das bewältigen können.

ISR im großen Maßstab: Betrieb von 25.000+ Seiten mit Incremental Static Regeneration auf Vercel - Architektur

Build-Strategie: Was soll vorgerendert vs. aufgeschoben werden

Dies ist die wichtigste Architekturentscheidung für große ISR-Websites. Hier ist das Framework, das wir verwenden:

Seitenkategorie Anzahl (Unser Fall) Strategie Begründung
High-Traffic-Seiten (Top 500) 500 Beim Build vorrendern Diese werden sofort nach dem Deployment aufgerufen. Keine Cold-Start-Strafe.
Medium-Traffic-Seiten 4.500 Mit fallback: 'blocking' aufschieben Der erste Besucher wartet ~300ms, dann wird es gecacht. Akzeptabel.
Long-Tail-Seiten 20.000 Mit fallback: 'blocking' aufschieben Die meisten werden Stunden/Tage nach dem Deployment nicht besucht. Keine Sinn, vorzurendern.

Die Schlüsselerkenntnis: Rendere nicht Seiten vor, die niemand in der ersten Stunde nach dem Deployment besuchen wird. Du verschwendest Build-Minuten und Geld.

// generateStaticParams - gib nur deine High-Traffic-Seiten zurück
export async function generateStaticParams() {
  // Wir nutzen Analysedaten, um die Top-Seiten zu bestimmen
  const topPages = await fetch('https://api.example.com/pages/top?limit=500', {
    headers: { Authorization: `Bearer ${process.env.CMS_TOKEN}` },
  }).then(r => r.json());

  return topPages.map((page: { slug: string }) => ({
    slug: page.slug,
  }));
}

Mit diesem Ansatz sank unsere Build-Zeit von Timeouts auf etwa 8 Minuten. Das ist ein großer Unterschied. Wir haben ähnliche Optimierungsstrategien im Kontext unserer Next.js-Entwicklungsarbeit beschrieben -- die Prinzipien gelten breit.

Die `dynamicParams`-Einstellung ist wichtig

In App Router bedeutet das Setzen von dynamicParams = true (Standard), dass Seiten, die nicht von generateStaticParams zurückgegeben werden, bei Bedarf gerendert und gecacht werden. Das Setzen auf false gibt einen 404 für jede Seite zurück, die nicht vorgerendert wurde. Für eine 25.000-Seiten-Website möchtest du fast sicher true.

export const dynamicParams = true; // Erlaube On-Demand-Rendering für Seiten nicht in generateStaticParams

Revalidierungsmuster, die wirklich funktionieren

Zeitbasierte Revalidierung

Der einfachste Ansatz. Setze revalidate auf eine Anzahl von Sekunden. Aber welche Zahl?

Hier ist das, womit wir nach monatelanger Feinabstimmung landeten:

Inhaltstyp Revalidierungszeitraum Warum
Produktpreise 60 Sekunden Preise ändern sich häufig, Kunden bemerken veraltete Preise
Produktbeschreibungen 3600 Sekunden (1 Stunde) Selten geändert, nicht zeitempfindlich
Blogbeiträge 86400 Sekunden (24 Stunden) Fast nie geändert nach Veröffentlichung
Kategorie-/Listingseiten 300 Sekunden (5 Minuten) Neue Produkte erscheinen, aber kleine Verzögerung ist OK
Location-Seiten 86400 Sekunden (24 Stunden) Adressinformationen ändern sich kaum

Der Fehler, den wir früh machten: Alles auf 60 Sekunden setzen. Dies überlastete unsere CMS (Contentful, in unserem Fall) API mit Regenerierungsanfragen und wir trafen auf Ratenlimits während Traffic-Spitzen.

On-Demand-Revalidierung

Dies ist der bessere Ansatz für die meisten Content-Updates. Anstatt mit zeitbasierter Revalidierung zu polieren, löst du die Regeneration aus, wenn sich der Inhalt tatsächlich ändert:

// app/api/revalidate/route.ts
import { revalidateTag, revalidatePath } from 'next/cache';
import { NextRequest, NextResponse } from 'next/server';

export async function POST(request: NextRequest) {
  const secret = request.headers.get('x-revalidation-secret');
  
  if (secret !== process.env.REVALIDATION_SECRET) {
    return NextResponse.json({ error: 'Invalid secret' }, { status: 401 });
  }

  const body = await request.json();
  
  // Tag-basierte Revalidierung -- das ist der Weg
  if (body.tag) {
    revalidateTag(body.tag);
    return NextResponse.json({ revalidated: true, tag: body.tag });
  }

  // Pfadbasierte Revalidierung als Fallback
  if (body.path) {
    revalidatePath(body.path);
    return NextResponse.json({ revalidated: true, path: body.path });
  }

  return NextResponse.json({ error: 'No tag or path provided' }, { status: 400 });
}

Richte dann einen Webhook in deinem CMS ein, um diesen Endpunkt jedes Mal zu erreichen, wenn Inhalte veröffentlicht werden. Wir kombinieren dies mit einer längeren zeitbasierten Revalidierung (wie 24 Stunden) als Sicherheitsnetz.

Tag-basierte Revalidierung im großen Maßstab

Hier glänzt Next.js 14+ wirklich für große Websites. Du kannst deine Abrufanfragen taggen und nach Tag invalidieren:

async function getProduct(slug: string) {
  const res = await fetch(`https://api.cms.com/products/${slug}`, {
    next: { 
      tags: [`product-${slug}`, 'products', 'all-content'],
      revalidate: 86400 // 24 Stunden Sicherheitsnetz
    },
  });
  return res.json();
}

Jetzt wenn ein einzelnes Produkt aktualisiert wird, rufst du revalidateTag('product-blue-widget') auf und nur diese Seite regeneriert. Wenn du ein Massen-Preisupdate machst, rufst du revalidateTag('products') auf und alle Produktseiten regenerieren beim nächsten Besuch.

Der Fallstrick: Das Aufrufen von revalidateTag('products') auf einer Website mit 25.000 Produktseiten regeneriert sie nicht alle sofort. Es markiert sie alle als veraltet. Sie regenerieren beim nächsten Besuch. Das ist wichtig -- es bedeutet, dass einige Seiten möglicherweise tagelang nicht aktualisiert werden, wenn sie wenig Traffic haben.

Vercel-spezifische Fallstricke und Grenzen

Wir betreiben dies seit Anfang 2024 auf Vercel. Hier sind die Dinge, die die Dokumentation nicht genug betont:

ISR-Cache-Speicher

Vercel speichert ISR-Seiten im Edge Network-Cache. Ab 2025 hat der Vercel Data Cache einige Grenzen, die du kennen solltest:

  • Pro-Plan: Der enthaltene ISR-Cache ist großzügig, aber es gibt Kosten für Cache-Lesevorgänge/-schreibvorgänge bei sehr hohem Volumen
  • Enterprise: Benutzerdefinierte Grenzen, aber du zahlst dafür
  • Cache-Einträge bleiben nicht für immer bestehen: Selbst mit revalidate: false kann Vercel Cache-Einträge entfernen, auf die lange Zeit nicht zugegriffen wurde. Wir haben gesehen, dass Seiten nach etwa 30 Tagen ohne Traffic im Pro-Plan aus dem Cache verschwunden sind.

Serverless-Funktionsdauer

Hintergrund-Regeneration wird als Serverless-Funktion ausgeführt. Bei Vercel Pro beträgt das Standard-Timeout 60 Sekunden (du kannst bis zu 300 Sekunden konfigurieren). Wenn deine Seite länger als das braucht zum Regenerieren -- sag, weil dein CMS langsam ist oder du schwere Bildverarbeitung machst -- schlägt die Regeneration stumm fehl und die veraltete Seite wird weiterhin serviert.

Wir trafen auf dies mit Seiten, die Daten aus drei verschiedenen APIs abrufen. Die Lösung war, eine Caching-Schicht (Redis über Upstash) zwischen unserer Next.js-App und der langsamsten API hinzuzufügen.

Gleichzeitige Regenerierungsgrenzen

Vercel veröffentlicht keine Hard Numbers zu diesem Punkt, aber wir beobachteten Drosselung, wenn mehr als ~1.000 ISR-Regenerierungen gleichzeitig ausgelöst wurden (z. B. nach Aufrufen von revalidateTag auf einem weit verbreiteten Tag). Die Regenerierungen bilden eine Warteschlange und werden über mehrere Minuten statt auf einmal verarbeitet. Plane dafür.

Cold Starts

Seiten, die lange Zeit nicht besucht wurden (und aus dem Edge-Cache entfernt wurden) werden beim nächsten Besuch einen Cold Start erleben. In unseren Benchmarks:

  • Warmer Cache-Hit: 15-40 ms TTFB
  • Veraltete Revalidierung (aus Cache serviert): 15-40 ms TTFB (gleich, da veraltet serviert)
  • Kalte Regeneration (kein Cache, blockierend): 400-1200 ms TTFB je nach API-Antwortzeiten

Echte Produktionskosten im großen Maßstab

Sprechen wir über Geld. Das ist, wo Leute überrascht sind.

Unsere 25.000-Seiten-Website auf Vercel Pro ($20/Monat Base) mit ISR:

Kostenkomponente Monatlich Hinweise
Vercel Pro-Abonnement $20 Basisplan
Serverless-Funktionsausführung $180-$340 Variiert mit Traffic. ISR-Regenerierungen zählen als Funktionsaufrufe.
Edge-Bandbreite $90-$150 25k Seiten mit Bildern summiert sich
Vercel Data Cache $40-$80 Cache-Lesevorgänge/-schreibvorgänge für ISR
Vercel gesamt $330-$590/Mo Hängt von Traffic im Monat ab
Contentful (CMS) $489/Mo Ihr Team-Plan. API-Aufrufe von ISR-Regenerierung drängten uns schnell über den kostenlosen Tier hinaus.
Upstash Redis (Caching) $30/Mo Hinzugefügt, um CMS-API-Aufrufe zu reduzieren
Gesamtsumme $849-$1.109/Mo Für eine Website mit ~2 Millionen Seitenaufrufen/Monat

Ist das teuer? Im Vergleich zu einer traditionellen Server-Einrichtung ist es wettbewerbsfähig. Im Vergleich zu einer statischen Website auf einem CDN ist es teuer. Die ISR-Regenerierungsfunktionsaufrufe sind der größte variable Kostenfaktor -- jedes Mal, wenn eine Seite regeneriert, wird diese Serverless-Funktion für 1-5 Sekunden ausgeführt.

Wir haben mit Kunden zusammengearbeitet, die Astro-basierte Ansätze für inhaltsreiche Websites erkunden, wo ISRs Kosten beginnen, seinen Nutzen zu überwiegen. Für Websites, auf denen sich Inhalte selten ändern, kann ein vollständiger statischer Build mit Astro erheblich günstiger zum Hosten sein.

Monitoring und Debugging von ISR in der Produktion

ISR-Fehler sind standardmäßig stumm. Die veraltete Seite wird weiterhin serviert und möglicherweise merkst du nicht, dass deine Regeneration tagelang fehlgeschlagen hat. Hier ist unsere Monitoring-Einrichtung:

Benutzerdefinierte Regenerierungs-Protokollierung

// lib/with-regeneration-logging.ts
export async function fetchWithLogging(
  url: string,
  options: RequestInit & { next?: { tags?: string[]; revalidate?: number } }
) {
  const start = Date.now();
  try {
    const res = await fetch(url, options);
    const duration = Date.now() - start;
    
    // In deinen Monitoring-Service protokollieren
    if (duration > 5000) {
      console.warn(`[ISR] Slow fetch: ${url} took ${duration}ms`);
      // An Datadog/Sentry/etc. senden.
    }
    
    return res;
  } catch (error) {
    console.error(`[ISR] Fetch failed: ${url}`, error);
    // Das ist kritisch -- wenn Abruf fehlschlägt, schlägt Regeneration fehl
    throw error;
  }
}

Die Vercel-eigenen Tools

Das Dashboard von Vercel zeigt ISR-Cache-Hit-Raten und Regenerierungszahlen. Im Tab Analytics suche nach:

  • Cache-Status in den Funktionsprotokollen: HIT, MISS, STALE
  • ISR-Regenerierungsdauer in den Serverless-Funktionsmetriken
  • Fehlerraten auf deinen ISR-Routes

Der `x-vercel-cache`-Header

Jede Antwort von Vercel enthält diesen Header:

  • HIT -- Aus Edge-Cache serviert, frisch
  • STALE -- Aus Edge-Cache serviert, Regeneration im Hintergrund ausgelöst
  • MISS -- Nicht im Cache, bei Bedarf gerendert

Wir richteten einen einfachen Monitor ein, der stündlich 100 zufällige Seiten überprüft und alarmiert, wenn mehr als 10% MISS zurückgeben -- das würde Cache-Evictions-Probleme andeuten.

Architekturentscheidungen: ISR vs. Alternativen

Nach über einem Jahr Betrieb von ISR im großen Maßstab, hier ist meine ehrliche Einschätzung, wann ISR zu verwenden ist und wann nicht:

Verwende ISR, wenn:

  • Du 5.000-100.000 Seiten hast, die sich mit unterschiedlichen Frequenzen ändern
  • Content-Frische gemessen in Minuten (nicht Sekunden) ist akzeptabel
  • Du bereits zu Next.js verpflichtet bist
  • Dein Team versteht Cache-Invalidierung (es ist nicht optionales Wissen im großen Maßstab)

Erwäge Alternativen, wenn:

  • Du Echtzeit-Content brauchst (verwende SSR oder client-seitiges Abrufen stattdessen)
  • Deine Website selten ändert (vollständige statische Builds sind einfacher und billiger)
  • Du 500.000+ Seiten hast (ISR beginnt bei sehr hohen Seitenzahlen zu zerrütten -- erwäge einen verteilten Build-Ansatz)
  • Kosten sind die primäre Sorge (selbstgehostetes Next.js mit deinem eigenen CDN kann 60-70% günstiger sein)

Für Clients mit komplexen Content-Architekturen empfehlen wir oft ein Headless-CMS-Setup, das dir Flexibilität gibt, zwischen ISR, SSR und vollständig statisch je nach Content-Typ zu wechseln.

Der Hybrid-Ansatz, den wir tatsächlich verwenden

Wir verwenden ISR nicht für alles auf unserer 25k-Seiten-Website. Hier ist die Aufschlüsselung:

  • ISR: Produktseiten, Kategorieseiten, Standortseiten (22.000 Seiten)
  • SSR: Suchergebnisse, Benutzer-Dashboard, Warenkorb
  • Statisch: Über, Kontakt, Legal-Seiten (beim Build generiert, keine Revalidierung)
  • Client-seitig: Echtzeit-Bestandszähler, benutzerspezifische Preisgestaltung

Dieser Hybrid-Ansatz reduzierte unsere Serverless-Funktionskosten um etwa 40% im Vergleich zu unserer anfänglichen "Alles ISR"-Strategie.

Performance-Benchmarks aus unserer Bereitstellung

Hier sind echte Zahlen aus unserer Produktionsbereitstellung, gemessen über Q1 2025:

Metrik ISR Cache Hit ISR Cache Miss (Blockierend) Vollständig SSR (Kein Cache)
TTFB (p50) 22 ms 480 ms 620 ms
TTFB (p95) 58 ms 1.100 ms 1.450 ms
TTFB (p99) 120 ms 2.800 ms 3.200 ms
LCP (p50) 1,1 s 1,8 s 2,2 s
CLS 0,02 0,02 0,05
Core Web Vitals Pass Rate 96% 78% 64%

Der Unterschied zwischen einem Cache-Hit und einem Miss ist dramatisch. Das ist der Grund, warum deine Vorrenderungs-Strategie so wichtig ist -- du möchtest, dass deine High-Traffic-Seiten immer warm sind.

Eine interessante Erkenntnis: Unsere Core Web Vitals-Scores verbesserten sich um 12%, als wir von revalidate: 60 zu revalidate: 3600 bei niedrig-wechsel-Inhalten wechselten. Weniger Regenerierungen bedeuteten mehr konsistente Cache-Hits, was mehr konsistente Performance bedeutete.

FAQ

Wie viele Seiten kann ISR auf Vercel verarbeiten, bevor die Performance degradiert?

Wir haben 25.000 Seiten ohne signifikante Probleme betrieben, und ich habe von Bereitstellungen mit 100.000+ Seiten gehört, die gut funktionieren. Der Engpass ist nicht die Anzahl der Seiten im Cache -- es ist die Rate der gleichzeitigen Regenerierungen. Wenn du 50.000 Seiten alle mit revalidate: 60 hast, wirst du auf Probleme treffen. Verteile deine Revalidierungsperioden basierend auf Content-Änderungsfrequenz und du wirst OK sein.

Kostet ISR mehr als SSR auf Vercel?

Allgemein ist ISR für das gleiche Traffic-Volumen deutlich billiger als SSR. Mit ISR werden die meisten Anfragen aus dem Edge-Cache serviert (im Wesentlichen kostenlos Berechnung). Mit SSR wird jede Anfrage als Serverless-Funktion ausgeführt. Für unsere 2 Millionen Seitenaufrufe/Monat-Website waren ISRs Funktionsaufrufe (aus Regenerierungen) ungefähr 15% von dem, was vollständiges SSR gewesen wäre.

Was passiert, wenn ISR-Regeneration fehlschlägt?

Die veraltete Version wird weiterhin serviert. Das ist sowohl ein Feature als auch ein Risiko. Deine Benutzer sehen keine Fehler, aber sie könnten veraltete Inhalte sehen. Wir hatten Situationen, wo ein CMS-API-Ausfall bedeutete, dass Seiten Inhalte servieren, die 6 Stunden alt waren, bevor jemand Bescheid wusste. Richte Monitoring auf.

Kann ich ISR mit dem Next.js App Router verwenden?

Ja, und es ist eigentlich sauberer im App Router. Du verwendest export const revalidate = 60 auf der Seite oder Layout-Ebene und next: { revalidate, tags } in deinen Abrufaufrufen. Die generateStaticParams-Funktion ersetzt getStaticPaths. Alles, was wir in diesem Artikel beschrieben haben, funktioniert mit sowohl Pages Router als auch App Router, obwohl die App Router-Syntax das ist, was wir für neue Projekte in 2025 empfehlen würden.

Wie verhandle ich ISR mit dynamischen Query-Parametern?

ISR cached nur basierend auf dem URL-Pfad, nicht auf Query-Parametern. Wenn du unterschiedliche gecachte Versionen für ?color=red gegen ?color=blue brauchst, musst du aktuelle Pfadsegmente verwenden (/product/widget/red statt /product/widget?color=red) oder die Variation client-seitig handhaben. Das überraschte uns bei unserer Filterimplementierung.

Ist On-Demand-Revalidierung im großen Maßstab zuverlässig?

Größtenteils. Wir sehen gelegentliche Verzögerungen von 10-30 Sekunden zwischen Aufrufen von revalidateTag() und dem tatsächlichen Invalidieren des Cache über alle Edge-Standorte hinweg. Für 99% der Anwendungsfälle ist das OK. Wenn du sofortige globale Invalidierung brauchst, musst du möglicherweise Cache-Busting-Query-Parameter hinzufügen oder SSR für diese spezifischen Seiten verwenden.

Sollte ich Next.js selbst hosten statt Vercel für große ISR-Websites zu verwenden?

Das hängt von deinem Team ab. Selbsthosting (auf AWS zum Beispiel) gibt dir mehr Kontrolle über Cache-Verhalten und kann im großen Maßstab 50-70% billiger sein. Aber du bist verantwortlich für das Einrichten der CDN-Cache-Invalidierung, Verwalten der Build-Pipeline und Umgang mit Edge-Verteilung selbst. Wir haben Teams gesehen, die Monate damit verbrachten, zu replizieren, was Vercel dir out of the box gibt. Wenn du Optionen erkunden möchtest, kontaktiere uns -- wir haben beide getan.

Was ist das beste CMS für eine 25.000+-Seiten-ISR-Website?

Wir haben Contentful, Sanity und Hygraph im großen Maßstab verwendet. Contentful handhabet webhook-basierte Revalidierung gut, aber Ratenlimits können ein Problem sein (plane für Caching). Sanitys GROQ-Abonnements sind großartig für Echtzeit-Bewusstsein von Content-Änderungen. Hygraphs Webhook-System ist solid. Die Schlüsselanforderung ist zuverlässige Webhook-Lieferung und eine API, die Burst-Traffic von Regenerierungs-Stürmen verarbeiten kann. Überprüfe unsere Headless-CMS-Entwicklungsfähigkeiten für spezifischere Empfehlungen basierend auf deinem Content-Modell.