Caching in Next.js

Next.js verbessert die Leistung Ihrer Anwendung und reduziert Kosten durch das Caching von Rendering-Arbeiten und Datenanfragen. Diese Seite bietet einen detaillierten Einblick in die Caching-Mechanismen von Next.js, die APIs, die Sie zur Konfiguration verwenden können, und wie sie miteinander interagieren.

Gut zu wissen: Diese Seite hilft Ihnen zu verstehen, wie Next.js unter der Haube funktioniert, ist aber kein essenzielles Wissen, um mit Next.js produktiv zu sein. Die meisten Caching-Heuristiken von Next.js werden durch Ihre API-Nutzung bestimmt und haben Standardwerte für die beste Leistung mit null oder minimaler Konfiguration. Wenn Sie stattdessen direkt zu Beispielen springen möchten, beginnen Sie hier.

Übersicht

Hier ist eine hochrangige Übersicht über die verschiedenen Caching-Mechanismen und ihre Zwecke:

Standardmäßig wird Next.js so viel wie möglich cachen, um die Leistung zu verbessern und die Kosten zu reduzieren. Das bedeutet, dass Routen statisch gerendert und Datenanfragen gecacht werden, es sei denn, Sie entscheiden sich dagegen. Das folgende Diagramm zeigt das Standard-Caching-Verhalten: wenn eine Route zur Build-Zeit statisch gerendert wird und wenn eine statische Route zum ersten Mal besucht wird.

Das Caching-Verhalten ändert sich je nachdem, ob die Route statisch oder dynamisch gerendert wird, Daten gecacht oder nicht gecacht sind und ob eine Anfrage Teil eines ersten Besuchs oder einer nachfolgenden Navigation ist. Abhängig von Ihrem Anwendungsfall können Sie das Caching-Verhalten für einzelne Routen und Datenanfragen konfigurieren.

Request Memoization

Next.js erweitert die fetch-API, um Anfragen mit derselben URL und denselben Optionen automatisch zu memoizen. Das bedeutet, dass Sie eine fetch-Funktion für dieselben Daten an mehreren Stellen in einem React-Komponentenbaum aufrufen können, während sie nur einmal ausgeführt wird.

Wenn Sie beispielsweise dieselben Daten in einer Route verwenden müssen (z.B. in einem Layout, einer Seite und mehreren Komponenten), müssen Sie die Daten nicht oben im Baum abfragen und zwischen Komponenten weitergeben. Stattdessen können Sie die Daten in den Komponenten abfragen, die sie benötigen, ohne sich Gedanken über die Leistungsauswirkungen mehrerer Anfragen für dieselben Daten über das Netzwerk machen zu müssen.

async function getItem() {
  // Die `fetch`-Funktion wird automatisch memoized und das Ergebnis
  // wird gecacht
  const res = await fetch('https://.../item/1')
  return res.json()
}

// Diese Funktion wird zweimal aufgerufen, aber nur beim ersten Mal ausgeführt
const item = await getItem() // cache MISS

// Der zweite Aufruf könnte überall in Ihrer Route erfolgen
const item = await getItem() // cache HIT

Wie Request Memoization funktioniert

• Während das Rendering einer Route läuft, wird beim ersten Aufruf einer bestimmten Anfrage das Ergebnis nicht im Speicher sein, und es wird ein Cache-MISS auftreten.
• Daher wird die Funktion ausgeführt, und die Daten werden von der externen Quelle abgerufen, und das Ergebnis wird im Speicher gespeichert.
• Nachfolgende Funktionsaufrufe derselben Anfrage im selben Rendering-Durchlauf werden ein Cache-HIT sein, und die Daten werden aus dem Speicher zurückgegeben, ohne die Funktion erneut auszuführen.
• Sobald die Route gerendert wurde und der Rendering-Durchlauf abgeschlossen ist, wird der Speicher "zurückgesetzt", und alle Memoization-Einträge werden gelöscht.

Gut zu wissen:

