CDN-Caching für Next.js: Cache-Header ohne Datenlecks

Warum CDN-Caching eine Next.js-App kaputtmachen kann

CDNs lassen Seiten schnell wirken, indem sie Kopien dessen speichern, was Ihr Server sendet, und diese Kopien von einem Ort in der Nähe des Besuchers ausliefern. Richtig umgesetzt reduziert das Ladezeit und Serverkosten. Nachlässig eingerichtet kann es Logins zerstören, falsche Daten zeigen oder sich später „zufällig“ wieder normalisieren.

Ein CDN kann zwei Arten von Dingen cachen:

• Dateien (Bilder, JS, CSS)
• Vollständige HTTP-Antworten (HTML einer Seite, JSON von einer API-Route)

Das Schwierige ist, dass eine Next.js-App oft sowohl öffentliche Seiten als auch benutzerspezifische Seiten unter derselben Domain ausliefert. Wenn Ihr CDN sie gleich behandelt, kann etwas gecacht werden, das niemals geteilt werden darf.

Zwei Probleme verursachen die meisten Kopfschmerzen:

• Veraltete Inhalte: Sie aktualisieren eine Seite, aber Nutzer sehen weiter die alte Version, weil sie gecacht wurde.
• Gecachte personalisierte Antworten: Das CDN speichert eine Antwort, die für eine Person bestimmt war, und liefert sie dann an jemand anderen aus.

Ein häufiges Fehlerszenario: Sie haben eine Marketing-Homepage und ein Dashboard unter /app. Ein Nutzer meldet sich an, besucht /app und der Server liefert HTML, das seinen Namen und letzte Aktivitäten enthält. Wird diese HTML-Antwort gecacht, kann der nächste Besucher, der /app aufruft, die Dashboard-Hülle des ersten Nutzers sehen oder in einer kaputten Auth-Schleife landen.

CDN-Caching für Next.js heißt deshalb nicht einfach „Caching einschalten“, sondern klare Regeln setzen: Entscheiden Sie, was sicher zu cachen ist (in der Regel statische Assets und wirklich öffentliche Seiten), was niemals gecacht werden darf (personalisiertes HTML, Auth-Flows und die meisten nutzerspezifischen APIs) und wie lange gecachte Inhalte leben sollen.

Ordnen Sie Ihre App in cachebare und nicht-cachebare Teile ein

Bevor Sie Header anfassen, kartieren Sie, was Ihre App tatsächlich ausliefert. CDN-Caching funktioniert am besten, wenn Sie jede Antwortart unterschiedlich behandeln. Eine einzige Regel für alles ist der Grund, warum Nutzerdaten versehentlich gecacht werden.

Beginnen Sie damit, die wichtigsten Antworttypen aufzulisten, die Sie zurückgeben:

• Statische Dateien (JS, CSS, Fonts)
• Bilder (einschließlich optimierter Varianten)
• HTML-Seiten (Marketing, Docs, Dashboards)
• API-Antworten (JSON, Webhooks, Auth-Callbacks)

Gruppieren Sie dann Ihre Routen danach, wie öffentlich sie wirklich sind:

Markieren Sie nun Bereiche mit hoher Fluktuation. Preise, Inventar und alles, was Live-Status anzeigt (Bestellungen, Nutzung, Nachrichten), kann schnell veralten. Dashboards sind offensichtliche Kandidaten, aber auch Checkout-Seiten, Onboarding-Schritte und sogar „Willkommen zurück“-Blöcke können personalisiert sein.

Verschiedene Inhaltstypen brauchen unterschiedliche Regeln, weil die Risiken unterschiedlich sind. Ein JS-Bundle aggressiv zu cachen ist in der Regel sicher. HTML zu cachen, das von Cookies abhängt, kann die Seite eines Nutzers für einen anderen sichtbar machen.

Ein reales Beispiel: Eine Seite hat eine öffentliche Marketing-Homepage, aber die Kopfzeile zeigt den Benutzernamen, wenn eingeloggt. Dieses Detail verwandelt eine ansonsten cachebare Seite in ein Risiko, es sei denn, Sie trennen die Erfahrung (öffentliche Hülle plus private Daten separat laden) oder deaktivieren das Caching, wenn Cookies vorhanden sind.

