Caching in Next.js

Next.js verbessert die Leistung deiner Anwendung und reduziert Kosten durch das Caching von Rendering-Vorgängen und Datenanfragen. Diese Seite bietet einen detaillierten Einblick in die Caching-Mechanismen von Next.js, die APIs zur Konfiguration und wie sie miteinander interagieren.

Hinweis: Diese Seite hilft dir zu verstehen, wie Next.js unter der Haube funktioniert, ist aber nicht unbedingt erforderlich, um produktiv mit Next.js zu arbeiten. Die meisten Caching-Heuristiken von Next.js werden durch deine API-Nutzung bestimmt und haben Standardeinstellungen für beste Performance mit minimaler oder gar keiner Konfiguration. Wenn du stattdessen direkt zu Beispielen springen möchtest, starte hier.

Übersicht

Hier ist ein Überblick über die verschiedenen Caching-Mechanismen und ihre Zwecke:

Standardmäßig wird Next.js so viel wie möglich cachen, um die Performance zu verbessern und Kosten zu reduzieren. Das bedeutet, dass Routen statisch gerendert und Datenanfragen gecacht werden, es sei denn, du deaktivierst dies explizit. Das folgende Diagramm zeigt das standardmäßige Caching-Verhalten: wenn eine Route zur Build-Zeit statisch gerendert wird und wenn eine statische Route zum ersten Mal aufgerufen wird.

Das Caching-Verhalten ändert sich abhängig davon, ob die Route statisch oder dynamisch gerendert wird, ob Daten gecacht sind oder nicht und ob eine Anfrage Teil eines initialen Besuchs oder einer nachfolgenden Navigation ist. Je nach Anwendungsfall kannst du das Caching-Verhalten für einzelne Routen und Datenanfragen konfigurieren.

Request Memoization

React erweitert die fetch API, um Anfragen mit gleicher URL und gleichen Optionen automatisch zu memoizieren. Das bedeutet, du kannst eine Fetch-Funktion für die gleichen Daten an mehreren Stellen im React-Komponentenbaum aufrufen, während sie nur einmal ausgeführt wird.

Wenn du zum Beispiel die gleichen Daten über eine Route hinweg benötigst (z.B. in einem Layout, einer Page und mehreren Komponenten), musst du die Daten nicht am oberen Ende des Baums abrufen und als Props weiterreichen. Stattdessen kannst du die Daten in den Komponenten abrufen, die sie benötigen, ohne dir Sorgen über die Performance-Auswirkungen von mehrfachen Netzwerkanfragen für die gleichen Daten machen zu müssen.

async function getItem() {
  // Die `fetch`-Funktion wird automatisch memoiziert 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 kann überall in deiner Route sein
const item = await getItem() // cache HIT

Wie Request Memoization funktioniert

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

Gut zu wissen:

• Request Memoization ist eine React-Funktion, keine Next.js-Funktion. Sie wird hier aufgeführt, um zu zeigen, wie sie mit den 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:
  • Sie gilt für fetch-Anfragen in generateMetadata, generateStaticParams, Layouts, Pages und anderen Server Components.
  • Sie 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), kannst du die React cache-Funktion verwenden, um Funktionen zu memoizieren.

Dauer

Der Cache besteht für die Lebensdauer einer Serveranfrage, bis der React-Komponentenbaum fertig gerendert wurde.

Revalidierung

Da die Memoization nicht über Serveranfragen hinweg geteilt wird und nur während des Renderings gilt, gibt es keine Notwendigkeit, sie zu revalidieren.

Deaktivierung

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

Um einzelne Anfragen zu verwalten, kannst du die signal-Eigenschaft von AbortController verwenden. Dies wird jedoch die Anfragen nicht von der Memoization ausschließen, sondern laufende Anfragen abbrechen.

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

Data Cache

Next.js hat einen eingebauten Data Cache, der die Ergebnisse von Datenabrufen über eingehende Serveranfragen und Deployments hinweg persistiert. Dies ist möglich, weil Next.js die native fetch API erweitert, um jeder Anfrage auf dem Server zu ermöglichen, ihre eigene persistente Caching-Semantik zu setzen.

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.

Du kannst die Optionen cache und next.revalidate von fetch verwenden, um das Caching-Verhalten zu konfigurieren.

