Was ist Caching von Inhalten?

Bei der Zwischenspeicherung von Inhalten werden wiederverwendbare Kopien von Antworten, Metadaten oder erzeugten Dateien nahe bei späteren Nutzern gespeichert. Nachfolgende Anfragen können dadurch eine erneute Berechnung oder einen erneuten Abruf vom Origin-Server vermeiden.

Ein HTTP-Cache speichert eine Antwort unter einem Cache-Schlüssel. Der Schlüssel besteht mindestens aus Anfragemethode und URL und kann durch Anfrage-Header, die die Antwort in Vary nennt, oder durch die CDN-Konfiguration erweitert werden. Solange eine gespeicherte Antwort aktuell ist, kann der Cache daraus antworten, ohne den Origin-Server zu kontaktieren. Sobald sie veraltet ist, fragt der Cache normalerweise beim Origin-Server nach, bevor er sie erneut verwendet, sofern nicht eine Direktive oder die Cache-Konfiguration die Auslieferung der veralteten Kopie erlaubt. Hat der Origin-Server ein Validierungsmerkmal (ETag oder Last-Modified) gesendet, erfolgt diese Prüfung als bedingte Anfrage. Eine Antwort mit 304 Not Modified erlaubt dem Cache, die Kopie weiterzuverwenden, ohne den Antwortkörper erneut herunterzuladen. Zwei Arten von Caches folgen unterschiedlichen Regeln. Ein privater Cache, typischerweise der Browser-Cache, ist einem einzelnen Nutzer zugeordnet und darf personalisierte Antworten enthalten. Ein gemeinsam genutzter Cache sitzt zwischen Clients und dem Origin-Server und bedient viele Nutzer. CDNs und Reverse-Proxys sind gemeinsam genutzte Caches, die vom Website-Betreiber betrieben werden und die MDN als verwaltete Caches bezeichnet. Cache-Control legt mit max-age eine explizite Gültigkeitsdauer fest und kann die beiden Arten separat steuern: private weist gemeinsam genutzte Caches an, eine Antwort nicht zu speichern, und s-maxage überschreibt max-age ausschließlich für gemeinsam genutzte Caches. Ein verwalteter Cache ergänzt dies um eigene Konfigurationen und Löschvorgänge. Ein Löschvorgang entfernt die Kopie beim CDN, doch bereits in Browsern gespeicherte Kopien bleiben bis zu ihrem Ablauf bestehen. Deshalb werden Dateien, die sich nie ändern, unter versionierten URLs mit langer Gültigkeitsdauer veröffentlicht, während URLs, die unverändert bleiben müssen, erneut validiert werden.