• Request Memoization ist ein React-Feature, kein Next.js-Feature. Es ist hier enthalten, um zu zeigen, wie es mit anderen Caching-Mechanismen interagiert.
• Memoization gilt nur für die GET-Methode in fetch-Anfragen.
• Memoization gilt nur für den React-Komponentenbaum, das bedeutet:
  • Es gilt für fetch-Anfragen in generateMetadata, generateStaticParams, Layouts, Seiten und anderen Server-Komponenten.
  • Es gilt nicht für fetch-Anfragen in Route Handlers, da diese nicht Teil des React-Komponentenbaums sind.
• Für Fälle, in denen fetch nicht geeignet ist (z.B. einige Datenbank-Clients, CMS-Clients oder GraphQL-Clients), können Sie die React cache-Funktion verwenden, um Funktionen zu memoizen.

Dauer

Der Cache hält für die Lebensdauer einer Server-Anfrage, bis der React-Komponentenbaum das Rendering abgeschlossen hat.

Revalidierung

Da die Memoization nicht über Server-Anfragen hinweg geteilt wird und nur während des Renderings gilt, ist keine Revalidierung erforderlich.

Deaktivierung

Memoization gilt nur für die GET-Methode in fetch-Anfragen, andere Methoden wie POST und DELETE werden nicht memoized. Dieses Standardverhalten ist eine React-Optimierung, und wir empfehlen nicht, es zu deaktivieren.

Um individuelle Anfragen zu verwalten, können Sie die signal-Eigenschaft von AbortController verwenden. Dies deaktiviert jedoch nicht die Memoization von Anfragen, sondern bricht laufende Anfragen ab.

const { signal } = new AbortController()
fetch(url, { signal })

Data Cache

Next.js verfügt über einen integrierten Data Cache, der das Ergebnis von Datenabfragen über eingehende Server-Anfragen und Deployments hinweg persistent speichert. Dies ist möglich, weil Next.js die native fetch-API erweitert, um jeder Server-Anfrage zu ermöglichen, ihre eigenen persistenten Caching-Semantiken festzulegen.

Gut zu wissen: Im Browser gibt die cache-Option von fetch an, wie eine Anfrage mit dem HTTP-Cache des Browsers interagiert. In Next.js gibt die cache-Option an, wie eine serverseitige Anfrage mit dem Data Cache des Servers interagiert.

Sie können die cache- und next.revalidate-Optionen von fetch verwenden, um das Caching-Verhalten zu konfigurieren.

Wie der Data Cache funktioniert

• Wenn eine fetch-Anfrage mit der Option 'force-cache' während des Renderings zum ersten Mal aufgerufen wird, prüft Next.js den Data Cache auf eine gecachte Antwort.
• Wenn eine gecachte Antwort gefunden wird, wird sie sofort zurückgegeben und memoized.
• Wenn keine gecachte Antwort gefunden wird, wird die Anfrage an die Datenquelle gesendet, das Ergebnis im Data Cache gespeichert und memoized.
• Für nicht gecachte Daten (z.B. keine cache-Option definiert oder { cache: 'no-store' }) wird das Ergebnis immer von der Datenquelle abgerufen und memoized.
• Unabhängig davon, ob die Daten gecacht oder nicht gecacht sind, werden die Anfragen immer memoized, um doppelte Anfragen für dieselben Daten während eines React-Rendering-Durchlaufs zu vermeiden.

Unterschiede zwischen Data Cache und Request Memoization

Während beide Caching-Mechanismen die Leistung durch die Wiederverwendung gecachter Daten verbessern, ist der Data Cache persistent über eingehende Anfragen und Deployments hinweg, während Memoization nur für die Lebensdauer einer Anfrage gilt.

Dauer

Der Data Cache ist persistent über eingehende Anfragen und Deployments hinweg, es sei denn, Sie revalidieren oder deaktivieren ihn.

Revalidierung

Gecachte Daten können auf zwei Arten revalidiert werden:

