Browser-Caching mit Cache-Control, Validatoren und sicherer Dateiversionierung

Browser-Caching verwendet eine gespeicherte HTTP-Antwort erneut, statt dieselbe Ressource nochmals herunterzuladen. Nutzen Sie lange Frischezeiten für öffentliche Dateien mit inhaltsabhängigen URLs, Validierung für stets aktuelles HTML und expliziten Schutz für persönliche Antworten. Eine effiziente Richtlinie regelt Wiederverwendung und Aktualisierung, nicht einfach einen langen max-age für jede URL.

Verstehen Sie frische, veraltete und validierte Antworten

Ein Cache speichert Antwortkörper und relevante Header. Solange die Antwort frisch ist, kann der Browser sie ohne Serverkontakt verwenden. Danach ist normalerweise eine Netzwerkinteraktion nötig, sofern die Richtlinie keine veraltete Auslieferung erlaubt. Ablauf bedeutet nicht sofortiges Löschen, sondern andere Wiederverwendungsbedingungen.

Validierung prüft, ob die gespeicherte Repräsentation noch aktuell ist. Bei Übereinstimmung kann der Server 304 Not Modified ohne Antwortkörper senden. Das spart Bytes, braucht aber weiterhin Anfrage und Antwort. Ein frischer lokaler Treffer vermeidet diese Runde und ist damit ein anderes Leistungsergebnis.

Der private Browsercache unterscheidet sich vom gemeinsamen Proxy- oder CDN-Cache. Für eine Person wiederverwendbare Inhalte können für eine andere ungeeignet sein. Berücksichtigen Sie diese Grenze im Anwendungsdesign. Der Leitfaden zur Serverantwortzeit beschreibt Ursprungsarbeit: Caching verändert deren Häufigkeit, nicht zwangsläufig die Dauer der ungecachten Operation.

Wählen Sie Cache-Control passend zur Antwort

Die Direktiven erteilen unterschiedliche Berechtigungen. Besonders no-cache ist leicht misszuverstehen: Es verbietet nicht das Speichern.

Ein Cookie macht eine Antwort nicht zuverlässig privat. Setzen Sie die Richtlinie ausdrücklich und verhindern Sie CDN-Überschreibungen. private verschlüsselt nicht und erlaubt weiterhin Browserablage. Für sensible Kontoinhalte, die nicht gespeichert werden sollen, verwenden Sie Cache-Control: no-store und zusätzlich eine CDN-Bypass-Regel.

Sammeln Sie keine widersprüchlichen Direktiven auf Verdacht. Eine klare Richtlinie lässt sich besser prüfen. Ein nachträgliches no-store holt unter früheren Regeln gespeicherte Kopien nicht zurück. Planen Sie deren Korrektur und Invalidierung gesondert. Die MDN-Anleitung zum HTTP-Caching erläutert das Modell.

Geben Sie geänderten Dateien neue URLs

Ein Inhalts-Hash im Namen bindet eine URL an ein Build-Artefakt. Ändert sich app.8f3a1c2d.js, veröffentlichen Sie einen neuen Hash und aktualisieren den HTML-Verweis. Die alte URL muss weiterhin alte Bytes liefern. Das Überschreiben einer unveränderlichen URL bricht die Voraussetzung ihrer langen Laufzeit.

Für öffentliche fingerprintierte Dateien ist diese beispielhafte Antwort verbreitet.

Cache-Control: public, max-age=31536000, immutable

Die Zahl entspricht einem Jahr in Sekunden und ist eine Richtlinienwahl, kein Pflichtwert. Der Browser kann die Datei wegen begrenztem Speicher früher entfernen. Lange Laufzeiten erlauben Wiederverwendung, garantieren aber weder Offlineverfügbarkeit noch dauerhaften Speicherverbleib.

Veröffentlichen Sie Dateien vor dem darauf verweisenden HTML. Bewahren Sie ältere Dateien für alte Dokumente und offene Tabs auf. Ein später dynamischer Import kann nach einem Deployment einen alten Chunk anfordern. Sofortiges Löschen kann eine normale Veröffentlichung in eine fehlgeschlagene Interaktion verwandeln. Nutzen Sie Build-Manifest und passende Aufbewahrungsregeln.

