Notizen zu Next.js 16 Cache Components

Vor einem halben Jahr wurde Next.js 16 am 21. Oktober 2025 offiziell veröffentlicht.

Das Konzept der Cache Components wurde mit Next.js 16 eingeführt und ermöglicht eine explizite Steuerung des Caches.

Nur der Bereich, in dem die Direktive use cache geschrieben wird, wird gecacht. Zusätzlich ist mit <Sunpense>eine komponentenbasierte Zwischenspeicherung möglich.

Da dieser Artikel ohnehin erscheint, fasse ich im Folgenden hauptsächlich zusammen, wie die Cache Components in Next.js 16 verwendet werden, und halte dabei zugleich meine eigenen Notizen fest!

Die vier Caches in Next.js AppRouter

Im Next.js AppRouter gibt es folgende vier Arten von Caches.

• Request Memoization: Doppelte Anfragen werden dedupliziert. Auch wenn verschiedene Komponenten denselben fetch aufrufen, wird er nur einmal ausgeführt. Diese Funktion übernimmt Next.js automatisch.
• Data Cache: Eine Funktion, mit der sich das Caching-Verhalten über die fetch-Optionen steuern lässt.
• Full Route Cache: Ein seitenbezogener Cache, der bei statischem Rendering (SSG, ISR) funktioniert. Er speichert den RSC-Payload und das HTML serverseitig.
• Router Cache: Ein temporärer Cache, der nur den „RSC-Payload“ im Arbeitsspeicher des Clients ablegt. Er wird aktiv, wenn die -Komponente von Next.js verwendet wird.

Neue Funktion in Next.js 16: "use cache"

Was die neue Funktion Cache Components ermöglicht.

• Mit use cache wird die Cache-Konfiguration vereinfacht. Nur die Stellen, an denen use cache geschrieben wird, werden gecacht, sodass sich das Caching explizit steuern lässt.
• Durch Umschließen mit <Suspense>... lassen sich Komponenten isolieren und das Caching kann auf Komponentenebene festgelegt werden.

Bis einschließlich Next.js 15 wurde fetch standardmäßig gecacht. Dadurch war schwer nachvollziehbar, was gecacht wird und was nicht, und unerwartetes Caching trat leicht auf.

Da standardmäßig automatisch gecacht wurde, war zum Deaktivieren das Hinzufügen von fetch(URL, { cache: 'no-store' }) erforderlich.

Next.js 16 hingegen verfolgt einen anderen Ansatz: Wenn Caching benötigt wird, wird use cache angegeben. Das ist klar und deutlich einfacher.

Bisher konnte der Data Cache von Next.js nur über fetch genutzt werden. Jetzt lässt sich der Cache auch direkt auf asynchrone Funktionen anwenden, die kein fetch verwenden, etwa Datenbankabfragen.

Umsetzung

Dazu müssen Sie Cache Components in der Datei next.config.js aktivieren.

Mit dieser Einstellung stehen die Funktionen von Cache Components zur Verfügung!

import type { NextConfig } from "next";

const nextConfig: NextConfig = {
  cacheComponents: true,
};

export default nextConfig;

Fügen Sie am Anfang der Komponente, die gecacht werden soll, die Direktive use cache hinzu. Soll nur eine bestimmte Funktion gecacht werden, schreiben Sie die Direktive innerhalb der Funktion.

'use cache'

async function getPosts() {
  const res = await fetch('<https://api.example.com/posts>')
  return res.json()
}

export default async function PostList() {
  const posts = await getPosts()
  return (
    <ul>
      {posts.map(post => <li>{post.title}</li>)}
    </ul>
  )
}

Was passiert, wenn für eine fetch-Funktion kein use cache gesetzt ist?

Ab Next.js 16 müssen Sie use cache hinzufügen, um Caching zu aktivieren. Was passiert aber, wenn weder use cache noch die Option cache gesetzt ist?

Bei cacheComponents: true tritt ein Fehler auf. Um Caching bewusst zu deaktivieren, verwenden Sie nicht fetch(url, { cache: 'no-store' }), sondern umschließen den Aufruf einfach mit <Suspense>...! (Bei cacheComponents: false (Standard) funktioniert no-store wie bisher.)

Caching auf Funktionsebene

Bisher ließ sich Caching nur auf Seitenebene konfigurieren. Mit use cache und lassen sich Caching-Einstellungen nun auf Komponenten- und Funktionsebene festlegen.

Der Vorteil dabei: Statisches und dynamisches Rendering lassen sich innerhalb einer einzigen Seite kombinieren. Schnell ausgelieferte statische Inhalte und dynamische Inhalte können so nebeneinander bestehen, was die initiale Ladezeit und die UX deutlich verbessert. (Diese Rendering-Methode heißt PPR.)

Suspense

Die Aufgabe besteht darin, diesen Bereich unabhängig vom übrigen Teil der Seite separat verarbeitbar zu machen. Dies übernimmt <Suspense><>.

Durch das Umschließen mit <Suspense> lassen sich Komponenten voneinander trennen. Soll ein Caching auf Komponentenebene erfolgen, wird dies innerhalb der umschlossenen Komponente festgelegt.

Zum Rendering

Die Caching-Konfiguration bestimmt die Rendering-Methode.

„Wie soll diese Seite bzw. diese Daten dargestellt werden?“ (z. B. Aktualisierungshäufigkeit)

↓

Rendering-Methode festlegen (SSG / ISR / SSR / PPR / CSR)

↓

Entsprechendes Caching konfigurieren

Das ist der Denkansatz.

Es gibt auch mehrere Rendering-Methoden, aber die lasse ich diesmal weg!

Zum Beispiel:

Im Fall einer "dynamischen Routing-Seite, die Daten aus microCMS abruft und Blogbeiträge anzeigt"

↓

Als Rendering-Methode eignet sich SSG oder ISR am besten (da sich Artikelinhalte nicht häufig ändern).

↓

Mit Caching ist es optimal → use cache hinzufügen.

So lässt sich das umsetzen.

Übrigens: Wenn Sie in der Datei next.config.js Cache Components nicht auf true setzen, können Sie die bisherige fetch-cache-Option wie gewohnt weiterverwenden.

Fazit

Bei der Planung der Cache-Einstellungen ist der Ablauf wichtig: "Wie soll dieser Datensatz bzw. diese Seite präsentiert werden?" Ausgehend davon implementiert man die optimale Performance für genau diese Seite.

Steht diese Antwort fest, ergibt sich ganz natürlich, ob use cache verwendet werden soll.

Viele denken vermutlich, dass Cache, Rendering-Methoden und Datenabruf getrennt voneinander zu verstehen sind, aber für mich fügt sich alles zusammen!

Es ist wichtig, das nicht als getrennte Konzepte zu betrachten, sondern als einen zusammenhängenden Ablauf!!