Wie der Data Cache funktioniert

• Wenn während des Renderings zum ersten Mal eine fetch-Anfrage mit der Option 'force-cache' 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 memoiziert.
• Wenn keine gecachte Antwort gefunden wird, wird die Anfrage an die Datenquelle gestellt, das Ergebnis wird im Data Cache gespeichert und memoiziert.
• Für ungecachte Daten (z.B. keine cache-Option definiert oder Verwendung von { cache: 'no-store' }), wird das Ergebnis immer von der Datenquelle abgerufen und memoiziert.
• Ob die Daten gecacht sind oder nicht, die Anfragen werden immer memoiziert, um doppelte Anfragen für die gleichen Daten während eines React-Render-Durchgangs zu vermeiden.

Unterschiede zwischen Data Cache und Request Memoization

Während beide Caching-Mechanismen die Performance verbessern, indem sie gecachte Daten wiederverwenden, ist der Data Cache persistent über eingehende Anfragen und Deployments hinweg, während die Memoization nur für die Lebensdauer einer Anfrage gilt.

Dauer

Der Data Cache ist persistent über eingehende Anfragen und Deployments hinweg, es sei denn, du revalidierst oder deaktivierst ihn.

Revalidierung

Gecachte Daten können auf zwei Arten revalidiert werden:

• Zeitbasierte Revalidierung: Revalidiere Daten, nachdem eine bestimmte Zeit verstrichen ist und eine neue Anfrage gestellt wird. Dies ist nützlich für Daten, die sich selten ändern und bei denen Aktualität nicht so kritisch ist.
• On-Demand-Revalidierung: Revalidiere Daten basierend auf einem Ereignis (z.B. Formular-Übermittlung). On-Demand-Revalidierung kann einen tag-basierten oder pfad-basierten Ansatz verwenden, um Gruppen von Daten auf einmal zu revalidieren. Dies ist nützlich, wenn du sicherstellen möchtest, dass die neuesten Daten so schnell wie möglich angezeigt werden (z.B. wenn Inhalte deines Headless CMS aktualisiert werden).

Zeitbasierte Revalidierung

Um Daten in einem zeitlichen Intervall zu revalidieren, kannst du die Option next.revalidate von fetch verwenden, um die Cache-Lebensdauer einer Ressource (in Sekunden) festzulegen.

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

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

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 innerhalb des angegebenen Zeitrahmens (z.B. 60 Sekunden) erhalten die gecachten Daten zurück.
• Nach Ablauf des Zeitrahmens wird die nächste Anfrage immer noch die gecachten (jetzt veralteten) Daten zurückgeben.
  • Next.js wird im Hintergrund eine Revalidierung der Daten auslösen.
  • 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 nach Bedarf per Pfad (revalidatePath) oder per 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 gelöscht.
  • Dies unterscheidet sich von der zeitbasierten Revalidierung, die die veralteten Daten im Cache behält, bis die frischen Daten abgerufen wurden.
• 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 du die Antwort von fetch nicht cachen möchtest, kannst du Folgendes tun:

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

Full Route Cache

Verwandte Begriffe:

Die Begriffe Automatische Statische Optimierung, Statische Site-Generierung oder Statisches Rendering werden oft austauschbar verwendet, um den Prozess des Renderns und Cachens von Routen deiner Anwendung zur Build-Zeit zu beschreiben.

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

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

1. React Rendering auf dem Server

Auf dem Server verwendet Next.js React's 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 Components in ein spezielles Datenformat, das für Streaming optimiert ist, genannt die React Server Component Payload.
2. Next.js verwendet die React Server Component Payload und Client Component 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 können. Stattdessen können wir eine Antwort streamen, während die Arbeit abgeschlossen wird.

Was ist die React Server Component Payload?

Die React Server Component Payload ist eine kompakte binäre Darstellung des gerenderten React Server Components-Baums. Sie wird von React auf dem Client verwendet, um das Browser-DOM zu aktualisieren. Die React Server Component Payload enthält:

• Das gerenderte Ergebnis von Server Components
• Platzhalter für die Stellen, an denen Client Components gerendert werden sollen, und Verweise auf ihre JavaScript-Dateien
• Alle Props, die von einem Server Component an ein Client Component übergeben werden

Weitere Informationen findest du in der Server Components-Dokumentation.

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