• Zeitbasierte Revalidierung: Revalidieren Sie Daten nach einem bestimmten Zeitintervall und einer neuen Anfrage. Dies ist nützlich für Daten, die sich selten ändern und bei denen Aktualität nicht so kritisch ist.
• On-Demand-Revalidierung: Revalidieren Sie Daten basierend auf einem Ereignis (z.B. Formularübermittlung). On-Demand-Revalidierung kann einen tag- oder pfadbasierten Ansatz verwenden, um Gruppen von Daten gleichzeitig zu revalidieren. Dies ist nützlich, wenn Sie sicherstellen möchten, dass die neuesten Daten so schnell wie möglich angezeigt werden (z.B. wenn Inhalte aus Ihrem Headless-CMS aktualisiert werden).

Zeitbasierte Revalidierung

Um Daten in regelmäßigen Abständen zu revalidieren, können Sie die next.revalidate-Option von fetch verwenden, um die Lebensdauer einer Ressource im Cache (in Sekunden) festzulegen.

// Höchstens jede Stunde revalidieren
fetch('https://...', { next: { revalidate: 3600 } })

Alternativ können Sie Route Segment Config-Optionen verwenden, um alle fetch-Anfragen in einem Segment zu konfigurieren oder für Fälle, in denen Sie fetch nicht verwenden können.

Wie zeitbasierte Revalidierung funktioniert

• Wenn eine fetch-Anfrage mit revalidate zum ersten Mal aufgerufen wird, werden die Daten von der externen Datenquelle abgerufen und im Data Cache gespeichert.
• Alle Anfragen, die innerhalb des angegebenen Zeitrahmens (z.B. 60 Sekunden) aufgerufen werden, geben die gecachten Daten zurück.
• Nach dem Zeitraum gibt die nächste Anfrage immer noch die gecachten (jetzt veralteten) Daten zurück.
  • Next.js löst eine Hintergrund-Revalidierung der Daten aus.
  • Sobald die Daten erfolgreich abgerufen wurden, aktualisiert Next.js den Data Cache mit den frischen Daten.
  • Wenn die Hintergrund-Revalidierung fehlschlägt, bleiben die vorherigen Daten unverändert.

Dies ähnelt dem Verhalten von stale-while-revalidate.

On-Demand-Revalidierung

Daten können on-demand durch Pfad (revalidatePath) oder Cache-Tag (revalidateTag) revalidiert werden.

Wie On-Demand-Revalidierung funktioniert

• Wenn eine fetch-Anfrage zum ersten Mal aufgerufen wird, werden die Daten von der externen Datenquelle abgerufen und im Data Cache gespeichert.
• Wenn eine On-Demand-Revalidierung ausgelöst wird, werden die entsprechenden Cache-Einträge aus dem Cache entfernt.
  • Dies unterscheidet sich von der zeitbasierten Revalidierung, bei der die veralteten Daten im Cache bleiben, bis die frischen Daten abgerufen werden.
• Wenn die nächste Anfrage erfolgt, wird es wieder ein Cache-MISS sein, und die Daten werden von der externen Datenquelle abgerufen und im Data Cache gespeichert.

Deaktivierung

Wenn Sie die Antwort von fetch nicht cachen möchten, können Sie Folgendes tun:

let data = await fetch('https://api.vercel.app/blog', { cache: 'no-store' })

Full Route Cache

Verwandte Begriffe:

Sie können auf die Begriffe Automatic Static Optimization, Static Site Generation oder Static Rendering stoßen, die synonym verwendet werden, um den Prozess des Renderns und Cachens von Routen Ihrer Anwendung zur Build-Zeit zu beschreiben.

Next.js rendert und cached Routen automatisch zur Build-Zeit. Dies ist eine Optimierung, die es ermöglicht, die gecachte Route statt auf dem Server für jede Anfrage zu rendern, was zu schnelleren Seitenladezeiten führt.

Um zu verstehen, wie der Full Route Cache funktioniert, ist es hilfreich, sich anzuschauen, wie React das Rendering behandelt und wie Next.js das Ergebnis cached:

1. React-Rendering auf dem Server