no-cache oder no-store? no-store weist jeden Cache, ob privat oder gemeinsam genutzt, an, die Antwort nicht aufzubewahren. no-cache erlaubt das Speichern der Antwort, verbietet aber ihre Wiederverwendung ohne vorherige erneute Validierung beim Origin-Server. Enthält die Antwort ein Validierungsmerkmal wie ETag oder Last-Modified und beantwortet der Origin-Server bedingte Anfragen, genügt bei einer unveränderten Ressource ein kleiner Austausch mit 304 Not Modified statt eines vollständigen Downloads. Ohne diese Voraussetzungen bedeutet eine Wiederverwendung normalerweise, die gesamte Antwort erneut herunterzuladen. Keine der beiden Direktiven garantiert allein den Datenschutz: no-cache erlaubt weiterhin das Speichern, und laut RFC 9111 ist no-store kein zuverlässiger oder ausreichender Mechanismus zur Gewährleistung des Datenschutzes. Ein CDN kann no-cache auch anders behandeln als im RFC vorgesehen. Laut der Dokumentation von Cloudflare wird eine Antwort mit no-cache bei deaktivierter Funktion Origin Cache Control überhaupt nicht zwischengespeichert. Ist die Funktion aktiviert, wird die Antwort zwischengespeichert und immer erneut validiert.
Bleibt eine Antwort ohne Cache-Control ungecacht? Nicht zuverlässig. Wenn keine explizite Gültigkeitsdauer angegeben ist, erlaubt RFC 9111 einem Cache, sie zu schätzen, typischerweise als Bruchteil der seit Last-Modified vergangenen Zeit (das Beispiel im RFC ist 10 %). Der RFC empfiehlt Origin-Servern, explizite Direktiven zu senden, wenn sie Caching verhindern möchten. CDNs ergänzen eigene Standardregeln. Cloudflare entscheidet anhand der Dateiendung, nicht des MIME-Typs: Eine Antwort mit 200 für eine Dateiendung aus der Standardliste, etwa JPG, PNG, CSS oder JS, wird für eine standardmäßig festgelegte Dauer gecacht, selbst wenn die Antwort weder Cache-Control noch Expires enthält. HTML und JSON werden nur gecacht, wenn eine Regel dies aktiviert. Dieser Standard richtet sich nach der Dateiendung der URL, und eine Cache-Regel kann ihn auf alle Inhalte ausweiten. Verlassen Sie sich daher nicht darauf, dass personalisierte Seiten aus dem Cache ausgeschlossen bleiben. Senden Sie mit jeder Antwort eine explizite Richtlinie und lesen Sie nach, wie sich das CDN standardmäßig verhält, bevor Sie sich auf eines von beidem verlassen.
Wie bleiben personalisierte Antworten aus einem gemeinsam genutzten Cache ausgeschlossen? Senden Sie Cache-Control: private. Damit weisen Sie gemeinsam genutzte Caches wie CDNs an, die Antwort nicht zu speichern, während der Browser des Nutzers sie weiterhin speichern darf. Für Seiten, die nach der Anmeldung personalisiert werden, empfiehlt MDN Cache-Control: no-cache, private, damit auch der Browser vor der Wiederverwendung erneut validiert. HTTP schützt nur einen Fall automatisch: Ein gemeinsam genutzter Cache darf eine Antwort auf eine Anfrage mit Authorization nur wiederverwenden, wenn die Antwort dies mit public, s-maxage oder must-revalidate ausdrücklich erlaubt. Eine über ein Cookie personalisierte Antwort erhält diesen Schutz nicht. MDN weist darauf hin, dass ein Cookie allein eine Antwort nicht privat macht. Ein CDN berücksichtigt die Direktive nur, solange es den Headern des Origin-Servers folgt: Cloudflare dokumentiert beispielsweise, dass es die Cache-Header des Origin-Servers respektiert, sofern eine Cache-Regel für Edge Cache TTL sie nicht überschreibt. Prüfen Sie deshalb, welche CDN-Regeln für personalisierte URLs gelten. private steuert nur, wo eine Antwort gespeichert werden darf. Laut RFC 9111 kann es die Vertraulichkeit des Inhalts nicht gewährleisten.
Was muss der Cache-Schlüssel für Medienvarianten enthalten? Alle Eingabewerte, die die Ausgabe verändern, und nichts anderes. Wenn die Variante von einem Anfrage-Header abhängt, etwa einem Bildformat, das über Accept ausgehandelt wird, muss die Antwort diesen Header in Vary aufführen. Nach RFC 9111 darf ein Cache eine gespeicherte Antwort dann nur für Anfragen wiederverwenden, deren aufgeführte Header übereinstimmen. Ein CDN wendet diese Regel nicht unbedingt standardmäßig an: Cloudflare dokumentiert, dass es Vary bei Caching-Entscheidungen außer für Vary: Accept-Encoding nicht berücksichtigt, sofern weder die Einstellung seiner Vary-Cache-Regel noch Vary for images konfiguriert ist. Vergewissern Sie sich, dass das CDN seinen Cache nach diesem Header differenziert, bevor Sie sich allein auf Vary verlassen. Wenn die Variante von URL-Parametern wie Breite, Zuschnitt oder Format abhängt, müssen diese Parameter im Schlüssel enthalten bleiben. Auch hier unterscheiden sich die CDN-Standardeinstellungen: Der standardmäßige Cache-Schlüssel von Cloudflare enthält den Query-String, während Amazon CloudFront nicht anhand von Query-String-Parametern cacht, wenn es nicht zur Weiterleitung von Query-Strings an den Origin-Server konfiguriert ist. Fehlt ein Eingabewert im Schlüssel, erhält ein Anfragender die abgeleitete Datei eines anderen. Enthält ein Schlüssel mehr als nötig, werden Duplikate gespeichert: CloudFront empfiehlt, nur anhand von Parametern zu cachen, für die der Origin-Server unterschiedliche Versionen zurückgibt. Zudem weist CloudFront darauf hin, dass Query-Strings mit unterschiedlicher Groß- und Kleinschreibung oder Reihenfolge als separate Objekte behandelt werden.

Cachen Sie häufig angefragte Medien und Varianten, wenn geringere Latenz und weniger Last am Origin-Server wichtiger sind als Aktualitätsanforderungen. Fehlerhafte Schlüssel oder Invalidierungsregeln können dazu führen, dass veraltete, private oder unpassende Inhalte ausgeliefert werden.

Transloadits Smart CDN cacht die Ausgabe eines Templates am Netzwerkrand. Bei einem Cache-Miss importiert es das Original aus Ihrem Speicher und führt die Assembly aus. Spätere Anfragen für dieselbe URL werden aus der gecachten Kopie beantwortet, ohne die Assembly erneut auszuführen. Die Transformationsparameter sind Teil der URL, sodass jede Kombination als eigene Variante angefragt und gecacht wird.

Die erste Anfrage für jede neue URL umfasst auch die Zeit zum Abrufen und Verarbeiten des Originals. Bei signierten URLs für Smart CDN ist die effektive Cache-Gültigkeitsdauer einer Antwort durch die verbleibende Gültigkeitsdauer der Signatur begrenzt. Eine kurze Gültigkeitsdauer verkürzt daher auch die Zeit, in der ein Ergebnis wiederverwendet wird.

Entdecken Sie Transloadits Möglichkeiten zur Auslieferung

Was ist Caching von Inhalten?

So funktioniert das Caching von Inhalten

Wichtige Fakten

Wann das Caching von Inhalten wichtig ist

So hilft Transloadit beim Caching von Inhalten

Quellen

Machen Sie aus Medienwissen eine funktionierende Pipeline