Was ist Cache-Busting?

Cache-Busting veröffentlicht geänderte Inhalte unter einer neuen URL, meist mit einem Inhalts-Hash oder einer Versionskennung im Dateinamen, Pfad oder Query-String. HTTP-Caches suchen gespeicherte Antworten anhand der URL. Eine Anfrage an die neue Adresse kann daher nicht mit der unter der alten Adresse gespeicherten Kopie beantwortet werden, solange kein Cache so konfiguriert ist, dass er den geänderten URL-Teil ignoriert.

Ein HTTP-Cache verwendet eine gespeicherte Antwort erneut, solange sie frisch ist, ohne den Origin-Server zu kontaktieren. Eine Datei, die mit langer Gültigkeitsdauer über max-age ausgeliefert wird, erzeugt daher keine weiteren Anfragen, über die der Server sie ersetzen könnte. Ein CDN-Cache lässt sich meist leeren, doch das erreicht keine Kopien, die Browser bereits gespeichert haben. Cache-Busting umgeht beide Probleme. Laut Spezifikation enthält ein Cache-Schlüssel mindestens die Anfragemethode und die URL; manche CDNs lassen sich so konfigurieren, dass sie den Query-String auslassen. Für eine URL, deren Schlüssel nicht gespeichert wurde, gibt es keine gespeicherte Antwort. Deshalb muss jeder Cache die Anfrage in Richtung Origin-Server weiterleiten. In der Praxis erhalten die versionierten Dateien eine lange Gültigkeitsdauer über max-age (das MDN-Beispiel verwendet ein Jahr, max-age=31536000), optional mit immutable. Das Dokument, das auf sie verweist, wird dagegen mit no-cache ausgeliefert. So muss ein Cache es vor der erneuten Verwendung revalidieren, und beim erneuten Laden der Seite werden die aktuellen Dateinamen abgerufen. MDN weist darauf hin, dass no-cache bei der Navigation im Browserverlauf keine Revalidierung garantiert. Die Zurück-Schaltfläche kann daher eine frühere Seite wiederherstellen. Bundler wie webpack und Vite erzeugen die Dateinamen mit Hash beim Build.

Dateiname oder Query-String? Sowohl app.3f9a1c.js als auch app.js?v=3f9a1c ändern die URL. Eine Version im Query-String funktioniert jedoch nur, wenn jeder Cache auf dem Weg den Query-String in seinem Cache-Schlüssel behält. Das standardmäßige Caching-Level Standard von Cloudflare tut dies. Das Level Ignore Query String liefert dagegen unabhängig vom Query-Wert dieselbe zwischengespeicherte Kopie einer statischen Datei aus. Amazon CloudFront berücksichtigt Query-Strings beim Caching nur, wenn die Distribution entsprechend konfiguriert ist. Bei Backend-Buckets von Google Cloud CDN muss der Versionsparameter auf einer Einschlussliste stehen. Bei einer Version im Query-String bleibt zudem meist eine einzige Datei auf dem Origin-Server, die bei jedem Release überschrieben wird. Fordert eine Seite des vorherigen Releases nach einem Cache-Miss ihre alte URL ?v= an, erhält sie daher die Datei des neuen Releases. Die Anleitung zu Cloud CDN von Google empfiehlt stattdessen eindeutige Dateinamen, da eine am selben Speicherort aktualisierte Datei im unvollständigen Zustand zwischengespeichert werden kann.
Behalten unveränderte Dateien ihre URL über Releases hinweg? Mit einem Inhalts-Hash ja, sofern der Build identische Bytes erzeugt. Eine Release-Nummer oder ein Zeitstempel in jedem Pfad ändert dagegen bei jedem Release sämtliche URLs und verwirft zwischengespeicherte Kopien unveränderter Dateien. Ein Hash kann sich auch bei einer Datei ändern, deren Quelltext unverändert blieb: Die Caching-Anleitung von webpack zeigt, wie sich [contenthash] eines Vendor-Bundles nach dem Hinzufügen eines unabhängigen Moduls ändert, weil die Modul-IDs der Auflösungsreihenfolge folgten. Die Anleitung weist darauf hin, dass der Produktionsmodus von webpack 5 standardmäßig deterministische Modul-IDs verwendet, und lagert außerdem die Laufzeit in einen eigenen Chunk aus.
In welcher Reihenfolge sollte ein Deployment erfolgen? Laden Sie zuerst die neuen versionierten Dateien hoch und veröffentlichen Sie zuletzt das Dokument, das auf sie verweist. Die Anleitung zu Cloud CDN von Google bezeichnet es als entscheidend, Abhängigkeiten vor den Dateien hochzuladen, die auf sie verweisen. Halten Sie auch die Dateien des vorherigen Releases verfügbar: Eine vor dem Deployment geladene Seite fordert weiterhin die alten Namen an. Sowohl webpack als auch Vite dokumentieren fehlgeschlagene Chunk-Ladevorgänge oder Importfehler, wenn ein Deployment diese Dateien löscht. Die webpack-Anleitung empfiehlt, alte Dateien nach etwa einem Tag durch das CDN ablaufen zu lassen statt beim nächsten Deployment. Falls ein Chunk weiterhin nicht geladen werden kann, sollte die Seite höchstens einmal neu geladen werden, da ein Tab länger geöffnet bleiben kann als die Aufbewahrungsfrist.
Was bewirkt immutable zusätzlich zu einer langen Gültigkeitsdauer mit max-age? Es weist Clients an, die Datei beim Neuladen nicht zu revalidieren, solange sie noch frisch ist. Das spart bedingte Anfragen, die lediglich 304 zurückgeben würden. Es verlängert die Gültigkeitsdauer nicht und ist nur dann korrekt, wenn sich die Datei unter dieser URL nicht ändert, solange die Antwort frisch ist, etwa bei einem Dateinamen mit Hash, dessen Datei nie überschrieben wird. MDN weist darauf hin, dass Chrome die Direktive nicht implementiert und stattdessen beim Neuladen auf die Revalidierung von Unterressourcen verzichtet.