Auf dem Server verwendet Next.js React-APIs, um das Rendering zu orchestrieren. Die Rendering-Arbeit wird in Chunks aufgeteilt: nach einzelnen Routensegmenten und Suspense-Grenzen.

Jeder Chunk wird in zwei Schritten gerendert:

1. React rendert Server-Komponenten in ein spezielles Datenformat, das für Streaming optimiert ist, den sogenannten React Server Component Payload.
2. Next.js verwendet den React Server Component Payload und Client-Komponenten-JavaScript-Anweisungen, um HTML auf dem Server zu rendern.

Das bedeutet, dass wir nicht warten müssen, bis alles gerendert ist, bevor wir die Arbeit cachen oder eine Antwort senden. Stattdessen können wir eine Antwort streamen, während die Arbeit abgeschlossen wird.

Was ist der React Server Component Payload?

Der React Server Component Payload ist eine kompakte binäre Darstellung des gerenderten React Server Components-Baums. Er wird von React auf dem Client verwendet, um den DOM des Browsers zu aktualisieren. Der React Server Component Payload enthält:

• Das gerenderte Ergebnis von Server-Komponenten
• Platzhalter für Client-Komponenten und Referenzen zu ihren JavaScript-Dateien
• Alle Props, die von einer Server-Komponente an eine Client-Komponente übergeben werden

Weitere Informationen finden Sie in der Server-Komponenten-Dokumentation.

2. Next.js-Caching auf dem Server (Full Route Cache)

Das Standardverhalten von Next.js ist, das gerenderte Ergebnis (React Server Component Payload und HTML) einer Route auf dem Server zu cachen. Dies gilt für statisch gerenderte Routen zur Build-Zeit oder während der Revalidierung.

3. React-Hydration und Reconciliation auf dem Client

Zur Anfragezeit auf dem Client:

1. Das HTML wird verwendet, um sofort eine schnelle, nicht-interaktive erste Vorschau der Client- und Server-Komponenten anzuzeigen.
2. Der React Server Components Payload wird verwendet, um den Client- und gerenderten Server-Komponentenbaum abzugleichen und den DOM zu aktualisieren.
3. Die JavaScript-Anweisungen werden verwendet, um Client-Komponenten zu hydrieren und die Anwendung interaktiv zu machen.

4. Next.js-Caching auf dem Client (Router Cache)

Der React Server Component Payload wird im clientseitigen Router Cache gespeichert - einem separaten In-Memory-Cache, der nach einzelnen Routensegmenten aufgeteilt ist. Dieser Router Cache wird verwendet, um das Navigationserlebnis zu verbessern, indem zuvor besuchte Routen gespeichert und zukünftige Routen vorab abgerufen werden.

5. Nachfolgende Navigationen

Bei nachfolgenden Navigationen oder während des Prefetching prüft Next.js, ob der React Server Components Payload im Router Cache gespeichert ist. Wenn ja, wird eine neue Anfrage an den Server übersprungen.

Wenn die Routensegmente nicht im Cache sind, holt Next.js den React Server Components Payload vom Server und füllt den Router Cache auf dem Client.

Statisches und dynamisches Rendering

Ob eine Route zum Build-Zeitpunkt zwischengespeichert wird oder nicht, hängt davon ab, ob sie statisch oder dynamisch gerendert wird. Statische Routen werden standardmäßig gecacht, während dynamische Routen zur Laufzeit gerendert und nicht zwischengespeichert werden.

Dieses Diagramm zeigt den Unterschied zwischen statisch und dynamisch gerenderten Routen mit gecachten und ungecachten Daten:

Erfahren Sie mehr über statisches und dynamisches Rendering.

Dauer

Standardmäßig ist der Full Route Cache persistent. Das bedeutet, dass das Rendering-Ergebnis über Benutzeranfragen hinweg zwischengespeichert wird.

Invalidierung

Es gibt zwei Möglichkeiten, den Full Route Cache zu invalidieren:

• Daten-Revalidierung: Durch Revalidierung des Data Cache wird auch der Router Cache invalidiert, indem Komponenten auf dem Server neu gerendert und das neue Rendering-Ergebnis zwischengespeichert wird.
• Neue Bereitstellung: Im Gegensatz zum Data Cache, der über Bereitstellungen hinweg bestehen bleibt, wird der Full Route Cache bei neuen Bereitstellungen gelöscht.

Opt-out

Sie können den Full Route Cache deaktivieren, d.h. Komponenten für jede eingehende Anfrage dynamisch rendern, indem Sie:

• Eine dynamische API verwenden: Dies deaktiviert den Full Route Cache für die Route und rendert sie dynamisch zur Laufzeit. Der Data Cache kann weiterhin genutzt werden.
• Die Route-Segment-Konfigurationsoptionen dynamic = 'force-dynamic' oder revalidate = 0 verwenden: Dies überspringt sowohl den Full Route Cache als auch den Data Cache. Das bedeutet, Komponenten werden bei jeder eingehenden Serveranfrage neu gerendert und Daten abgerufen. Der Router Cache gilt weiterhin, da es sich um einen Client-seitigen Cache handelt.
• Den Data Cache deaktivieren: Wenn eine Route eine fetch-Anfrage enthält, die nicht gecacht wird, wird die Route aus dem Full Route Cache ausgeschlossen. Die Daten für diese spezifische fetch-Anfrage werden bei jeder eingehenden Anfrage abgerufen. Andere fetch-Anfragen, die das Caching nicht deaktivieren, bleiben im Data Cache zwischengespeichert. Dies ermöglicht eine Mischung aus gecachten und ungecachten Daten.

Client-seitiger Router Cache

Next.js verfügt über einen speicherinternen Client-seitigen Router Cache, der das RSC-Payload (React Server Component) von Routensegmenten speichert, aufgeteilt nach Layouts, Ladezuständen und Seiten.

Wenn ein Benutzer zwischen Routen navigiert, speichert Next.js die besuchten Routensegmente zwischen und prefetched die Routen, zu denen der Benutzer wahrscheinlich navigieren wird. Dies führt zu sofortigem Vor-/Zurück-Navigieren, keinem vollständigen Seitenneuladen zwischen Navigationen und der Beibehaltung des React- und Browser-Zustands.

Mit dem Router Cache:

• Layouts werden zwischengespeichert und bei Navigation wiederverwendet (partielles Rendering).
• Ladezustände werden zwischengespeichert und bei Navigation für sofortige Navigation wiederverwendet.
• Seiten werden standardmäßig nicht zwischengespeichert, aber bei Browser-Vor- und Zurück-Navigation wiederverwendet. Sie können das Caching für Seiten-Segmente durch die experimentelle staleTimes-Konfigurationsoption aktivieren.

Wichtig zu wissen: Dieser Cache gilt speziell für Next.js und Server Components und unterscheidet sich vom bfcache des Browsers, obwohl er ähnliche Ergebnisse liefert.

Dauer

Der Cache wird im temporären Speicher des Browsers gespeichert. Zwei Faktoren bestimmen, wie lange der Router Cache bestehen bleibt:

• Sitzung: Der Cache bleibt über Navigationen hinweg bestehen. Er wird jedoch beim Seitenneuladen gelöscht.
• Automatischer Invalidierungszeitraum: Der Cache für Layouts und Ladezustände wird nach einer bestimmten Zeit automatisch invalidiert. Die Dauer hängt davon ab, wie die Ressource geprefetched wurde und ob die Ressource statisch generiert wurde:
  • Standard-Prefetching (prefetch={null} oder nicht angegeben): nicht gecacht für dynamische Seiten, 5 Minuten für statische Seiten.
  • Vollständiges Prefetching (prefetch={true} oder router.prefetch): 5 Minuten für statische und dynamische Seiten.

Während ein Seitenneuladen alle zwischengespeicherten Segmente löscht, betrifft der automatische Invalidierungszeitraum nur das einzelne Segment ab dem Zeitpunkt des Prefetchings.