Das Standardverhalten von Next.js ist es, 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 Zeitpunkt der Anfrage, auf dem Client:

1. Das HTML wird verwendet, um sofort eine schnelle, nicht-interaktive Vorschau der Client und Server Components anzuzeigen.
2. Die React Server Components Payload wird verwendet, um die Client- und gerenderten Server Component-Bäume abzugleichen und das DOM zu aktualisieren.
3. Die JavaScript-Anweisungen werden verwendet, um Client Components zu hydratisieren und die Anwendung interaktiv zu machen.

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

Die 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 die Navigationserfahrung zu verbessern, indem zuvor besuchte Routen gespeichert und zukünftige Routen vorgeladen werden.

5. Nachfolgende Navigationen

Bei nachfolgenden Navigationen oder während des Vorladens prüft Next.js, ob die React Server Component Payload im Router Cache gespeichert ist. Wenn ja, wird keine neue Anfrage an den Server gesendet.

Wenn die Routensegmente nicht im Cache sind, wird Next.js die React Server Component Payload vom Server abrufen und den Router Cache auf dem Client füllen.

Statisches und Dynamisches Rendering

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

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

Erfahre mehr über statisches und dynamisches Rendering.

Dauer

Standardmäßig ist der Full Route Cache persistent. Das bedeutet, dass die Render-Ausgabe über Benutzeranfragen hinweg gecacht wird.

Invalidierung

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

• Daten revalidieren: Das Revalidieren des Data Cache wird wiederum den Router Cache invalidieren, indem Komponenten auf dem Server neu gerendert und die neue Render-Ausgabe gecacht wird.
• Neu deployen: Im Gegensatz zum Data Cache, der über Deployments hinweg bestehen bleibt, wird der Full Route Cache bei neuen Deployments gelöscht.

Deaktivierung

Du kannst den Full Route Cache deaktivieren, oder mit anderen Worten, Komponenten für jede eingehende Anfrage dynamisch rendern, durch:

• Verwendung einer Dynamischen API: Dies wird die Route aus dem Full Route Cache ausschließen und sie zur Anforderungszeit dynamisch rendern. Der Data Cache kann weiterhin verwendet werden.
• Verwendung der Route Segment Config-Optionen dynamic = 'force-dynamic' oder revalidate = 0: Dies wird den Full Route Cache und den Data Cache überspringen. Das bedeutet, dass Komponenten gerendert und Daten bei jeder eingehenden Anfrage an den Server abgerufen werden. Der Router Cache wird weiterhin angewendet, da er ein clientseitiger Cache ist.
• Deaktivierung des Data Cache: Wenn eine Route eine fetch-Anfrage hat, die nicht gecacht ist, wird dies die Route aus dem Full Route Cache ausschließen. Die Daten für die spezifische fetch-Anfrage werden für jede eingehende Anfrage abgerufen. Andere fetch-Anfragen, die das Caching nicht deaktivieren, werden weiterhin im Data Cache gecacht. Dies ermöglicht eine Mischung aus gecachten und ungecachten Daten.

Clientseitiger Router Cache

Next.js hat einen In-Memory clientseitigen Router Cache, der die RSC Payload von Routensegmenten speichert, aufgeteilt nach Layouts, Ladezuständen und Seiten.

Wenn ein Benutzer zwischen Routen navigiert, cached Next.js die besuchten Routensegmente und lädt vor die Routen, zu denen der Benutzer wahrscheinlich navigieren wird. Dies führt zu sofortiger Vor-/Zurück-Navigation, keinem vollständigen Seiten-Reload zwischen Navigationen und Erhaltung des React-Zustands und Browser-Zustands.

Mit dem Router Cache:

• Layouts werden gecacht und bei der Navigation wiederverwendet (partielles Rendering).
• Ladezustände werden gecacht und bei der Navigation für sofortige Ladezustände wiederverwendet.
• Seiten werden standardmäßig nicht gecacht, werden aber während der Browser-Vor-/Zurück-Navigation wiederverwendet. Du kannst das Cachen für Seitensegmente mit der experimentellen staleTimes-Konfigurationsoption aktivieren.

