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 zur Konfiguration und ihre Interaktionen.

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

Überblick

Hier ist eine hochrangige Übersicht der verschiedenen Caching-Mechanismen und ihrer Zwecke:

Standardmäßig cached Next.js so viel wie möglich, um die Leistung zu verbessern und Kosten zu reduzieren. Das bedeutet, Routen werden statisch gerendert und Datenanfragen werden gecached, es sei denn, Sie deaktivieren dies. Das Diagramm unten zeigt das Standard-Caching-Verhalten: wenn eine Route zur Build-Zeit statisch gerendert wird und wenn eine statische Route erstmals besucht wird.

Das Caching-Verhalten ändert sich je nachdem, ob die Route statisch oder dynamisch gerendert wird, Daten gecached oder uncached 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, Sie können eine fetch-Funktion für dieselben Daten an mehreren Stellen in einem React-Komponentenbaum aufrufen, 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 an der Spitze des Baums abfragen und Props zwischen Komponenten weitergeben. Stattdessen können Sie die Daten in den Komponenten abfragen, die sie benötigen, ohne sich um die Leistungsauswirkungen mehrerer Netzwerkanfragen für dieselben Daten kümmern zu müssen.

async function getItem() {
  // Die `fetch`-Funktion wird automatisch memoized und das Ergebnis
  // wird gecached
  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

async function getItem() {
  // Die `fetch`-Funktion wird automatisch memoized und das Ergebnis
  // wird gecached
  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 des Renderings einer Route wird beim ersten Aufruf einer bestimmten Anfrage das Ergebnis nicht im Speicher sein, was zu einem Cache MISS führt.
• Daher wird die Funktion ausgeführt, die Daten von der externen Quelle abgerufen und das Ergebnis im Speicher gespeichert.
• Nachfolgende Funktionsaufrufe derselben Anfrage im selben Render-Durchlauf führen zu einem Cache HIT, 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 gelöscht.

Gut zu wissen:

• Request Memoization ist ein React-Feature, kein Next.js-Feature. Es ist hier enthalten, um die Interaktion mit anderen Caching-Mechanismen zu zeigen.
• 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 Handlern, 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 fertig gerendert wurde.

Revalidierung

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

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, sondern bricht laufende Anfragen ab.

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

Data Cache

Next.js hat einen integrierten Data Cache, der die Ergebnisse 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

• Beim ersten Aufruf einer fetch-Anfrage mit der 'force-cache'-Option während des Renderings 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 ungecachte 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 gecached oder ungecached sind, werden die Anfragen immer memoized, um doppelte Anfragen für dieselben Daten während eines React-Render-Durchlaufs zu vermeiden.

Unterschiede zwischen Data Cache und Request Memoization

Während beide Caching-Mechanismen die Leistung durch 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: Daten nach einer bestimmten Zeit und einer neuen Anfrage revalidieren. Dies ist nützlich für Daten, die sich selten ändern und bei denen Aktualität nicht kritisch ist.
• On-Demand-Revalidierung: Daten basierend auf einem Ereignis revalidieren (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 Cache-Lebensdauer einer Ressource (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

• Beim ersten Aufruf einer fetch-Anfrage mit revalidate 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 Zeitrahmen gibt die nächste Anfrage weiterhin 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 stale-while-revalidate-Verhalten.

On-Demand-Revalidierung

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

Wie On-Demand-Revalidierung funktioniert

• Beim ersten Aufruf einer fetch-Anfrage 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 veraltete Daten im Cache bleiben, bis frische Daten abgerufen werden.
• Bei der nächsten Anfrage 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önnten die Begriffe Automatic Static Optimization, Static Site Generation oder Static Rendering sehen, die synonym verwendet werden, um den Prozess des Renderings und Cachings 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 eines serverseitigen Renderings für jede Anfrage auszuliefern, was zu schnelleren Seitenladezeiten führt.

Um zu verstehen, wie der Full Route Cache funktioniert, ist es hilfreich, sich anzuschauen, wie React mit Rendering umgeht 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 Routen-Segmenten 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, genannt 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, wir müssen nicht warten, 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

Zum Anfragezeitpunkt auf dem Client:

1. Das HTML wird verwendet, um sofort eine schnelle, nicht-interaktive initiale 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 Routen-Segmenten aufgeteilt ist. Dieser Router Cache wird verwendet, um das Navigationserlebnis zu verbessern, indem zuvor besuchte Routen gespeichert und zukünftige Routen vorab geladen werden.

5. Nachfolgende Navigationen

Bei nachfolgenden Navigationen oder während des Prefetchings 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 Routen-Segmente 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 zwischengespeichert, während dynamische Routen zur Laufzeit gerendert und nicht zwischengespeichert werden.

Dieses Diagramm zeigt den Unterschied zwischen statisch und dynamisch gerenderten Routen mit zwischengespeicherten und nicht zwischengespeicherten 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 geleert.

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 schließt die Route aus dem Full Route Cache aus 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 abgefragt. 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 zwischengespeichert wird, wird die Route aus dem Full Route Cache ausgeschlossen. Die Daten für diese spezifische fetch-Anfrage werden bei jeder eingehenden Anfrage neu abgerufen. Andere fetch-Anfragen, die das Caching nicht deaktivieren, bleiben im Data Cache zwischengespeichert. Dies ermöglicht eine Mischung aus zwischengespeicherten und nicht zwischengespeicherten Daten.

Client-seitiger Router Cache

Next.js verfügt über einen speicherinternen Client-seitigen Router Cache, der die RSC-Payload (React Server Component) von Routensegmenten speichert, unterteilt in Layouts, Ladezustände 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 sofortiger Vor-/Rückwärtsnavigation, keinem vollständigen Seitenneuladen zwischen Navigationen und der Beibehaltung des React- und Browserzustands.

Mit dem Router Cache:

• Layouts werden zwischengespeichert und bei der Navigation wiederverwendet (partielles Rendering).
• Ladezustände werden zwischengespeichert und bei der Navigation für sofortige Navigation wiederverwendet.
• Seiten werden standardmäßig nicht zwischengespeichert, aber bei Browser-Vor- und Rückwärtsnavigation 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 bei einem Seitenneuladen geleert.
• Automatischer Invalidierungszeitraum: Der Cache für Layouts und Ladezustände wird automatisch nach einem bestimmten Zeitraum 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 zwischengespeichert 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:
  • On-Demand-Daten-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-Property 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 zwischengespeicherte als auch nicht zwischengespeicherte Daten enthält. Dies ist nützlich, wenn der Großteil Ihrer Seite zwischengespeicherte Daten verwendet, Sie aber einige Komponenten haben, die auf Daten angewiesen sind, die zur Laufzeit abgerufen werden müssen. Sie können dynamisch rendern, ohne sich Gedanken über die Leistungsauswirkungen des erneuten Abrufs aller Daten machen 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 die 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 die React Server Component Payload dem Router Cache hinzu.

Um das Prefetching zu deaktivieren, können Sie die prefetch-Property 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 die React Server Component Payload dem 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 leert 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 Browserzustand erhalten bleibt.

Siehe die useRouter-Hook-API-Referenz.

fetch

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

Das standardmäßige Caching-Verhalten von fetch (z.B. wenn die cache-Option nicht angegeben ist) entspricht der Einstellung 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-Anfragen 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) einer einzelnen fetch-Anfrage 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 fein abgestimmtes 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 invalidert 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 invalidert den Router Cache für die zugehörige Route.

revalidatePath

revalidatePath ermöglicht es Ihnen, manuell Daten und die darunter liegenden Routensegmente eines bestimmten Pfads in einem einzigen Vorgang zu revalidieren. 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, Klick auf einen Button) zu revalidieren.

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

revalidatePath vs. router.refresh:

Der Aufruf von router.refresh leert 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 verändert, da es sich um eine Client-seitige API handelt.

Dynamische APIs

Dynamische APIs wie cookies und headers sowie die searchParams-Property in Pages hängen von Laufzeitinformationen der eingehenden Anfrage ab. Ihre Verwendung schließt eine Route aus dem Full Route Cache aus, d.h. die Route wird dynamisch gerendert.

cookies

Die Verwendung von cookies.set oder cookies.delete in einer Server Action invalidert 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 Route-Segmente

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

Die folgenden Konfigurationsoptionen für Route-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 fortgeschrittene Optionen finden Sie unter fetchCache.

Weitere Optionen finden Sie in der Dokumentation zu 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 Pfade, die zum Build-Zeitpunkt nicht bekannt waren, beim ersten Aufruf ebenfalls im Cache gespeichert.

Um alle Pfade statisch zum Build-Zeitpunkt 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 statisch zum Build-Zeitpunkt und den Rest beim ersten Aufruf zur Laufzeit zu rendern, 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 werden zum Build-Zeitpunkt gerendert
  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 verwenden Sie export const dynamic = 'force-static':

export async function generateStaticParams() {
  return []
}

Wichtig: Sie müssen ein Array von 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 Route-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 memoized werden, müssen Sie sie nicht in 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 Datenbankclients, 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
})

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

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