Inhaltsverzeichnis
- Es gibt vier Cache-Szenarien in Next.js 14:
- Beispiel für das Standardverhalten (1)
- Beispiel für “Keinen Cache” (2)
- Beispiel für “Zeitbasierte Cache Regenerierung"
- Beispiel für “On-demand Cache Regenerierung”
- Contentful webhook für Cache Neugenerierung über Route revalidatepath
- Cloudapp-dev und bevor Sie uns verlassen
In dieser Schritt-für-Schritt Anleitung werde ich Ihnen am Anfang erklären, wie das Caching in Next.js. 14 funktioniert und wie Sie es einfach im Code implementieren können. Wie in unseren vorherigen Posts werde ich Contentful als Headless-CMS für das Content-Management verwenden. Das Zwischenspeichern ist entscheidend für die Bereitstellung einer schnellen Website, aber da neue Inhalte hinzukommen, benötigen wir eine geeignete Revalidierungsstrategie, die von Ihrem Anwendungsfall abhängt. Über die Contentful Webhooks haben wir eine einfache Möglichkeit, gezielt den Cache von Seiten (Urls) neu zu generieren, welche hinzugekommen sind oder angepasst wurden.
Der komplette Code ist in diesem Github repo verfügbar.
Es gibt vier Cache-Szenarien in Next.js 14:
Das Standardverhalten besteht darin, die Daten (Werte aus dem Fetch-Rückgabewert) im Daten-Cache auf dem Server für immer zu speichern (SSG - Statische Seiten-Generierung).
Kein Caching oder Opting-Out aus der Daten-Caching (Dynamisches Abrufen)
Zeitbasierte Neuvalidierung
Bedarfsorientierte Neuvalidierung
Beispiel für das Standardverhalten (1)
Beispiel für “Keinen Cache” (2)
fetch Anfragen werden nicht gecached wenn:
Der cache: 'no-store' bei Anfragen hinzugefügt wird.
Die revalidate: 0 Option bei individuellen fetch Anfragen hinzugefügt wird.
Die fetch Anfrage sich innerhalb eines Route Handlers befindet, welcher die POST Methode verwendet.
Die fetch Anfrage nach der Verwendung von headers oder cookies genutzt wird.
Die Route Segment Option const dynamic = 'force-dynamic' genutzt wird.
Die fetchCache Route Segment Option so konfiguriert ist, dass nichts gecached wird.
Die Fetch-Anfrage verwendet Autorisierungs- oder Cookie-Header, und es gibt eine nicht zwischengespeicherte Anfrage darüber im Komponentenbaum.
Beispiel für “Zeitbasierte Cache Regenerierung"
man kann die “next.revalidate” fetch Option für das Konfigurieren der Cache TTL in Sekunden verwenden.
Wenn Sie alle "Fetch-Anfragen" in einem Routenabschnitt neu validieren möchten, z. B. für alle Blogbeiträge in einem Blog, können Sie die Segmentkonfigurationsoptionen in der layout.tsx- oder page.tsx-Datei verwenden.
Beispiel für “On-demand Cache Regenerierung”
Hier gibt es zwei Möglichkeiten:
path (revalidatePath)
tag (revalidateTag)
Auf der Suchergebnisseite ("src/app/[locale]/search/[searchTerm]") finden Sie ein Beispiel für "no-cache" in Zeile 37.
In der Datei sitemap.ts finden Sie ein Beispiel für zeitbasierte Validierung: "export const revalidate = 24 * 60 * 60; // alle höchstens jede Stunde neu validieren" in Zeile 57.
Für On-Demand Cache Regenerierung habe ich zwei neue API-Routen hinzugefügt (revalidatetag und revalidatepath).
Aus Sicherheitsgründen habe ich am Anfang der Routen ein "Secret" hinzugefügt, damit nicht jeder die Endpunkte aufrufen kann.
Contentful webhook für Cache Neugenerierung über Route revalidatepath
Wir werden das "slug"-Attribut in unserem Contentful-Eintrag verwenden, um die Daten an unseren neuen "revalidatepath"-Endpunkt zu senden, der sich um die Aktualisierung des Caches kümmert.
Darunter können Sie den Code des Endpunkts “revalidatepath” sehen:
Für den "revalidatetag"-Endpunkt empfehle ich eine Postman-Integration oder eine benutzerdefinierte Integration für Ihr Projekt.
Cloudapp-dev und bevor Sie uns verlassen
Danke, dass Sie bis zum Ende gelesen haben. Noch eine Bitte bevor Sie gehen:
Wenn Ihnen gefallen hat was Sie gelesen haben oder wenn es Ihnen sogar geholfen hat, dann würden wir uns über einen "Clap" 👏 oder einen neuen Follower auf unseren Medium Account sehr freuen.