Statische Assets sicher cachen (JS, CSS, Fonts, Bilder)

Statische Assets sind der einfachste Gewinn, weil sie in der Regel pro Nutzer gleich sind. Denken Sie an Dateien, die der Browser herunterlädt und auf vielen Seiten wiederverwendet.

Typische statische Assets umfassen:

• Next.js-Build-Dateien unter /_next/static/ (JS-Chunks, CSS)
• Fonts und Icon-Dateien (woff2, ttf, svg)
• Bilder und Favicons
• Alles im public/-Ordner

Bei versionierten Dateien (mit Hash im Dateinamen) ist langes Caching die richtige Standardeinstellung. Der Hash ändert sich, wenn sich der Inhalt ändert, also ist die Datei effektiv unveränderlich.

Ein gängiger Header für diese ist:

Cache-Control: public, max-age=31536000, immutable

Bevor Sie eine einjährige TTL setzen, stellen Sie sicher, dass „immutable“ in Ihrer Umgebung wirklich zutrifft. Wenn Sie logo.png aus public/ ausliefern und später die Datei ersetzen, aber den gleichen Namen behalten, kann eine lange TTL dafür sorgen, dass Caches lange die alte Logo-Version halten. Für nicht-versionierte Dateinamen empfehlen sich kürzere TTLs oder ein Build-Schritt, der Dateinamen fingerprintet.

Bilder brauchen oft eine eigene Strategie. Wenn Sie mehrere Größen oder Formate generieren (z. B. WebP und AVIF), ist Caching nur sicher, wenn die finale URL die Variante eindeutig identifiziert. Variiert ein optimierter Bild-Endpunkt nach Breite, Qualität oder Format, müssen diese Eingaben Teil des Cache-Keys sein. Ansonsten erhalten Nutzer womöglich die falsche Variante.

Eine schnelle Plausibilitätsprüfung: Öffnen Sie ein JS-Chunk und eine Schriftdatei und bestätigen Sie, dass sie sich nur bei einem neuen Build ändern.

Seiten und HTML cachen: was sicher ist und was riskant

Der größte Gewinn (und das größte Risiko) ist das Cachen von vollständigem HTML. HTML ist das, was der Nutzer sieht – wenn Sie das Falsche cachen, zeigen Sie womöglich die falsche Person die falschen Inhalte.

Sicher zu cachenes HTML ist meistens Inhalt, der für alle gleich ist: Marketingseiten, Preise, Docs, öffentliche Landingpages, die meisten Blogposts. Ein einfacher Test: Öffnen Sie die Seite im Inkognito-Modus. Sieht sie beim Ein- und Ausloggen gleich aus? Dann ist sie ein guter Kandidat.

Riskantes HTML ist alles, was sich pro Nutzer, Session oder anhand privater Daten ändert: Dashboards, Kontoeinstellungen, Checkout, Bestellhistorie, Seiten, die einen Namen, eine E-Mail, gespeicherte Items, Zahlungsstatus oder „Sie haben sich zuletzt eingeloggt um...“ zeigen. CDN-Caching solcher Inhalte ist die Ursache für Datenleaks.

Eine einfache Faustregel:

• Cache öffentliche Seiten mit kontrollierten Lebensdauern.
• Cache keine Nutzerseiten, es sei denn, Sie sind sich zu 100 % sicher, dass die Antwort für alle identisch ist.
• Im Zweifelsfall behandeln Sie HTML als privat und deaktivieren Caching.

ISR (Incremental Static Regeneration) liegt in der Mitte: Next.js kann eine gecachte Seite schnell ausliefern und sie dann im Hintergrund nach einer Frist erneuern. Das ist großartig für gelegentlich geänderte Seiten wie Blogposts. Für persönliche Seiten ist es ungeeignet, denn Frische behebt nicht das Problem „falscher Nutzer“.

Ein weiteres Stolperfall: HTML-Caching ist nicht das gleiche wie das Cachen von Datenaufrufen. Eine Seite kann sicher gecacht werden, während eine API, die sie aufruft, nicht gecacht werden darf. Oder Sie machen HTML privat, cachen aber wirklich öffentliche Daten (z. B. Produktlisten) mit kurzer TTL. Wer beides vermischt, provoziert veraltete Inhalte oder versehentliche Offenlegung.