Wichtig zu wissen: Die experimentelle staleTimes-Konfigurationsoption kann verwendet werden, um die oben genannten automatischen Invalidierungszeiten anzupassen.

Invalidierung

Es gibt zwei Möglichkeiten, den Router Cache zu invalidieren:

• In einer Server Action:
  • Daten-On-Demand-Revalidierung nach Pfad mit (revalidatePath) oder nach Cache-Tag mit (revalidateTag)
  • Die Verwendung von cookies.set oder cookies.delete invalidiert den Router Cache, um zu verhindern, dass Routen, die Cookies verwenden, veraltet werden (z.B. Authentifizierung).
• Der Aufruf von router.refresh invalidiert den Router Cache und stellt eine neue Anfrage an den Server für die aktuelle Route.

Opt-out

Ab Next.js 15 sind Seiten-Segmente standardmäßig deaktiviert.

Wichtig zu wissen: Sie können auch das Prefetching deaktivieren, indem Sie die prefetch-Prop der <Link>-Komponente auf false setzen.

Cache-Interaktionen

Bei der Konfiguration der verschiedenen Caching-Mechanismen ist es wichtig zu verstehen, wie sie miteinander interagieren:

Data Cache und Full Route Cache

• Die Revalidierung oder Deaktivierung des Data Cache wird den Full Route Cache invalidieren, da das Rendering-Ergebnis von den Daten abhängt.
• Die Invalidierung oder Deaktivierung des Full Route Cache betrifft nicht den Data Cache. Sie können eine Route dynamisch rendern, die sowohl gecachte als auch ungecachte Daten enthält. Dies ist nützlich, wenn der größte Teil Ihrer Seite gecachte Daten verwendet, Sie aber einige Komponenten haben, die von Daten abhängen, die zur Laufzeit abgerufen werden müssen. Sie können dynamisch rendern, ohne sich um die Leistungsauswirkungen des erneuten Abrufs aller Daten sorgen zu müssen.

Data Cache und Client-seitiger Router Cache

• Um den Data Cache und Router Cache sofort zu invalidieren, können Sie revalidatePath oder revalidateTag in einer Server Action verwenden.
• Die Revalidierung des Data Cache in einem Route Handler wird nicht sofort den Router Cache invalidieren, da der Route Handler nicht an eine bestimmte Route gebunden ist. Das bedeutet, der Router Cache wird weiterhin das vorherige Payload bereitstellen, bis ein Hard Refresh durchgeführt wird oder der automatische Invalidierungszeitraum abgelaufen ist.

APIs

Die folgende Tabelle gibt einen Überblick darüber, wie verschiedene Next.js-APIs das Caching beeinflussen:

<Link>

Standardmäßig prefetched die <Link>-Komponente automatisch Routen aus dem Full Route Cache und fügt das React Server Component Payload zum Router Cache hinzu.

Um das Prefetching zu deaktivieren, können Sie die prefetch-Prop auf false setzen. Dies überspringt den Cache jedoch nicht dauerhaft, das Routensegment wird client-seitig weiterhin zwischengespeichert, wenn der Benutzer die Route besucht.

Erfahren Sie mehr über die <Link>-Komponente.

router.prefetch

Die prefetch-Option des useRouter-Hooks kann verwendet werden, um manuell eine Route zu prefetchen. Dies fügt das React Server Component Payload zum Router Cache hinzu.

Siehe die useRouter-Hook-API-Referenz.

router.refresh

Die refresh-Option des useRouter-Hooks kann verwendet werden, um manuell eine Route zu aktualisieren. Dies löscht den Router Cache vollständig und stellt eine neue Anfrage an den Server für die aktuelle Route. refresh beeinflusst nicht den Data oder Full Route Cache.

Das gerenderte Ergebnis wird auf dem Client abgeglichen, während der React- und Browser-Zustand erhalten bleibt.

Siehe die useRouter-Hook-API-Referenz.

fetch

Von fetch zurückgegebene Daten werden nicht automatisch im Data Cache zwischengespeichert.

