Die Produktseite zeigt den alten Preis nach einer Flash-Promo – der Support gibt „dem CDN“ die Schuld. In Wirklichkeit sendet PHP „Cache-Control: public, max-age=3600“ im Katalog-HTML, Cloudflare respektiert diese Anweisung und nur die Warenkorb-API gibt „no-store“ zurück. JavaScript-Assets bleiben dank des Hashs im Dateinamen aktuell; Der HTML-Katalog bleibt eine ganze Stunde lang eingefroren. Niemand hat dokumentiert, welche Schicht welche Ressource zwischenspeichert.
HTTP-Cache-Header sind der Vertrag zwischen Ihrem Ursprung, dem CDN und dem Browser. Bei einer Fehlausrichtung zahlen Sie mehrfach: Latenz für den Benutzer, Ursprungsaufwand oder veraltete Inhalte, die das Vertrauen schwächen. Ein ohne eine kohärente Richtlinie aktiviertes CDN fügt einen Netzwerkschritt hinzu, ohne den Vorteil zu verlieren.
Die Suite legt eine Ressource-für-Ressource-Matrix fest – keinen „Cache-aktivierten“ Schieberegler im Hosting-Panel.
Cache-Control: die Anweisungen, die wirklich wichtig sind
„Cache-Control“ ist die von Browsern und CDNs am häufigsten gelesene Anweisung. Jedes Schlüsselwort hat eine bestimmte Wirkung:
| Richtlinie | Wirkung |
|---|---|
max-age=N | Ressource wird auf Browserseite als neue N Sekunden betrachtet |
s-maxage=N | Gleiche Logik, aber für gemeinsam genutzte Caches (CDN) |
| „no-store“ | Keine Speicherung – sensible Daten, Kontoseiten |
| „kein Cache“ | Autorisierte Lagerung, obligatorische erneute Validierung vor der Verwendung |
| „unveränderlich“ | Fingerabdruck des Vermögenswerts – keine unnötige erneute Validierung |
stale-while-revalidate | Bereitstellung einer veralteten Version während einer asynchronen Aktualisierung |
Für dynamisches HTML (Katalog, Artikel, personalisierte Seiten) bevorzugen Sie „privat, ohne Cache“ oder ein kurzes „Max-Alter“ in Verbindung mit einer erneuten Validierung. Für statische Assets mit einem Hash im Namen („/app.abc123.js“) ist „public, max-age=31536000, immutable“ der erwartete Standard.
Ein CDN errät Ihre Absicht nicht – es befolgt die Header, es sei denn, es gibt eine explizite Überschreibungsregel im Panel.
Überprüfen Sie bei Shared Hosting oder einem VPS mit integriertem CDN (OVH, Infomaniak usw.), dass die Panel-Regeln nicht im Widerspruch zu dem stehen, was Ihre Bewerbung sendet. Konflikte zwischen Nginx, PHP und dem CDN sind eine der häufigsten Ursachen für veraltete Inhalte.
CDN, Ursprung und die Vary-Header-Trap
Der Vary-Header teilt dem Cache mit, welche Dimensionen der Anfrage die Antwort beeinflussen. Zwei Fälle tauchen immer wieder auf:
Variieren: Accept-Encoding – unerlässlich, wenn Sie je nach Client Brotli und gzip bereitstellen. Ohne Vary kann ein CDN die gzip-Version zwischenspeichern und sie einem Client bereitstellen, der Brotli erwartet.
Vary: Accept – erforderlich, wenn Sie das Bildformat (WebP, AVIF) über den Accept-Header aushandeln. Ohne Vary kann das CDN ein AVIF für einen Browser bereitstellen, der es nicht unterstützt. Die vollständige Strategie finden Sie unter WebP und AVIF.
Konfigurieren Sie den Cache-Schlüssel auf der CDN-Seite: Kodierung einschließen, Sitzungscookies für öffentliche Assets ausschließen. Ein „Set-Cookie“ auf einer CSS-Datei kann bei einigen Anbietern Edge-Caching verhindern.
ETag, 304 Antworten und Laden beim Ursprung
Durch die bedingte erneute Validierung können Sie das erneute Herunterladen einer unveränderten Datei vermeiden. Der Client sendet „If-None-Match“ mit dem empfangenen ETag; Der Server antwortet 304 ohne Text, wenn der Inhalt identisch ist.
In einem Cluster mit mehreren Knoten wird ein maschinell generierter ETag (Inode, Zeitstempel) inkonsistent: Der Client erhält 200 statt 304 und der Ursprung übernimmt die Last. Bevorzugen Sie einen stabilen Inhalts-Hash oder delegieren Sie den Cache mit langen Laufzeiten für Fingerabdruck-Assets an das CDN.
Für eine Benutzer-JSON-API („/api/me“, „/api/orders“) bleibt „No-Store“ oder ein sehr kurzer Cache mit Schlüssel pro Benutzer die Norm. Ein gemeinsam genutzter CDN-Cache auf diesen Routen legt private Daten offen.
Strategie nach Ressourcentyp
Jeder Dateityp verdient seine eigene Richtlinie – dokumentiert, getestet, mit dem Team geteilt:
| Ressource | Empfohlene Richtlinie |
|---|---|
| CSS/JS mit Hash | 1 Jahr, „unveränderlich“ |
| Statische Bilder | 7 bis 30 Tage + gezielte Bereinigung bei Bereitstellung |
| Öffentliches HTML | kurz „max-age“ + „stale-while-revalidate“ oder „no-cache“ |
| Benutzer-API | „privat, kein Geschäft“ |
| Feeds, Sitemaps | Kurze „Max-Age“- oder ETag-Revalidierung |
In WordPress ändern Plugins Header ohne Koordination – prüfen Sie den „wp_headers“-Filter und vergleichen Sie, was Nginx, PHP-FPM und das CDN zurückgeben. Ein Seiten-Cache-Plugin kann mit einem Minifizierungs-Plugin in Konflikt geraten, das Dateinamen ändert.
Vergleichen Sie diese Lesart für die Bereitstellung und Ungültigmachung mit HTTP/2 und Multiplexing: Weniger Verbindungen gleichen schlecht zwischengespeicherte Assets nicht aus.
Bereinigung, Bereitstellung und klassische Fehler
Bei jedem Audit treten drei Fehler wieder auf:
- Vergessen Sie die CDN-Bereinigung nach der HTML-Bereitstellung ohne Fingerabdruck – der Besucher sieht stundenlang die alte Version.
Cache-Control: max-age=0ohneno-store– unterschiedliches Verhalten je nach CDN; sowieso irgendein Laden.- Cookies für Assets – „Set-Cookie“ für eine statische Datei kann Edge-Caching blockieren.
Testen Sie systematisch mit „curl -I“ von der CDN-Kante und vom Ursprung aus. Die Header müssen identisch sein oder der Unterschied muss dokumentiert werden (TLS-Terminierung zum CDN, Komprimierung usw.).
Vergleichen Sie Angebote mit integriertem CDN über unser Verzeichnis und den Vergleich – einige Hosts legen Standardregeln fest, die Sie vor der Bereitstellung kennen sollten.
Oben: CDN aktiviert, nichts zwischenspeicherbar
Folgendes sagt das Kontrollkästchen „CDN aktiviert“ im Panel nicht aus.
Um die drei Ebenen zur Zusammenarbeit zu bewegen, müssen Sie akzeptieren, dass jeder Dateityp seine eigene Richtlinie hat – und keine globale „Cache-Ein“-Einstellung.
Entscheide dich und gehe ohne blinden Fleck voran
In einem halben Tag können Sie den Cache wieder auf ein gesundes Fundament stellen:
- Zeichnen Sie eine Matrix-Ressource → Direktive („Cache-Control“, „Vary“, Dauer) und teilen Sie sie mit dem Team.
- Statische Fingerabdruck-Assets (Hash im Namen), um lange Zeiträume ohne blindes Löschen zu ermöglichen.
- Überprüfen Sie die Vary-Header, wenn Sie Komprimierung oder Bildformat aushandeln.
- Test mit „curl -I“ von Kante und Ursprung – dokumentieren Sie erwartete Abweichungen.
- Planen Sie eine gezielte Bereinigung für jede HTML-Bereitstellung, niemals eine „Alles bereinigen“ ohne eine Rollback-Warteschlange.
- Vergleichen Sie Hosts mit CDN über das Verzeichnis, wenn Sie Ihren Stack migrieren oder neu aushandeln.
Besorgen Sie sich für eine schnelle Prüfung eine HTML-URL und eine JS-Datei – die Header sollten über alle drei Ebenen hinweg konsistent sein. Wenn Sie bereits bei einem europäischen Spieler hosten, konsultieren Sie dessen Profil auf Hébergeurs.eu, um die Standard-CDN-Regeln herauszufinden.
Häufig gestellte Fragen
öffentlich vs. privat vs. kein Laden?
„public“ ermöglicht es dem CDN, die Antwort für alle Besucher zwischenzuspeichern. „privat“ beschränkt die Speicherung auf den Browser des Benutzers – geeignet für Kontoseiten. „no-store“ verbietet jegliche Speicherung sensibler Daten, auch im Arbeitsspeicher. „No-Cache“ ermöglicht die Speicherung, erfordert jedoch vor der Verwendung eine erneute Validierung.
maximales Alter und maximales Alter?
„max-age“ gilt für den Browser; s-maxage zu freigegebenen Caches wie CDN. Bei einem versionierten Asset („/app.abc123.js“) vermeidet ein langes „max-age“ in Verbindung mit „immutable“ unnötige Anfragen. Dynamisches HTML verdient kurze Zeiträume oder eine systematische Neuvalidierung.
Wie kann ich nach der Bereitstellung ungültig machen?
Versehen Sie die Dateien mit einem Fingerabdruck (Hash im Namen), bereinigen Sie das CDN gezielt auf den betroffenen URLs oder fügen Sie einen Versionsparameter hinzu. Vermeiden Sie eine vollständige Bereinigung in der Produktion ohne Rollback-Plan – es kann den Ursprung überlasten, wenn der gesamte Datenverkehr auf Fehler zurückgeht.
ETag oder Last-Modified?
Das ETag ermöglicht eine präzise bedingte Revalidierung (304-Antwort ohne Text). „Last-Modified“ funktioniert auch, aber der auf einem Inhalts-Hash basierende ETag ist in Clustern zuverlässiger. Hüten Sie sich vor maschinell generierten ETags – sie machen die erneute Validierung wirkungslos.
Der effektive Cache wird in den Headern gelesen – nicht in der CDN-Checkbox des Hosting-Panels.