Cache-Header, die Sie kennen sollten (ohne Fachchinesisch)

Die meisten Caching-Probleme entstehen, weil CDN und Browser raten, wie lange etwas wiederverwendbar ist. Cache-Header sind die Art, wie Sie das klar sagen.

Cache-Control: der wichtigste Header

Cache-Control ist eine Reihe von Anweisungen. Die gebräuchlichsten Teile sind:

• max-age=...: wie lange der Browser es halten darf (Sekunden)
• s-maxage=...: wie lange gemeinsame Caches (CDN) es halten können. Wenn vorhanden, folgen CDNs normalerweise diesem Wert statt max-age.
• public: darf in einem geteilten Cache gespeichert werden
• private: nur der Browser des Nutzers darf es speichern (CDNs sollen es nicht)
• no-store: nirgendwo speichern (für persönliche oder sensible Antworten)

Eine einfache Regel: Wenn die Antwort sich je nach Nutzer unterscheiden kann, vermeiden Sie public. Für Dashboards und Kontoseiten standardmäßig no-store verwenden, sofern kein sehr spezifischer Grund dagegenspricht.

stale-while-revalidate: alte Version zeigen, im Hintergrund aktualisieren

stale-while-revalidate=... erlaubt einem Cache, eine leicht veraltete Version für kurze Zeit auszuliefern, während er eine frische im Hintergrund holt.

Das passt gut zu Inhalten, die ein bisschen hängen dürfen (z. B. Marketing-Homepage). Für Dinge, die jetzt korrekt sein müssen (Abrechnung, Berechtigungen), ist es riskant.

ETag und Last-Modified: wie Caches prüfen, ob etwas geändert wurde

Mit ETag oder Last-Modified kann ein Cache nachfragen: „Hat sich das geändert?“ Wenn nicht, antwortet der Server mit einer kleinen „not modified“-Antwort, statt den ganzen Body neu zu senden.

Das ist wichtig, wenn Antworten groß sind, Inhalte oft aktualisiert werden oder Sie schnelle Updates möchten, ohne Caching auszuschalten.

Vary: das „hängt von ... ab“-Label

Vary sagt Caches, von welchen Request-Headern die Antwort abhängt. Das ist wichtig, wenn Cookies oder Auth beteiligt sind.

Wenn HTML sich anhand des Login-Status ändert und Sie Vary plus Caching-Regeln nicht korrekt handhaben, kann ein CDN die Version eines Nutzers einem anderen ausliefern. Häufige Vary-Header sind Cookie, Authorization und Accept-Encoding.

Schritt-für-Schritt: Cache-Regeln für eine typische Next.js-App

Eine praktische Vorgehensweise ist: Mit den sichersten Dingen anfangen und sich dann zu den Änderlichen vorarbeiten.

1) Mit den sichersten Zielen starten

Beginnen Sie mit Dateien, die für alle gleich sind: JavaScript-Bundles, CSS, Fonts und versionierte Bilder. Diese sind risikoarm und bringen meist den größten Geschwindigkeitsgewinn.

2) Cache-Zeiten nach Änderbarkeit setzen

Verwenden Sie sehr lange Cachingzeiten für unveränderliche Assets (Dateien, die ihren Namen ändern, wenn sich der Inhalt ändert). Für Seiten und HTML verwenden Sie kürzere Zeiten, weil Inhalte ohne Namensänderung aktualisiert werden können.

Eine Checkliste, die in der Praxis funktioniert:

• Starten Sie mit /_next/static/*, klar versionierten Assets und anderen Dateien mit Hash im Namen.
• Für unveränderliche Assets lange Cache-Control-Werte plus immutable senden.
• Für öffentliche, nicht personalisierte Seiten (Marketing, Docs) eine kürzere gemeinsame Cache-Zeit (Minuten bis Stunden) und stale-while-revalidate in Betracht ziehen.
• Für alles nutzerspezifische (Dashboards, Kontoseiten, API-Routen, die von Cookies abhängen) Cache-Control: private oder no-store erzwingen.
• Entscheiden Sie, wie Sie Cache-Busting machen: auf Deploys setzen, die Asset-Dateinamen ändern, und einen klaren Purge-Plan für HTML haben, wenn Sie dringende Updates ausrollen.

3) Testen, bevor Sie vertrauen

Hören Sie nicht bei „es lädt schnell“ auf. Machen Sie ein Hard-Refresh und vergleichen Sie ausgeloggtes vs. eingeloggtes Verhalten.

Eine schnelle Realitätsschau: Öffnen Sie dieselbe Seite im Inkognito-Fenster und in einer eingeloggten Session. Wenn HTML, Header oder sichtbare Daten jemals übereinstimmen, obwohl sie es nicht sollten, behandeln Sie das als Leak und stoppen Sie das Caching dieser Route.

CDN-Cache-Keys und Regeln, die entscheiden, was ausgeliefert wird

Ein CDN cached eine Antwort nicht „abstrakt“. Es cached sie unter einem Cache-Key. Dieser Schlüssel wird meist aus dem Request-Pfad und manchmal Query-String, Headern und Cookies gebildet.

Ist der Key zu breit, sehen Nutzer falsche Inhalte. Ist er zu spezifisch, sinkt die Cache-Trefferquote und Seiten werden langsamer.

Was normalerweise in den Cache-Key gehört

Starten Sie einfach: Für öffentliche Seiten reicht oft der Pfad. Fügen Sie nur dann weitere Teile hinzu, wenn sie wirklich verändern, was der Nutzer sehen soll.

• Pfad: /pricing vs /blog/slug sollten getrennt sein.
• Query-Parameter: Nur solche einschließen, die Inhalte verändern (z. B. ?page=2). Tracking-Params wie utm_* ignorieren.
• Header: Nur echte Varianten einbeziehen (z. B. Sprache).
• Cookies: Für öffentliche Inhalte vermeiden. Sie explodieren die Anzahl von Cache-Varianten.

Das gefährliche Szenario ist, wenn ein CDN eine personalisierte Antwort cached, weil ein Cookie vorhanden war. Selbst wenn der Cookie nicht Teil des Keys ist, kann das Cachen einer personalisierten Antwort Daten leaken.

Varianten: Locale und Gerät

Wenn Ihr HTML je nach Locale anders ist, verwenden Sie ein klares Signal und Vary darauf (oft Accept-Language oder ein eigener Header, den Sie kontrollieren).

Seien Sie vorsichtig bei gerätebasierter Variation. Auf User-Agent zu variieren erzeugt zu viele Versionen und ist leicht fehleranfällig. Bevorzugen Sie responsives Design oder einen kleinen, expliziten Header, wenn Sie wirklich separate HTML-Versionen benötigen.

Schließlich setzen Sie Bypass-Regeln für alles, was niemals gecacht werden sollte: /admin, /api-Routen, die personenbezogene Daten zurückgeben, authentifizierte Dashboards und jede Route, die ein Session-Cookie prüft.

Wie Sie das Cachen personalisierter Antworten vermeiden

Ein CDN ist großartig, bis es versehentlich eine für eine Person bestimmte Antwort speichert und an jemand anderen ausliefert. Das ist das größte Risiko: gecachtes HTML oder JSON kann zu einem Datenleck werden, wenn es Namen, E-Mails, Zahlungsstatus oder andere sessiongebundene Daten enthält.

Personalisierung schleicht sich meist über Cookies und Auth-Header ein. Wenn eine Anfrage Cookie oder Authorization enthält, gehen Sie davon aus, dass sie nutzerspezifische Ausgabe erzeugen kann, sofern Sie nicht absolut sicher sind, dass das nicht der Fall ist.

Verwenden Sie klare Cache-Header für alles, was hinter einer Anmeldung liegt. Für Dashboards, Einstellungen, Abrechnungsseiten und nutzerspezifische API-Routen bevorzugen Sie Cache-Control: no-store (oder zumindest private, no-store). Das sagt Browsern und CDNs, dass keine Kopie aufbewahrt werden darf.

Praktische Warnsignale, die Sie zum Nicht-Cachen bewegen sollten:

• Die Anfrage enthält Cookie, Authorization oder einen Session-Token-Header.
• Die Antwort hängt davon ab, wer der Nutzer ist (auch wenn die URL gleich bleibt).
• Das HTML enthält Kontodaten, letzte Aktivitäten oder Abrechnungsstatus.
• Eine API liefert Nutzer-Datensätze, Tokens oder etwas Sensibles.
• Sie können Ihren CDN-Cache-Key nicht in einem Satz erklären.

Gemischte Seiten sind knifflig. Ein gängiges Muster ist eine öffentliche Marketing-Hülle, die bei eingeloggten Nutzern „Hi Sam“ oder eine Benachrichtigungszahl zeigt. Wenn das HTML personalisiert ist, cachen Sie es nicht öffentlich. Eine sichere Lösung: die öffentliche Hülle cachen und personalisierte Fragmente clientseitig (oder von einem separaten uncachebaren Endpunkt) nachladen.

Wenn möglich, trennen Sie öffentliche und private Endpunkte, damit Ihre Regeln einfach bleiben. Halten Sie cachebare Routen klar öffentlich und authentifizierte Routen klar uncachebar.

Häufige Fehler, die zu veralteten Inhalten oder Datenleaks führen

Die meisten Caching-Fehler passieren, wenn etwas in einem schnellen Test „schnell“ wirkte, aber im echten Betrieb anders läuft. Die Gefahr ist nicht nur veraltete Seiten, sondern auch, dass man die Inhalte einer Person einem anderen zeigt.

Wiederkehrende Fehler:

• HTML für eingeloggte Routen cachen, weil es beim anonymen Test sicher wirkte.
• Antworten als public markieren, obwohl sie sich abhängig von Cookies, einem Auth-Header oder Geolocation ändern.
• Langes max-age für nicht-versionierte Assets (z. B. /app.css) vergeben und dann ein Update ausliefern, während Nutzer die alte Datei behalten.
• Vergessen, dass Redirects, Fehlerseiten und 404s ebenfalls gecacht werden können, was einen temporären Ausfall oder falsche Routen festsetzt.
• Dem Standardverhalten von Hosting oder Framework vertrauen, ohne zu prüfen, was das CDN tatsächlich speichert.

Eine schnelle Risiko-Frage: „Könnte diese Antwort für zwei Nutzer unterschiedlich sein?“ Wenn ja, sollte sie nicht öffentlich gecacht werden. Schon eine kleine Abweichung wie eine Begrüßung bedeutet: HTML ist personalisiert.

Achten Sie auch auf unsichtbares Caching: ein gecachter 302-Redirect zu /login, ein gecachter 404 für eine frisch veröffentlichte Seite oder ein gecachter 500-Fehler während eines Deploys.

Schnelle Prüfungen, bevor Sie Caching in Produktion freischalten

Bevor Sie Caching ausrollen, testen Sie mit echten Requests, nicht nur mit dem, was Sie für Ihr Codeverhalten erwarten. Kleine Header-Fehler können zu veralteten Seiten oder – schlimmer – falschen Nutzerinhalten führen.

Beginnen Sie mit dem Wesentlichen:

• Öffentliche Seiten, die für alle gleich sind, sollten Cache-Control: public und eine sinnvolle s-maxage senden, damit das CDN sie cachen kann.
• Alles hinter einer Anmeldung sollte Cache-Control: private oder no-store sein, niemals public.

Wenn Sie unsicher sind, wählen Sie no-store und lockern das später.

Vor-Produktion-Checks, die die meisten Probleme finden:

• Öffnen Sie eine öffentliche Seite und bestätigen Sie, dass sie wirklich cachebar ist (Cache-Control: public mit s-maxage).
• Öffnen Sie eine authentifizierte Seite und bestätigen Sie, dass sie nicht in einem Shared-Cache liegt (private oder no-store, niemals public).
• Prüfen Sie statische Assets: Langes Caching ist nur sicher, wenn Dateinamen versioniert sind (Hash im Namen). Falls nicht, kurz cachen.
• Rufen Sie APIs auf, die Nutzerdaten zurückgeben, und prüfen Sie, dass sie nicht vom CDN gecacht werden.
• Testen Sie zwei Accounts: Account A in einem Browser, Account B in einem anderen, und laden Sie dieselben URLs. Es darf nichts Persönliches übergehen.

Behalten Sie Query-Parameter im Blick. Wenn Ihr CDN nach kompletter URL cached, erzeugen ?ref=, ?utm_ und zufällige Filter endlose Varianten. Entscheiden Sie, welche Params ignoriert werden sollen und welche Teil des Cache-Keys sein müssen.

Ein realistisches Beispiel: Marketingseite + Dashboard auf derselben Domain

Ein Startup rollt eine Next.js-App aus, die eine öffentliche Marketingseite und ein eingeloggtes Dashboard unter derselben Domain kombiniert. Der Traffic steigt nach Releases, also fügen sie ein CDN hinzu, um Seiten schnell zu halten.

Sie teilen die App in zwei Gruppen.

Cache, was sicher und für alle gleich ist:

• Versionierte JS- und CSS-Dateien (langes Caching, weil Dateinamen sich beim Deploy ändern)
• Bilder, Fonts und Icons (langes Caching, wenn Dateinamen versioniert sind; kürzer, wenn Dateien überschrieben werden)
• Marketingseiten wie /, /pricing, /blog (kurze CDN-TTL, damit Änderungen schnell sichtbar sind)

Für Marketing-HTML setzen sie eine kurze gemeinsame Cache-Zeit und ein kleines stale-while-revalidate-Fenster. Das CDN kann eine etwas ältere Seite kurz ausliefern, während es aktualisiert.

Nie cachen, was nach Nutzer variiert:

• /dashboard und alles darunter
• Einstellungen und Abrechnungsseiten
• /api/user (und alles, was Kontodaten zurückgibt)
• Auth-Seiten und Callbacks

Um sicherzustellen, dass kein Datenleck entstanden ist, testen sie „paranoid“: zwei Accounts, zwei Browser, harter Refresh und Header-Check. Personalisierte Seiten dürfen niemals public-Cache-Header zeigen.

Wenn etwas schiefgeht (ein Nutzer sieht einen falschen Namen oder veralteten Abonnement-Status), rollen sie zuerst die CDN-Regel zurück. Dann verschärfen sie Header auf riskanten Routen (zuerst /dashboard und /api), bevor sie Caching wieder aktivieren.

Nächste Schritte: sicher ausrollen und Hilfe holen, wenn es chaotisch ist

Fangen Sie klein an und machen Sie die Erfolge langweilig. Cachen Sie unveränderliche statische Assets (gehashte JS/CSS, Fonts, versionierte Bilder) mit langen TTLs. Wenn das stabil ist, fügen Sie Caching für wirklich öffentliche Seiten hinzu. Behandeln Sie alles, was sich nach Nutzer, Cookie oder Auth ändert, als uncachebar, sofern Sie nicht ausdrücklich für Edge-Caching designen.

Schreiben Sie Ihre Cache-Regeln in einfachem Deutsch auf. Viele Caching-Bugs entstehen Monate später, wenn jemand einen Header hinzufügt, einen Redirect einführt oder Auth ändert. Ein kurzes „Caching-Vertrag“-Dokument macht Reviews einfacher: was ist cachebar, was darf niemals gecacht werden, und welche Signale (Cookies, Header, Query-Params) ändern die Antwort.

Wenn Sie eine KI-generierte Next.js-Codebasis geerbt haben, prüfen Sie Header und Auth-Flows genau. Solche Projekte liefern oft uneinheitliche Routenmuster, inkonsistente Cache-Control-Angaben und Sessions, die lokal funktionieren, aber hinter einem CDN auseinanderfallen.

Wenn Sie kaputte Authentifizierung, riskantes Caching oder Unsicherheit darüber sehen, was Ihr CDN speichert: FixMyMess (fixmymess.ai) bietet Codebasis-Diagnose und Reparaturen für KI-generierte Apps an, inklusive Entwirrung von Cache-Headern und Auth-Grenzen. Sie bieten auch ein kostenloses Code-Audit, um Probleme zu identifizieren, bevor Sie etwas in Produktion ändern.