Das Standard-Caching-Verhalten von fetch (z.B. wenn die cache-Option nicht angegeben ist) entspricht dem Setzen der cache-Option auf no-store:

let data = await fetch('https://api.vercel.app/blog', { cache: 'no-store' })

Siehe die fetch-API-Referenz für weitere Optionen.

fetch options.cache

Sie können einzelne fetch-Aufrufe durch Setzen der cache-Option auf force-cache in das Caching einbeziehen:

// Caching aktivieren
fetch(`https://...`, { cache: 'force-cache' })

Siehe die fetch-API-Referenz für weitere Optionen.

fetch options.next.revalidate

Sie können die next.revalidate-Option von fetch verwenden, um den Revalidierungszeitraum (in Sekunden) für einen einzelnen fetch-Aufruf festzulegen. Dies revalidiert den Data Cache, was wiederum den Full Route Cache revalidiert. Frische Daten werden abgerufen und Komponenten auf dem Server neu gerendert.

// Höchstens nach 1 Stunde revalidieren
fetch(`https://...`, { next: { revalidate: 3600 } })

Siehe die fetch-API-Referenz für weitere Optionen.

fetch options.next.tags und revalidateTag

Next.js verfügt über ein Cache-Tagging-System für feingranulare Daten-Caching und -Revalidierung.

1. Bei Verwendung von fetch oder unstable_cache haben Sie die Möglichkeit, Cache-Einträge mit einem oder mehreren Tags zu versehen.
2. Anschließend können Sie revalidateTag aufrufen, um die mit diesem Tag verknüpften Cache-Einträge zu löschen.

Beispielsweise können Sie beim Abrufen von Daten ein Tag setzen:

// Daten mit einem Tag cachen
fetch(`https://...`, { next: { tags: ['a', 'b', 'c'] } })

Dann können Sie revalidateTag mit einem Tag aufrufen, um den Cache-Eintrag zu löschen:

// Einträge mit einem bestimmten Tag revalidieren
revalidateTag('a')

Es gibt zwei Orte, an denen Sie revalidateTag verwenden können, abhängig davon, was Sie erreichen möchten:

1. Route Handlers - um Daten als Reaktion auf ein externes Ereignis (z.B. Webhook) zu revalidieren. Dies invalidiert den Router Cache nicht sofort, da der Route Handler nicht an eine bestimmte Route gebunden ist.
2. Server Actions - um Daten nach einer Benutzeraktion (z.B. Formularübermittlung) zu revalidieren. Dies invalidiert den Router Cache für die zugehörige Route.

revalidatePath

revalidatePath ermöglicht es Ihnen, manuell Daten zu revalidieren und die Routensegmente unter einem bestimmten Pfad in einem einzigen Vorgang neu zu rendern. Der Aufruf der revalidatePath-Methode revalidiert den Data Cache, was wiederum den Full Route Cache invalidert.

revalidatePath('/')

Es gibt zwei Orte, an denen Sie revalidatePath verwenden können, abhängig davon, was Sie erreichen möchten:

1. Route Handlers - um Daten als Reaktion auf ein externes Ereignis (z.B. Webhook) zu revalidieren.
2. Server Actions - um Daten nach einer Benutzerinteraktion (z.B. Formularübermittlung, Klicken eines Buttons) zu revalidieren.

Siehe die revalidatePath-API-Referenz für weitere Informationen.

revalidatePath vs. router.refresh:

Der Aufruf von router.refresh löscht den Router Cache und rendert Routensegmente auf dem Server neu, ohne den Data Cache oder den Full Route Cache zu invalidieren.

Der Unterschied besteht darin, dass revalidatePath den Data Cache und Full Route Cache löscht, während router.refresh() den Data Cache und Full Route Cache nicht ändert, da es sich um eine Client-seitige API handelt.

Dynamische APIs

Dynamische APIs wie cookies und headers sowie die searchParams-Prop in Pages hängen von Laufzeitinformationen der eingehenden Anfrage ab. Ihre Verwendung deaktiviert den Full Route Cache für eine Route, d.h. die Route wird dynamisch gerendert.