Versionen in Query-Parametern funktionieren ebenfalls, wenn alle beteiligten Caches diese im Schlüssel berücksichtigen. Fingerprint-Dateinamen sind leichter zu erkennen. Ein neuer Zeitstempel bei jeder Anfrage verhindert dagegen Wiederverwendung identischer Inhalte.

Validieren Sie HTML mit ETag und Last-Modified

Öffentliches HTML mit stabiler URL profitiert oft von Cache-Control: no-cache und serverseitigen Validatoren. Ein ETag identifiziert eine Repräsentationsversion, ohne zwingend ein Hash zu sein. Last-Modified liefert einen Änderungszeitpunkt. Diese Werte müssen sich passend zu Inhalt und Varianten ändern.

Der Browser kann If-None-Match mit dem gespeicherten ETag senden. Bei Übereinstimmung folgt 304, sonst die aktuelle Repräsentation. If-Modified-Since validiert zeitbasiert über Last-Modified. Sind beide Bedingungen anwendbar, hat ETag Vorrang. Verwenden Sie nicht für alle Seiten und Releases denselben festen ETag.

Für persönliche Inhalte, die im Browser, aber nicht im CDN liegen dürfen, ist private, no-cache ein Ausgangspunkt. Bei sensibleren Antworten wählen Sie no-store. Prüfen Sie Anmeldung, Berechtigungen und Abmeldung in der Anwendung: Header ersetzen keine Zugriffskontrolle. Statische Regeln dürfen keine authentifizierten Downloads öffentlich cachebar machen.

Validierung spart nicht notwendigerweise sämtliche Ursprungsarbeit. Muss die Anwendung die Antwort zuerst vollständig erzeugen, um den ETag zu bestimmen, bleibt viel Rechenaufwand. Messen Sie Übertragung und Backend-Verarbeitung getrennt.

Konfigurieren Sie Apache in einem öffentlichen Asset-Verzeichnis

Diese .htaccess gehört ausschließlich in ein Verzeichnis öffentlicher Dateien mit Inhaltsfingerabdruck. Sie benötigt Apache HTTP Server 2.4, mod_headers und passende Override-Berechtigungen. Sie ist keine allgemeine Regel für Uploads, Kontoexporte oder beliebige Dateien passender Endung.

Die Regel erkennt einen mindestens achtstelligen hexadezimalen Fingerabdruck in Kleinbuchstaben vor einer zugelassenen Endung.

# public/assets/.htaccess
<FilesMatch "\.[a-f0-9]{8,}\.(css|js|mjs|png|jpg|jpeg|webp|avif|svg|woff2)$">
    Header set Cache-Control "public, max-age=31536000, immutable"
</FilesMatch>

Setzen Sie HTML-Regeln in der Anwendung oder Serverposition, die HTML tatsächlich erzeugt. Dateinamensregeln decken umgeschriebene Routen nicht automatisch ab. Setzen andere Module, Frameworks oder Proxys bereits Cache-Control, beseitigen Sie die Überschneidung an der Quelle und prüfen doppelte Header. Apache-Headertabellen und interne Weiterleitungen beeinflussen deren Kombination.

Prüfen Sie im Staging erfolgreiche Assets, eine fehlende Datei und einen authentifizierten Endpunkt. Fehler oder private Inhalte dürfen nicht zu öffentlich gespeicherten Jahresobjekten werden. Klären Sie bei Managed Hosting zuerst, welche Ebene die Cache-Regeln besitzt und ob Änderungen ersetzt werden.

Konfigurieren Sie Nginx ohne zusätzliche Inhalte freizugeben

Beschränken Sie lange Laufzeiten auf einen eigenen Pfad mit öffentlichen Build-Fingerprints. Das Fragment gehört in einen bestehenden server-Block mit /assets/ unter dessen Dokumentwurzel. Prüfen Sie die Location-Reihenfolge gegen vorhandenes Routing.

