Next.js 16 Cache Components: Was Shopware-Headless-Shops jetzt umbauen müssen
Wer ein Shopware-Frontend auf Next.js betreibt, hat sein Caching bisher über Route-Segment-Configs wie revalidate und dynamic gesteuert. Next.js 16 dreht dieses Modell um: Mit den Cache Components ist standardmäßig alles dynamisch, und gecacht wird nur noch dort, wo man es explizit mit use cache anfordert. Für Headless-Shops ist das kein kosmetisches Update, sondern eine Umstellung, die genau an der heikelsten Stelle ansetzt — der Grenze zwischen gecachtem Katalog und dynamischem Warenkorb. Was sich ändert und wie der Umbau aussieht.
1. Die Umkehr: Caching ist jetzt Opt-in
Der Kern der Cache Components in Next.js 16 ist ein Vorzeichenwechsel. Bisher war die Frage: „Wie mache ich diese Seite dynamisch?" Jetzt ist sie: „Was an dieser Seite darf ich überhaupt cachen?" Mit aktivierten Cache Components sind alle Seiten per Default dynamisch, und Caching passiert nur, wo man die use-cache-Direktive setzt. Aktiviert wird das Ganze über ein Flag in der Konfiguration: cacheComponents: true in der next.config.ts. Die Direktive selbst war in Next.js 15 noch experimentell — mit Version 16 ist sie als Teil der Cache Components produktiv nutzbar. Für den Alltag heißt das: Der Katalog wird bewusst gecacht, der Rest bleibt frisch. Genau diese Trennschärfe hat im Headless-Commerce bisher gefehlt.
2. use cache: Route, Komponente oder Funktion
Die Direktive lässt sich auf drei Ebenen einsetzen — und diese Flexibilität ist im Shop-Kontext der eigentliche Gewinn. Auf Datei-Ebene (ganz oben in page.tsx oder layout.tsx) cachst du eine ganze Route, etwa eine Kategorieseite. Auf Komponenten-Ebene cachst du gezielt einen Teilbaum — zum Beispiel eine Produktkachel, deren Ausgabe pro serialisierter Props-Kombination wiederverwendet wird. Auf Funktions-Ebene cachst du einen einzelnen Store-API-Aufruf, ohne die umgebende Seite anzufassen. Wichtig ist das Prinzip hinter dem Cache-Key: Er entsteht aus den Argumenten der Funktion. Übergibst du also eine Produkt-ID oder einen Sprach-Code, bekommt jede Kombination ihren eigenen Eintrag — die Basis für sauberes Caching mehrsprachiger, mehrwährungsfähiger Kataloge.
3. cacheLife und cacheTag: Dauer und gezielte Invalidierung
Ein gecachter Bereich ohne Steuerung würde entweder zu selten oder zu oft aktualisiert. Dafür gibt es zwei Werkzeuge. cacheLife bestimmt die Lebensdauer über benannte Profile — etwa cacheLife('hours') für einen Katalog, der sich stündlich rühren darf, oder cacheLife('max') für nahezu statische Inhalte. Das Standardprofil hält serverseitig 15 Minuten, bevor neu validiert wird. Der für Shops entscheidende Baustein ist aber cacheTag: Du versiehst einen gecachten Aufruf mit einem Tag wie products, und wenn in Shopware ein Preis oder Lagerstand geändert wird, feuert ein Webhook eine Server Action, die den Tag über revalidateTag invalidiert. So bleibt der Katalog blitzschnell und trotzdem aktuell — dieselbe On-Demand-Logik wie beim klassischen ISR-Setup, nur feingranularer verdrahtet.
4. Der Knackpunkt: dynamische Daten raus aus dem Cache
Hier liegt die Stelle, an der Headless-Shops beim Umstieg am ehesten stolpern. Ein gecachter Bereich darf laut Dokumentation nicht direkt auf laufzeitspezifische APIs wie cookies(), headers() oder searchParams zugreifen. Genau diese APIs braucht man im Shop aber ständig: Der Warenkorb hängt am sw-context-token im Cookie, der Login-Status ebenso. Die Regel ist deshalb klar: Kundenspezifische Daten dürfen nie in einen use cache-Scope. Entweder liest man die Runtime-Werte außerhalb des Caches aus und übergibt sie als Argumente, oder man kapselt die dynamischen Teile in eine <Suspense>-Grenze, die neben dem statischen Shell rendert. Wer das ignoriert, riskiert im schlimmsten Fall, dass ein Warenkorb quer über Nutzer hinweg gecacht wird — der klassische, teure Headless-Fehler, den das Token-Handling ohnehin sauber trennen sollte (mehr dazu im Beitrag zum Login & Session-Handling).
5. Der Migrationspfad: weg von dynamic, revalidate und fetchCache
Die gute Nachricht: Der Umstieg ist gut dokumentiert und folgt klaren Ersetzungsregeln. Laut Migrations-Guide fällt dynamic = 'force-dynamic' ersatzlos weg, weil ohnehin alles dynamisch ist. Ein bisheriges revalidate = 3600 wird zu use cache plus cacheLife('hours'). fetchCache entfällt, weil innerhalb eines gecachten Scopes automatisch alle Fetches gecacht werden. Und force-static ersetzt man, indem man use cache so nah wie möglich an den Datenzugriff setzt. Der empfohlene Weg in der Praxis: das Flag aktivieren und den Build laufen lassen. Next.js meldet dann jede Stelle, an der ununcachter oder laufzeitabhängiger Datenzugriff auftaucht — man arbeitet die Fehler ab, statt blind umzubauen.
6. Zwei Fallstricke, die man kennen sollte
Zwei Verhaltensänderungen fallen erst im Detail auf. Erstens: Die Edge-Runtime wird nicht unterstützt. Cache Components setzen die Node.js-Runtime voraus; ein runtime = 'edge'-Export muss raus. Wer heute Edge-Rendering fährt, sollte das früh einplanen. Zweitens: Next.js bewahrt beim Navigieren jetzt den UI-Zustand über Reacts <Activity>-Komponente — Routen werden nicht mehr unmounted, sondern versteckt. Formularinhalte, Scroll-Position und useState-Werte überleben also einen Seitenwechsel und das Zurücknavigieren. Für einen Shop ist das oft erwünscht (Filter bleiben erhalten), kann aber Nebenwirkungen haben: Ein Dropdown, das sich früher beim Verlassen von selbst schloss, bleibt jetzt offen. Solche Stellen brauchen explizite Reset-Logik, etwa im Cleanup eines useLayoutEffect.
7. Fazit: Nicht neues Feature, sondern neues Fundament
Cache Components sind kein Feature, das man nebenbei einschaltet — sie verändern die Denkweise. Statt dynamische Seiten mühsam abzusichern, definiert man bewusst die wenigen Inseln, die gecacht werden dürfen, und lässt den Rest dynamisch. Für Shopware-Headless-Setups passt das erstaunlich gut, weil es exakt die Trennung erzwingt, die man ohnehin braucht: Katalog cachen, Warenkorb und Login niemals. Der Umbau ist überschaubar, wenn man ihn build-getrieben angeht und den Migrations-Guide als Checkliste nutzt. Wer heute ein Next.js-Frontend auf Shopware betreibt, sollte den Umstieg nicht als Pflichttermin sehen, sondern als Gelegenheit, das Caching endlich sauber und nachvollziehbar aufzustellen — statt es über verstreute Route-Configs zu erraten.
Steht bei dir der Umstieg auf Next.js 16 an?
Lass uns in 30 Minuten dein Shopware-Headless-Setup durchgehen — wo Cache Components sofort etwas bringen und wo Warenkorb und Login sauber dynamisch bleiben müssen. Kein Sales-Call.