Gut zu wissen: Dieser Cache gilt speziell für Next.js und Server Components und unterscheidet sich vom bfcache des Browsers, obwohl er ein ähnliches Ergebnis hat.

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 Seiten-Aktualisierung gelöscht.
• Automatische Invalidierungsperiode: Der Cache von Layouts und Ladezuständen wird nach einer bestimmten Zeit automatisch invalidiert. Die Dauer hängt davon ab, wie die Ressource vorgeladen wurde und ob die Ressource statisch generiert wurde:
  • Standard-Vorladen (prefetch={null} oder nicht angegeben): nicht gecacht für dynamische Seiten, 5 Minuten für statische Seiten.
  • Vollständiges Vorladen (prefetch={true} oder router.prefetch): 5 Minuten für sowohl statische als auch dynamische Seiten.

Während eine Seiten-Aktualisierung alle gecachten Segmente löscht, betrifft die automatische Invalidierungsperiode nur das einzelne Segment ab dem Zeitpunkt des Vorladens.

Gut 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 revalidieren 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 wird den Router Cache invalidieren und eine neue Anfrage an den Server für die aktuelle Route stellen.

Deaktivierung

Ab Next.js 15 sind Seitensegmente standardmäßig deaktiviert.

Gut zu wissen: Du kannst auch das Vorladen deaktivieren, indem du die prefetch-Prop der <Link>-Komponente auf false setzt.

Cache-Interaktionen

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

Data Cache und Full Route Cache

• Das Revalidieren oder Deaktivieren des Data Cache wird den Full Route Cache invalidieren, da die Render-Ausgabe von Daten abhängt.
• Das Invalidieren oder Deaktivieren des Full Route Cache hat keinen Einfluss auf den Data Cache. Du kannst eine Route dynamisch rendern, die sowohl gecachte als auch ungecachte Daten hat. Dies ist nützlich, wenn der Großteil deiner Seite gecachte Daten verwendet, aber du einige Komponenten hast, die auf Daten angewiesen sind, die zur Anforderungszeit abgerufen werden müssen. Du kannst dynamisch rendern, ohne dir Sorgen über die Performance-Auswirkungen des erneuten Abrufens aller Daten machen zu müssen.

Data Cache und clientseitiger Router Cache

• Um den Data Cache und Router Cache sofort zu invalidieren, kannst du revalidatePath oder revalidateTag in einer Server Action verwenden.
• Das Revalidieren 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. Dies bedeutet, dass der Router Cache weiterhin die vorherige Payload bereitstellen wird, bis eine harte Aktualisierung erfolgt oder die automatische Invalidierungsperiode abgelaufen ist.

APIs

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

<Link>

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

Um das Vorladen zu deaktivieren, kannst du die prefetch-Prop auf false setzen. Dies wird den Cache jedoch nicht dauerhaft überspringen, das Routensegment wird trotzdem clientseitig gecacht, wenn der Benutzer die Route besucht.

Erfahre mehr über die <Link>-Komponente.

router.prefetch

Die prefetch-Option des useRouter-Hooks kann verwendet werden, um eine Route manuell vorzuladen. 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 eine Route manuell zu aktualisieren. Dies löscht den Router Cache vollständig und stellt eine neue Anfrage an den Server für die aktuelle Route. refresh hat keinen Einfluss auf den Data oder Full Route Cache.

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

Siehe die useRouter-Hook API-Referenz.

fetch

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

Wenn du die Antwort von fetch nicht cachen möchtest, kannst du Folgendes tun:

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

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

fetch options.cache

Du kannst einzelne fetch-Anfragen in das Caching einbeziehen, indem du die cache-Option auf force-cache setzt:

// Opt into caching
fetch(`https://...`, { cache: 'force-cache' })

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

fetch options.next.revalidate

Du kannst die next.revalidate-Option von fetch verwenden, um die Revalidierungsperiode (in Sekunden) einer einzelnen fetch-Anfrage festzulegen. Dies wird den Data Cache revalidieren, was wiederum den Full Route Cache revalidiert. Frische Daten werden abgerufen und Komponenten werden auf dem Server neu gerendert.

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

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

fetch options.next.tags und revalidateTag

Next.js hat ein Cache-Tagging-System für feingranulares Daten-Caching und Revalidierung.