Das Beispiel liefert echte Dateien und leitet fehlende Assets nicht an die Anwendung weiter.

location ~ ^/assets/.+\.[a-f0-9]{8,}\.(css|js|mjs|png|jpg|jpeg|webp|avif|svg|woff2)$ {
    try_files $uri =404;
    add_header Cache-Control "public, max-age=31536000, immutable";
}

always fehlt absichtlich, damit nicht jeder Fehlerstatus diese Richtlinie erhält. Prüfen Sie die add_header-Vererbung Ihrer Nginx-Version. Header in untergeordneten Locations können geerbte Sicherheitsheader beeinflussen; neuere Versionen bieten zusätzliche Vererbungssteuerung. Erhalten Sie erforderliche Schutzheader und prüfen Sie die endgültige Antwort.

Führen Sie vor dem Neuladen nginx -t mit passenden Rechten aus. Das prüft Syntax, nicht die Sicherheit des Cache-Konzepts. Kontrollieren Sie Ursprung und Auslieferung über das CDN: Eine dortige Überschreibung kann richtige Ursprungsheader wirkungslos machen.

Behalten Sie Varianten und weitere Caches im Blick

Vary benennt Anfrageheader, die Repräsentationen unterscheiden. Variieren Inhalt, Sprache oder Kodierung, muss der Schlüssel die tatsächlichen Unterschiede berücksichtigen. Vary: Cookie ist kein allgemeines Heilmittel: Es kann zahlreiche Varianten erzeugen und ersetzt weder private noch Shared-Cache-Bypass.

Das CDN besitzt eigene Schlüssel, Laufzeiten und Löschmechanismen. Ein Purge entfernt normalerweise keine Browserkopien. Eine neue URL erreicht eine sofortige Asset-Aktualisierung verlässlicher als bloßes Edge-Löschen. Der Leitfaden zu CDN- und Edge-Caching erläutert das Zusammenspiel.

Ein Service Worker kann Anfragen abfangen und Cache Storage getrennt vom HTTP-Cache verwalten. Alter Worker-Code oder Cache-first-Logik erklären möglicherweise veraltete Inhalte trotz korrekter Header. Prüfen Sie Worker und Speicher und wiederholen die Diagnose ohne diese Ebene. Löschen Sie Offline-Daten nicht pauschal als Deployment-Routine.

Prüfen Sie Besuche, Aktualisierungen und private Zustände

Lassen Sie Disable cache im Network-Panel deaktiviert. Laden Sie normal, besuchen die Seite erneut und prüfen Header und Übertragung. Memory- oder Disk-Cache unterscheidet sich von einer Netzwerkantwort 304. Hard Reload verändert absichtlich das Verhalten und darf nicht die einzige Prüfung sein.

Führen Sie eine kleine Prüfliste für öffentliches HTML, Fingerprint-Assets, sensible Seiten und fehlende URLs. Notieren Sie Speicherberechtigung und Aktualisierungsverhalten. Das erklärt späteren Verantwortlichen jede Regel und entdeckt breite Konfigurationsfehler, die bei einer Einzelseite unauffällig bleiben.

Untersuchen Sie Header per echtem GET, weil manche Server HEAD anders behandeln.

curl -sS -D - -o /dev/null https://example.com/assets/app.8f3a1c2d.js

Veröffentlichen Sie eine geänderte Datei und prüfen den neuen HTML-Verweis. Lassen Sie für eine verspätet aktivierte Funktion einen alten Tab offen. Testen Sie anonym, angemeldet und abgemeldet. Private Seiten dürfen keine gemeinsam wiederverwendeten Treffer werden; fehlende Assets dürfen kein gecachtes HTML liefern.

Dokumentieren Sie Richtlinie und Prüfungen im Performance-Check. Nutzen Sie die Sammlung zur Serverleistung und messen eine typische Wiederholungsnavigation. Ziel sind sichere Wiederverwendung und zuverlässige Updates, nicht eine verschwundene Warnung zulasten veralteter oder offengelegter Inhalte.