Was ist ein Cache?

Der Begriff steht für mehrere ähnliche Dinge. MDN unterscheidet zwei Arten von HTTP-Caches. Ein privater Cache gehört zu einem einzelnen Client, meist dem Browser, und darf personalisierte Antworten für diese Person speichern. Ein gemeinsam genutzter Cache sitzt zwischen Client und Server, etwa in einem CDN oder einem Proxy, und speichert Antworten, die an viele Nutzer ausgeliefert werden können.

Die Regeln für HTTP-Caches stehen im Standard RFC 9111 vom Juni 2022, der Caches und die Header definiert, die ihr Verhalten steuern. Wer nach „Cache leeren“ sucht, meint meist etwas anderes: den Cache des eigenen Browsers löschen. In Chrome auf dem Computer geht das über das Dreipunkt-Menü und die Option „Browserdaten löschen“, in der man den Zeitraum und die zu löschenden Daten auswählt.

Der Server legt in jeder Antwort mit dem Header Cache-Control fest, wie lange sie gespeichert werden darf. max-age bestimmt die Sekunden, in denen die Kopie als frisch gilt und ohne Rückfrage verwendet werden darf. Bei no-cache wird die Kopie gespeichert, muss aber vor jeder Verwendung beim Server geprüft werden. Bei no-store wird sie in keinem Cache gespeichert. Fehlt Cache-Control, darf der Cache eine geschätzte Dauer ansetzen; MDN nennt das heuristisches Caching.

Ist eine Kopie abgelaufen, muss der Cache sie nicht vollständig neu laden. Er kann beim Server nachfragen, ob sie sich geändert hat, indem er den erhaltenen ETag-Wert im Header If-None-Match mitschickt. Hat sie sich nicht geändert, antwortet der Server mit 304 Not Modified ohne Inhalt, und der Cache verwendet weiter seine Kopie.

Um Dateien lange zu speichern, ohne alte Fassungen auszuliefern, ändert man ihre Adresse, sobald sich ihr Inhalt ändert, etwa mit einem Fingerabdruck im Dateinamen. MDN nennt diese Technik Cache Busting.

Der Cache beeinflusst die Ladezeit, die Nutzer erleben. Google beschreibt das in der Google-Konto-Hilfe: Nach dem Löschen des Caches laden manche Websites zunächst langsamer, weil Inhalte wie Bilder neu heruntergeladen werden müssen.

Er beeinflusst auch das Crawling. Die Crawler von Google unterstützen HTTP-Caching mit den Header-Paaren ETag und If-None-Match sowie Last-Modified und If-Modified-Since. Enthält eine Antwort beide, verwenden sie ETag. Google empfiehlt, beide zu senden. Außerdem weist Google darauf hin, dass Googlebot Ressourcen aggressiv cacht und beim Rendern Cache-Header ignorieren kann, sodass er veraltetes JavaScript oder CSS verwendet. Als Lösung nennt Google denselben Fingerabdruck im Dateinamen.

Für zds.es haben wir das am 14. Oktober 2026 gemessen. Die HTML-Seiten senden kein Cache-Control, und Cloudflare kennzeichnet sie als DYNAMIC: Jeder Abruf wird vom Server beantwortet. Die JavaScript-Datei der Vorlage trägt einen Fingerabdruck im Namen, wird ein Jahr lang gespeichert, mit max-age=31536000 und immutable, und kommt aus dem Cache von Cloudflare. Die Schriftdateien ohne Fingerabdruck werden vier Stunden gespeichert. Bei einem erneuten Abruf mit ihrem ETag antwortete der Server mit 304.

• Statischen Dateien mit Fingerabdruck im Namen ein langes max-age geben.
• Für Inhalte, die sich ändern, ohne die Adresse zu wechseln, kurze Zeiten oder Revalidierung verwenden.
• ETag und Last-Modified senden, damit Browser und Crawler revalidieren können.
• no-store für Antworten reservieren, die nicht gespeichert werden dürfen, etwa personenbezogene Daten.
• Die tatsächlichen Header einer Seite und ihrer Ressourcen prüfen, nicht nur die Konfiguration.
• Den CDN-Cache leeren, wenn sich eine Datei ändert, deren Adresse gleich bleibt.

• Glauben, no-cache verhindere das Speichern. Es verhindert die Verwendung ohne vorherige Prüfung.
• Dateien ein Jahr lang cachen lassen, deren Name sich bei einer Änderung nicht ändert.
• Eine Änderung im eigenen Browser testen, ohne den Cache zu leeren, und daraus schließen, sie habe nicht funktioniert.
• Annehmen, Googlebot halte sich beim Rendern an dieselben Cache-Header.
• Last-Modified mit einem Datumsformat senden, das nicht dem HTTP-Standard entspricht.