Was ist Cache-Invalidierung?
Die Cache-Invalidierung entfernt Cache-Einträge oder markiert sie vor ihrem regulären Ablauf als veraltet. Spätere Anfragen lösen einen erneuten Abruf oder eine Revalidierung beim Origin-Server aus. Ein lediglich als veraltet markierter Eintrag kann je nach Cache-Richtlinie zwischenzeitlich weiterhin ausgeliefert werden.
So funktioniert die Cache-Invalidierung
Die Invalidierung ändert den Cache-Zustand, ohne dass Herausgeber den Ablauf der Frischedauer abwarten müssen. HTTP selbst bietet dafür wenig: Ein Cache invalidiert eine URL, wenn eine erfolgreiche Anfrage für diese URL mit einer nicht sicheren Methode wie PUT, POST oder DELETE ihn durchläuft. Das betrifft nur die Caches auf dem Weg dieser Anfrage, und keine Direktive im Header Cache-Control kann eine bereits gespeicherte Antwort löschen. CDNs bieten daher eine eigene Steuerungsebene, die gezielt einzelne URLs, Präfixe, Tags oder eine ganze Distribution ansprechen kann. Anschließend entfernen die betroffenen Knoten das Objekt oder verlangen eine Revalidierung. Hartes Löschen entfernt das Objekt, sodass die nächste Anfrage danach ein Cache-Miss ist, bei dem es vollständig abgerufen und erneut gecacht wird. Weiches Löschen behält das Objekt bei und markiert es als veraltet. Die nächste Anfrage revalidiert es und kann den gespeicherten Antwortkörper wiederverwenden, wenn der Origin-Server mit 304 Not Modified antwortet. Die Bezeichnungen unterscheiden sich je nach Anbieter: Cloudflare nennt den weichen Vorgang Invalidierung und den harten Löschen, während die bei Amazon CloudFront und Google Cloud CDN als Invalidierung bezeichnete Aktion das Objekt entfernt.
Wichtige Fakten
- Entfernt das Löschen der ursprünglichen URL auch ihre Varianten mit geänderter Größe oder anderem Format? Nur wenn der Anbieter sie als ein Objekt behandelt oder Sie sie gemeinsam ansprechen. Prüfen Sie daher zunächst, wie sich die Varianten-URLs vom Original unterscheiden. Bei Fastly-CDN-Diensten löscht Image Optimizer das Original und jede Variante, wenn die Löschanfrage keine Transformationsparameter enthält; bei Fastly-Compute-Diensten wird dieselbe Menge über die Purge API mithilfe eines gemeinsamen Surrogatschlüssels gelöscht. Cloudflare löscht alle gecachten Varianten einer Bild-URL, die seine Funktion Vary for Images verwendet. Amazon CloudFront verlangt dagegen den Query-String im Invalidierungspfad, wenn die Distribution Query-Strings an den Origin-Server weiterleitet, oder den Platzhalter
*am Ende, um jeden Query-String abzudecken. Eine Löschung, die eine einzelne URL nennt, erreicht keine Varianten, die unter anderen Pfaden veröffentlicht wurden. Ob sie andere Hostnamen abdeckt, hängt vom Anbieter ab: Eine Pfadinvalidierung bei Google Cloud CDN gilt für jeden Hostnamen auf dem Load Balancer, sofern kein Host angegeben ist. Varianten außerhalb der Auswahl benötigen ein gemeinsames Cache-Tag oder einen gemeinsamen Surrogatschlüssel, eine Löschung nach Präfix oder eine explizite Liste. - In welcher Reihenfolge gehe ich vor, und woher weiß ich, dass es funktioniert hat? Korrigieren Sie zuerst den Inhalt auf dem Origin-Server: Cloudflare und Google Cloud CDN warnen beide, dass die nächste Anfrage sonst erneut die alte Version cachen kann. Eine erfolgreiche API-Antwort beweist keine Entfernung. Cloudflare dokumentiert, dass HTTP 200 als Antwort auf eine Löschanfrage den Empfang bestätigt, aber nicht, dass etwas gecacht war oder entfernt wurde. Laut Cloudflare sollten Sie die Datei anfordern und bestätigen, dass
CF-Cache-Statusnicht mehrHITist. Dieser Header ist ein Indiz, kein Beweis: Die erste Anfrage nach einer Löschung meldetMISS, spätere meldenHITfür die erneut gecachte Kopie.STALEoderUPDATINGbedeutet dagegen, dass eine abgelaufene gespeicherte Kopie ausgeliefert wurde. Fordern Sie das Original und jede betroffene Variante mit einem Client ohne lokalen Cache an und bestätigen Sie, dass der zurückgegebene Inhalt die neue Fassung ist. Jede Antwort beschreibt einen einzelnen Cache: Google Cloud CDN weist darauf hin, dass eine Invalidierung als abgeschlossen gemeldet werden kann, obwohl eine kleine Anzahl von Caches sie noch nicht verarbeitet hat. Dieser seltene Zustand korrigiert sich von selbst. Bei CloudFront lässt sich eine eingereichte Invalidierung nicht abbrechen. Prüfen Sie daher die Pfade vor dem Absenden. - Aktualisiert eine CDN-Löschung auch die in Browsern gespeicherten Kopien? Nein. Google Cloud CDN erklärt, dass Invalidierungen keine Kopien in Webbrowser-Caches oder in Caches externer Internetanbieter betreffen. Laut CloudFront-Leitfaden kann ein Nutzer die alte Version weiterhin sehen, bis sie in diesen Caches abläuft. Um diese Kopien früher zu umgehen, veröffentlichen Sie die korrigierte Datei unter einem neuen Dateinamen oder Pfad und aktualisieren Sie die Seiten, die darauf verweisen. Das ist ein Grund, warum CloudFront für häufig aktualisierte Dateien versionierte Dateinamen statt Invalidierungen empfiehlt. Unter der alten URL gespeicherte Kopien werden nicht entfernt: Seiten, die auf die neue URL verweisen, fordern sie einfach nicht mehr an. Nur den Query-String zu ändern, ist weniger verlässlich, denn es funktioniert nur, wenn jeder Cache auf dem Weg den Query-String in seinen Cache-Schlüssel einbezieht. Bei der Cache-Stufe Ignore Query String von Cloudflare teilen sich beispielsweise URLs, die sich nur im Query-String unterscheiden, ein gecachtes Objekt. Eine URL, die unverändert bleiben muss und deren Inhalt möglicherweise unter derselben URL korrigiert werden muss, sollte keine lange Browser-Cache-Lebensdauer vorgeben.
- Hartes oder weiches Löschen, und in welchem Umfang? Nach dem harten Löschen aller Inhalte werden Anfragen vom Origin-Server bedient, bis der Cache wieder gefüllt ist. Cloudflare warnt, dass dies bei stark besuchten Websites mit vielen Dateien einen starken Anstieg der Anfragen an den Origin-Server verursachen, die Website verlangsamen und den Origin-Server überlasten kann. Google empfiehlt, nur das Nötigste zu invalidieren. Weiches Löschen ermöglicht es der nächsten Anfrage, den gespeicherten Antwortkörper zu revalidieren und wiederzuverwenden. Das funktioniert nur, wenn der Origin-Server
ETagoderLast-Modifiedsendet und bedingte Anfragen beantwortet. Cloudflare empfiehlt dies zum Aktualisieren von Inhalten, die sich möglicherweise nicht geändert haben, etwa einer Gruppe von Dateien mit einem gemeinsamen Cache-Tag. Der Nachteil: Als veraltet markierte Inhalte können Betrachter weiterhin erreichen. Fastly beschreibt, dass ein weich gelöschtes Objekt im veralteten Zustand ausgeliefert wird, während das aktualisierte abgerufen wird. Cloudflare kann invalidierte Inhalte im veralteten Zustand ausliefern, wenn der Origin-Server einen 5xx-Fehler zurückgibt oder nicht erreichbar ist. Verwenden Sie hartes Löschen, wenn die alten Inhalte nie wieder ausgeliefert werden dürfen. Das Zusammenfassen von Anfragen und eine Origin-Shield-Ebene verringern die Zahl der Anfragen zum Wiederbefüllen des Caches, die den Origin-Server erreichen.
Wann Cache-Invalidierung wichtig ist
Invalidieren Sie eine Datei, wenn eine dringende Korrektur vor Ablauf ihrer Gültigkeitsdauer verbreitet werden muss. Eine Invalidierung beim CDN erreicht keine Kopien, die Browser oder andere nachgelagerte Caches bereits gespeichert haben. Inhalte, die sich regelmäßig ändern, sollten daher besser unter versionierten Dateinamen veröffentlicht werden. Löschen Sie die kleinste Menge an Cache-Inhalten, die die Änderung abdeckt, denn alles, was eine umfassende Löschung entfernt, muss bei eintreffenden Anfragen erneut vom Origin-Server abgerufen werden.
So hilft Transloadit bei der Cache-Invalidierung
Transloadits Smart CDN cacht jedes transformierte Ergebnis unter seiner URL tlcdn.com. Die Dokumentation beschreibt Einstellungen, die vorab begrenzen, wie lange ein Ergebnis wiederverwendet wird: Der Parameter cache_duration beim Robot /file/serve legt die mit dem Ergebnis übermittelten Lebensdauern für Browser-Caches und gemeinsam genutzte Caches fest. Bei signierten URLs ist die effektive Cache-Lebensdauer durch die verbleibende Gültigkeitsdauer der Signatur begrenzt.
Die hier verlinkten Seiten beschreiben weder einen Lösch- oder Invalidierungsvorgang für Smart CDN noch, was mit einem gecachten Ergebnis geschieht, wenn das Original unter einem unveränderten Dateipfad ersetzt wird. Eine URL für Smart CDN benennt eine Quelldatei und die Transformationsparameter, die Ihr Template ausliest. Ein anderer Dateipfad oder ein anderer Wert für einen dieser Parameter fordert daher eine andere Variante an. Die Seiten sagen nicht, dass ein zusätzlicher, davon unabhängiger Parameter ein gecachtes Ergebnis umgeht. Testen Sie den Fall mit unverändertem Pfad in Ihrem eigenen Workspace, bevor Sie sich darauf verlassen.
Quellen
- RFC 9111, Abschnitt 4.4: Gespeicherte Antworten invalidieren
- MDN: HTTP-Caching (gespeicherte Antworten löschen und verwaltete Caches)
- Amazon CloudFront: Dateien invalidieren, um Inhalte zu entfernen
- Amazon CloudFront: Wissenswertes zur Invalidierung von Pfaden
- Cloudflare: Cache leeren (Methoden und Überprüfung)
- Cloudflare: Gecachte Inhalte invalidieren (Löschen im Vergleich zur Invalidierung)
- Cloudflare: Cache-Antworten (Werte von CF-Cache-Status)
- Cloudflare: Cache-Schlüssel (Query-Strings und der Cache-Schlüssel)
- Fastly: Einstieg in das Löschen von Cache-Inhalten (weiches und hartes Löschen, Surrogatschlüssel)
- Referenz zu Fastly Image Optimizer: Bilder und ihre Varianten löschen
- Google Cloud CDN: Überblick zur Cache-Invalidierung