Angenommen, eine Bibliothek ändert auf ihrer Website die heutigen Öffnungszeiten, doch manche Besucher sehen weiterhin die alten Zeiten. Zunächst sind mögliche Ursachen zu trennen: Wurde das Original auf dem Server nicht geändert, verwendet der Browser eine gespeicherte Antwort erneut oder liefert ein zwischengeschalteter Server eine frühere Version? Mehrmaliges Neuladen allein zeigt nicht, an welcher Stelle die Ursache liegt.
Ein HTTP-Cache speichert empfangene Antworten und verwendet sie erneut, wenn die Bedingungen dies erlauben. Dieser Artikel verbindet anhand eines fiktiven öffentlichen Öffnungszeitenplans die Speicher- und Revalidierungsanweisungen von Cache-Control mit ETag und 304-Antworten. Die folgenden Austauschprotokolle sind verkürzte Erläuterungen, keine Messungen einer wirklichen Bibliothek oder eines bestimmten Servers. Ziel ist zu erklären, welche Antworten wann wiederverwendbar sein sollen, statt pauschal sämtliche Caches abzuschaffen.
1. Speicherung, Prüfung vor Wiederverwendung und gemeinsame Nutzung trennen
Notieren Sie beim Lesen einer Cache-Richtlinie drei getrennte Fragen: Darf die Antwort gespeichert werden, darf die Kopie bei der nächsten Anfrage sofort verwendet werden und darf sie zwischen mehreren Nutzern geteilt werden? Speicherung erlaubt nicht automatisch jede Wiederverwendung; eine Aktualitätsprüfung erlaubt ebenso wenig automatisch die Weitergabe an andere Nutzer. Der HTTP-Caching-Standard RFC 9111 definiert diese Bedingungen durch unterschiedliche Direktiven. Im Folgenden geht es um Antwortdirektiven ohne zusätzliches Argument mit Feldnamen.
| Zu entscheidende Frage | Zugehörige Antwortdirektive | Zu unterscheidende Bedeutung |
|---|---|---|
| Darf die Antwort nicht gespeichert werden? | no-store | Untersagt die Speicherung zur späteren Wiederverwendung |
| Ist vor erneuter Verwendung eine Prüfung nötig? | no-cache | Speicherung ist möglich, Wiederverwendung erfordert erfolgreiche Validierung |
| Dürfen mehrere Nutzer die Antwort gemeinsam verwenden? | private | Schließt Speicherung in gemeinsamen Caches aus, verbietet aber nicht zugleich private Caches |
Wird ein öffentlicher Zeitplan unter derselben Adresse häufig geändert, lässt sich beispielsweise eine Prüfung vor jeder Nutzung der gespeicherten Kopie erwägen. Eine personalisierte Ansicht unterscheidet sich bereits bei den Freigabebedingungen von diesem Zeitplan. private betrifft gemeinsame Caches und ersetzt weder Anmeldung noch Berechtigungsprüfung. Unterschiedliche Einstellungszwecke in einem Satz zusammenzufassen kann dazu führen, bei der Geschwindigkeitsoptimierung den falschen Empfängerkreis für Informationen festzulegen.
Tragen Sie in eine Richtlinientabelle nicht nur die Direktive, sondern auch ihre Begründung ein: Sind die Öffnungszeiten öffentliche Informationen, deren Änderungen geprüft werden müssen? Ist das Logo eine Datei mit festem Inhalt? Stehen unter derselben Adresse nutzerspezifische Informationen? Diese Tabelle ist ein Ausgangspunkt zur Einordnung tatsächlicher Antworten, keine fertige Konfiguration für jede Website. Unterscheiden Sie außerdem den Speicherort, etwa Browser und CDN.
2. no-cache und no-store nicht allein nach dem Namen auswählen
Der Name no-cache wird leicht als Speicherverbot verstanden. Als Antwortdirektive verlangt er jedoch die Validierung vor erneuter Verwendung einer gespeicherten Antwort. Bestätigt der Server, dass sie unverändert ist, kann der gespeicherte Inhalt erneut genutzt werden. no-store dagegen weist an, diese Antwort nicht zu speichern. Was aufbewahrt werden darf und was bei der nächsten Anfrage geprüft werden muss, unterscheidet sich; erwarten Sie daher kein gleiches Verhalten.
fresh bezeichnet beim Caching einen Zustand, in dem die Richtlinie eine Wiederverwendung ohne zusätzliche Validierung erlaubt. Das garantiert nicht, dass der Betreiber das Original inzwischen unverändert gelassen hat. Definiert max-age eine Wiederverwendungsdauer, kann eine gespeicherte Antwort weiterhin ausgewählt werden, obwohl das Original innerhalb dieses Zeitraums geändert wurde. Bestimmen Sie zuerst die zulässige Aktualisierungsverzögerung und verbinden Sie diese Anforderung mit den Direktiven. Kopieren Sie keine beliebige lange Speicherdauer als allgemeingültige Leistungslösung.
Die HTTP-Caching-Anleitung von MDN erklärt, dass no-store an einer neuen Antwort zuvor gespeicherte Antworten derselben URL nicht löscht. Ist die ältere Kopie noch verwendbar und wird keine neue Antwort angefordert, erreicht möglicherweise auch der neue Header den Cache nicht. Verstehen Sie no-store weder als vollständige Cache-Leerung noch als ausreichende Datenschutzbedingung. Prüfen Sie auch die Lebensdauer vorhandener Antworten und die Aktualisierungsverfahren für verwaltbare Caches.
3. Einen erneuten Besuch mit ETag und 304 nachvollziehen
Die fiktive Adresse /hours.json soll zunächst eine Schließzeit von 18:00 melden. Das folgende erläuternde HTTP/1.1-Format enthält nur die benötigten Teile; weitere Header einer wirklichen Antwort sind ausgelassen. hours-v1 ist hier ein vom Server gewählter Bezeichner der Darstellung, weder eine Formel zur Zeitberechnung noch ein tatsächlicher Datei-Hash.
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-cache
ETag: "hours-v1"
{"closes":"18:00"}Hat der Browser diese Antwort gespeichert, kann er den ETag-Wert bei einer späteren bedingten Anfrage als If-None-Match senden. Passt die Bedingung zur aktuell vom Server ausgewählten Darstellung und gilt diese als unverändert, antwortet der Server mit 304 Not Modified. Der nächste Block ist ein verkürztes Protokoll von Anfrage und anschließender Antwort. Er zeigt kein neues Öffnungszeiten-JSON, das nach dem 304 gesendet würde.
GET /hours.json HTTP/1.1
Host: library.example
If-None-Match: "hours-v1"
HTTP/1.1 304 Not Modified
Cache-Control: no-cache
ETag: "hours-v1"Wie MDNs ETag-Erklärung beschreibt, nutzt der Client in diesem Fall den gespeicherten Antwortinhalt. Ein 304 enthält keinen neuen Body, doch Anfrage und Validierung verursachen weiterhin Kommunikation. Ändert der Betreiber die Schließzeit auf 19:00 und ändert sich auch die Serverdarstellung, ist auf die alte Bedingung eine 200-Antwort mit neuem Body und neuem Bezeichner zu erwarten. no-cache führt weder immer zu 304 noch automatisch zum Wegfall von Datenbankabfragen.
Prüfen Sie vor allem die Zuordnung zwischen Inhalt und Bezeichner statt nur einen Statuscode. Ändert sich der Inhalt, während der Server den alten ETag beibehält, kann die Validierung ein falsches Ergebnis liefern. Umgekehrt können ständig wechselnde Bezeichner bei gleichem Inhalt häufigere Übertragungen des Bodys verursachen. Untersuchen Sie serverseitig die Beziehung zwischen Erzeugung und ausgewählter Darstellung. Ein vorhandener ETag allein beweist keine korrekte Implementierung.
4. Veränderliche Dokumente von neu benannten Ressourcen unterscheiden
Ein Dokument, dessen Inhalt unter derselben URL wechselt, etwa der Zeitplan, kann eine andere Aktualisierungsstrategie benötigen als Logos oder Skripte, die bei Inhaltsänderungen neue Dateinamen erhalten. Wird ein Logo beispielsweise von logo.a1.png zu logo.b2.png, muss das neue Dokument auf die neue Adresse verweisen. Ein Kennzeichen im Dateinamen und anschließendes Überschreiben der alten Datei widersprechen der Zusage, Inhalt und Adresse gemeinsam zu verwalten.
Eine neue Datei hochzuladen führt nicht von allein dazu, dass Besucher die neue Adresse anfordern. Verweist das empfangene HTML weiter auf das alte Logo, kann die alte Ressource wiederverwendet werden. Betrachten Sie daher neben deren Cache-Einstellungen auch den Aktualisierungsweg des referenzierenden Dokuments. Statt Dokumenten und Ressourcen dieselbe Speicherdauer zu geben, sollten Sie die jeweils zulässige Verzögerung erklären können.
Während einer Bereitstellung können alte und neue Dokumente vorübergehend nebeneinander genutzt werden. Ein neues Dokument vor seinen Ressourcen freizugeben oder alte Ressourcen zu früh zu löschen erzeugt unterschiedliche Fehler. Im fiktiven Beispiel prüfen Sie sowohl die Existenz der vom neuen Dokument referenzierten Dateien als auch die Erreichbarkeit der noch von vorhandenen Dokumenten benötigten Dateien. Dateinamenswechsel helfen beim Cache-Entwurf, lösen aber nicht automatisch alle Reihenfolge- oder Rollback-Probleme einer Bereitstellung.
5. Im Network-Panel jeweils eine Hypothese prüfen
Halten Sie zur direkten Untersuchung zunächst einen Ausgangszustand bei erlaubtem Cache fest. Betrachten Sie gemeinsam genaue URL und Abfrageparameter, angezeigte Zeitplanversion, Antwortstatus, If-None-Match der Anfrage sowie Cache-Control und ETag der Antwort. Anfrage- und Antwortheader beschreiben Bedingungen verschiedener Beteiligter, auch wenn Namen übereinstimmen; notieren Sie die jeweils gelesene Seite. Die Network-Referenz von Chrome DevTools zeigt die Unterscheidung dieser Elemente unter Headers.
| Fiktive Testsituation | Gemeinsam zu prüfende Aufzeichnungen | Vorschnelle Schlussfolgerung |
|---|---|---|
| Denselben Zeitplan erneut anfordern | Bedingte Anfrage, Status und angezeigte Zeiten | Bei 304 gab es überhaupt keine Kommunikation |
| Nach Änderung der Originalzeiten anfordern | Neuer Body, ETag und tatsächlich angeforderte URL | Eine erfolgreiche Speicheranzeige beweist die Aktualisierung bei allen Nutzern |
| Mit abgeschaltetem Browsercache anfordern | Unterschied zwischen erstem Download und gewöhnlichem Wiederbesuch | Dieses Ergebnis entspricht der normalen Wiederbesuchsleistung |
| Mit der Zurück-Taste zurückkehren | Neue Anfrage und wiederhergestellte Ansicht | Eine sichtbare Ansicht beweist eine neue HTTP-Validierung |
Testen Sie das Abschalten des Browsercaches danach als eigene Bedingung. Chromes Einstellung Disable cache gilt bei geöffneten DevTools; notieren Sie deshalb den geöffneten Zustand und die Einstellung zusammen. Das hilft beim ersten Download, ist aber ein anderer Test als die Nutzung gespeicherter Antworten bei gewöhnlichen Wiederbesuchen. Ohne diese Angabe können stets neue Downloads fälschlich als fehlende Cache-Funktion gedeutet werden. Dokumentieren Sie die Versuchsbedingungen für einen späteren Vergleich mit wieder erlaubtem Cache.
Ändern und fordern Sie während der Beobachtung möglichst nicht vieles gleichzeitig an. Prüfen Sie erst einen Wiederbesuch ohne Inhaltsänderung und verändern Sie danach nur einen Zeitwert, um die Antwort zu vergleichen. Gleichzeitige Änderungen von Dokument-URL, Servereinstellungen und Dateinamen erschweren die Zuordnung der Wirkung. Erscheint der erwartete Status 200 oder 304 nicht, lesen Sie zuerst die tatsächlichen Anfragen und Antworten erneut, bevor Sie weitere Einstellungen hinzufügen.
6. Andere Speicherwege und Abschlusskriterien mitprüfen
Ein abgeschalteter HTTP-Cache im Browser beseitigt nicht zwangsläufig ein vorgeschaltetes CDN oder andere Speicherwege der Anwendung. Prüfen Sie getrennt, ob ein Service Worker die Anfrage verarbeitet, welche Antwort ein Zwischenserver auswählt und ob die Anwendung bereits empfangene Daten weiter anzeigt. Dieselbe sichtbare URL bedeutet nicht, dass jede Schicht dieselbe Kopie nutzt.
Unterscheiden Sie auch die Zurück-Navigation von einer neuen HTTP-Anfrage. Stellt der Browser die Ansicht einer früheren Sitzung wieder her, erscheint trotz no-cache möglicherweise nicht die erwartete Revalidierungsanfrage. Dies sofort als Beweis für einen ignorierten Header zu nehmen kann zur falschen Ursache führen. Notieren Sie getrennt, ob bei neuer Navigation, Neuladen und Zurückgehen tatsächlich Anfragen entstanden, statt verschiedene Vorgänge als ein Problem zu behandeln.
Der Abschluss des Zeitplanbeispiels ist nicht allein durch eine gute Cache-Trefferquote bestimmt. Prüfen Sie, ob unveränderte Kopien richtig genutzt werden, ob neue Informationen nach Änderungen innerhalb der zulässigen Zeit erscheinen und ob die Antwort mit dem richtigen Empfängerkreis geteilt wird. Änderungs- und Beobachtungszeit, Bedingungen und tatsächlicher Body erleichtern anderen die Wiederholung. Bessere Geschwindigkeitswerte erfüllen die ursprüngliche Anforderung nicht, wenn falsche Öffnungszeiten zu lange sichtbar bleiben.
Für den Betrieb prüfen Sie Richtlinien je Antworttyp gemeinsam mit Aktualisierungs- und Rücknahmeverfahren. Kopieren Sie Cache-Anweisungen öffentlicher Dokumente nicht auf persönliche Antworten und verwechseln Sie erfolgreiche Validierung nicht mit abgeschlossener Berechtigungsprüfung. Header vermitteln Regeln für Speicherung und Wiederverwendung. Erklären zu können, was gespeichert wurde und über welche Prüfungen die aktuelle Ansicht entstand, ermöglicht eine genauere Diagnose veralteter Ansichten.