1. Bei der Verwendung von fetch oder unstable_cache hast du die Möglichkeit, Cache-Einträge mit einem oder mehreren Tags zu versehen.
2. Dann kannst du revalidateTag aufrufen, um die Cache-Einträge zu löschen, die mit diesem Tag verbunden sind.

Zum Beispiel kannst du beim Abrufen von Daten einen Tag setzen:

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

Dann rufe revalidateTag mit einem Tag auf, um den Cache-Eintrag zu löschen:

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

Es gibt zwei Stellen, an denen du revalidateTag verwenden kannst, je nachdem, was du erreichen möchtest:

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

revalidatePath

revalidatePath ermöglicht es dir, manuell Daten und die Routensegmente unterhalb eines bestimmten Pfads in einem einzigen Vorgang zu revalidieren. Der Aufruf der revalidatePath-Methode revalidiert den Data Cache, was wiederum den Full Route Cache invalidiert.

revalidatePath('/')

Es gibt zwei Stellen, an denen du revalidatePath verwenden kannst, je nachdem, was du erreichen möchtest:

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

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

revalidatePath vs. router.refresh:

Der Aufruf von router.refresh wird den Router Cache löschen und Routensegmente auf dem Server neu rendern, 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 eine clientseitige API ist.

Dynamic APIs

Dynamische APIs wie cookies und headers und die searchParams-Prop in Pages hängen von Laufzeit-Informationen der eingehenden Anfrage ab. Ihre Verwendung wird eine Route aus dem Full Route Cache ausschließen, mit anderen Worten, 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.

Segment Config Options

Die Route Segment Config Optionen können verwendet werden, um die Standardeinstellungen des Routensegments zu überschreiben oder wenn du die fetch API nicht verwenden kannst (z.B. Datenbank-Client oder Drittanbieter-Bibliotheken).

Die folgenden Route Segment Config Optionen werden den Full Route Cache deaktivieren:

• const dynamic = 'force-dynamic'

Diese Konfigurationsoption wird alle Abrufe aus dem Data Cache ausschließen (d.h. no-store):

• const fetchCache = 'default-no-store'

Siehe fetchCache für weitere fortgeschrittene Optionen.

Siehe die Route Segment Config Dokumentation für weitere Optionen.

generateStaticParams

Für dynamische Segmente (z.B. app/blog/[slug]/page.js) werden Pfade, die von generateStaticParams bereitgestellt werden, zur Build-Zeit im Full Route Cache gecacht. Zur Laufzeit wird Next.js auch Pfade cachen, die zur Build-Zeit nicht bekannt waren, wenn sie zum ersten Mal besucht werden.

Um alle Pfade zur Build-Zeit statisch zu rendern, gib 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 von Pfaden zur Build-Zeit statisch zu rendern und den Rest beim ersten Besuch zur Laufzeit, gib eine Teilliste von Pfaden zurück:

export async function generateStaticParams() {
  const posts = await fetch('https://.../posts').then((res) => res.json())
 
  // Rendere die ersten 10 Posts zur Build-Zeit
  return posts.slice(0, 10).map((post) => ({
    slug: post.slug,
  }))
}

Um alle Pfade beim ersten Besuch statisch zu rendern, gib ein leeres Array zurück (keine Pfade werden zur Build-Zeit gerendert) oder verwende export const dynamic = 'force-static':

export async function generateStaticParams() {
  return []
}

Gut zu wissen: Du musst 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 Anforderungszeit zu deaktivieren, füge die Option export const dynamicParams = false in einem Routensegment hinzu. Wenn diese Konfigurationsoption verwendet wird, werden nur Pfade bereitgestellt, die von generateStaticParams bereitgestellt werden, und andere Routen werden 404 oder match (im Fall von catch-all routes).

React cache Funktion

Die React cache Funktion ermöglicht es dir, den Rückgabewert einer Funktion zu memoizieren, sodass du die gleiche Funktion mehrmals aufrufen kannst, während sie nur einmal ausgeführt wird.

Da fetch-Anfragen automatisch memoiziert werden, musst du sie nicht in React cache einwickeln. Du kannst jedoch cache verwenden, um Datenanfragen manuell zu memoizieren, wenn die fetch API nicht geeignet ist. Zum Beispiel einige 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
})

import { cache } from 'react'
import db from '@/lib/db'
 
export const getItem = cache(async (id) => {
  const item = await db.item.findUnique({ id })
  return item
})