Verwenden Sie Cache-Busting für Unterressourcen wie Skripte, Stylesheets und Bilder, die Browser und CDNs lange speichern, aber direkt nach einem Release aktualisieren sollen. Es lässt sich nicht auf eine URL anwenden, die unverändert bleiben muss, etwa die des HTML-Dokuments, das auf diese Dateien verweist. Liefern Sie dieses Dokument mit no-cache aus, damit Browser es bei jedem erneuten Laden der Seite revalidieren. Wenn das CDN so eingerichtet ist, dass es das Dokument ohne Revalidierung aus seinem eigenen Cache ausliefert, löschen Sie diese Kopie ebenfalls bei jedem Deployment. Das Leeren des CDN-Caches allein aktualisiert Browser nicht. Jeder neue Cache-Schlüssel startet ohne gespeicherte Antwort: Jeder Cache muss die Datei einmal vom Origin-Server oder von einem Cache näher am Origin-Server abrufen, bevor er sie ausliefern kann.

Transloadits Smart CDN gibt jeder transformierten Variante eine eigene URL: Der Workspace, der Template-Name, der Quelldateipfad und die Transformationsparameter sind alle Teil der Adresse tlcdn.com. Eine Anfrage für eine andere Größe oder ein anderes Format ändert daher die URL und erzeugt eine separat zwischengespeicherte Variante. Ein Cache-Treffer für dieselbe URL verwendet dagegen das zwischengespeicherte Ergebnis erneut, statt das Template erneut auszuführen. Bei signierten URLs ist die effektive Cache-Gültigkeitsdauer einer Antwort durch die verbleibende Gültigkeitsdauer der Signatur begrenzt.

Die hier verlinkten Seiten beschreiben weder einen Vorgang zum Leeren des Caches noch, was mit einem zwischengespeicherten Ergebnis passiert, wenn das Original unter unverändertem Dateipfad ersetzt wird. Wird ein Ersatzoriginal unter einem neuen Pfad gespeichert, ändert sich die URL von Smart CDN. Testen Sie den Fall mit unverändertem Pfad in Ihrem eigenen Workspace, bevor Sie sich darauf verlassen.

Entdecken Sie Transloadits Möglichkeiten zur Auslieferung

Was ist Cache-Busting?

So funktioniert Cache-Busting

Wichtige Fakten

Wann Cache-Busting wichtig ist

Wie Transloadit bei Cache-Busting hilft

Quellen

Machen Sie aus Medienwissen eine funktionierende Pipeline