CDN- und Browser-Cache nach einem Release prüfen

Ein CDN-Purge löscht keine Dateien, die bereits im Browser liegen. Prüfe den Antwortpfad, bevor du breit purgst oder die TTL erhöhst.

HTML und versionierte Assets vergleichen

• Rufe Seite und Asset in einer sauberen Browsersitzung ab. Notiere Status, Age, Cache-Control, ETag/Last-Modified und CDN-Cache-Status, falls vorhanden.
• Prüfe HTML-Revalidierung und lange Cache-Zeit für gehashte JS/CSS-Dateien. Verwende kein einjähriges immutable für veränderliche URLs.

Nur die veraltete Cache-Schicht leeren

• Liefert das CDN alte Bytes, purge die genaue URL oder Version und prüfe aus zwei Netzen. Ist nur ein Browser veraltet, teste ein frisches Profil vor einer Edge-Regeländerung.
• Prüfe öffentliche und angemeldete Seiten getrennt. Personalisierte Antworten dürfen nicht in gemeinsam genutzte Caches; sichere Header und Rollback der Regel.

Beispiel und erwartetes Ergebnis

• Rufe die Seite mit curl -sS -D page.headers -o page.html PAGE_URL ab; nutze für das gehashte Asset andere Namen wie asset.headers und asset.bin. Prüfe die gespeicherte page.html oder vergleiche die Build-Kennung mit dem Origin. Wiederhole beide GET-Anfragen nach dem Deployment und vergleiche Age sowie den CDN-Statusheader; prüfe auch Cache-Control und ETag. HTML wird möglicherweise standardmäßig nicht gecacht; prüfe zuerst die Website-Regeln.
• Ist nur ein Browserprofil veraltet, prüfe Service Worker und lokalen Cache. Bei altem CDN-HIT leere nur den betroffenen Pfad und teste in einem frischen Profil. Ist auch der Origin veraltet, behebe zuerst das Deployment.

Primärquellen

• Cloudflare · Cache-Control and origin caching
• Cloudflare · Default cache behavior