cookies

Die Verwendung von cookies.set oder cookies.delete in einer Server Action invalidiert den Router Cache, um zu verhindern, dass Routen, die Cookies verwenden, veraltet werden (z.B. um Authentifizierungsänderungen widerzuspiegeln).

Siehe die cookies-API-Referenz.

Konfigurationsoptionen für Segmente

Die Konfigurationsoptionen für Routen-Segmente können verwendet werden, um die Standardeinstellungen eines Routen-Segments zu überschreiben oder wenn die fetch-API nicht genutzt werden kann (z.B. bei Datenbank-Clients oder Bibliotheken von Drittanbietern).

Die folgenden Konfigurationsoptionen für Routen-Segmente deaktivieren den Full Route Cache:

• const dynamic = 'force-dynamic'

Diese Konfigurationsoption deaktiviert den Data Cache für alle Fetch-Aufrufe (d.h. no-store):

• const fetchCache = 'default-no-store'

Weitere erweiterte Optionen finden Sie unter fetchCache.

Weitere Optionen finden Sie in der Dokumentation zur Route Segment Config.

generateStaticParams

Für dynamische Segmente (z.B. app/blog/[slug]/page.js) werden die von generateStaticParams bereitgestellten Pfade zum Build-Zeitpunkt im Full Route Cache gespeichert. Zur Laufzeit werden auch Pfade, die zum Build-Zeitpunkt nicht bekannt waren, beim ersten Aufruf zwischengespeichert.

Um alle Pfade zum Build-Zeitpunkt statisch zu rendern, übergeben Sie die vollständige Liste der Pfade an generateStaticParams:

export async function generateStaticParams() {
  const posts = await fetch('https://.../posts').then((res) => res.json())

  return posts.map((post) => ({
    slug: post.slug,
  }))
}

Um eine Teilmenge der Pfade zum Build-Zeitpunkt statisch zu rendern und den Rest beim ersten Aufruf zur Laufzeit, geben Sie eine Teilmenge der Pfade zurück:

export async function generateStaticParams() {
  const posts = await fetch('https://.../posts').then((res) => res.json())

  // Die ersten 10 Beiträge zum Build-Zeitpunkt rendern
  return posts.slice(0, 10).map((post) => ({
    slug: post.slug,
  }))
}

Um alle Pfade beim ersten Aufruf statisch zu rendern, geben Sie ein leeres Array zurück (keine Pfade werden zum Build-Zeitpunkt gerendert) oder nutzen Sie export const dynamic = 'force-static':

export async function generateStaticParams() {
  return []
}

Wichtig: Sie müssen ein Array aus generateStaticParams zurückgeben, auch wenn es leer ist. Andernfalls wird die Route dynamisch gerendert.

export const dynamic = 'force-static'

Um das Caching zur Laufzeit zu deaktivieren, fügen Sie die Option export const dynamicParams = false in einem Routen-Segment hinzu. Wenn diese Konfigurationsoption verwendet wird, werden nur die von generateStaticParams bereitgestellten Pfade bedient, andere Routen führen zu einem 404-Fehler oder werden gematcht (im Fall von Catch-all-Routen).

React cache-Funktion

Die React cache-Funktion ermöglicht es Ihnen, den Rückgabewert einer Funktion zu memoizen, sodass Sie dieselbe Funktion mehrfach aufrufen können, während sie nur einmal ausgeführt wird.

Da fetch-Anfragen automatisch memoisiert werden, müssen Sie sie nicht manuell mit React cache wrappen. Sie können jedoch cache verwenden, um Datenanfragen manuell zu memoizen, wenn die fetch-API nicht geeignet ist. Zum Beispiel bei einigen Datenbank-Clients, CMS-Clients oder GraphQL-Clients.

import { cache } from 'react'
import db from '@/lib/db'

export const getItem = cache(async (id: string) => {
  const item = await db.item.findUnique({ id })
  return item
})