HTTP-Caching erklärt: ETag, Cache-Control und CDNs

Warum Ihre Website langsam wirkt (und wie Caching das behebt)

Sie haben Ihre Bilder optimiert, Ihr CSS minimiert und sogar Ihren Server aufgerüstet. Dennoch erleben wiederkehrende Besucher langsame Ladezeiten, und Ihr Origin-Server verbraucht Bandbreite. Der Übeltäter? Ineffizientes HTTP-Caching. Ohne ordnungsgemäße Caching-Header laden Browser dieselben Assets bei jedem Besuch erneut herunter, und CDNs können ihre Aufgabe nicht effektiv erfüllen.

HTTP-Caching ist eine der wirkungsvollsten Performance-Optimierungen. Es reduziert Latenz, senkt Bandbreitenkosten und entlastet Ihre Origin-Server. In diesem Leitfaden erklären wir die wichtigsten Mechanismen: ETag, Cache-Control und wie CDNs ins Bild passen. Sie lernen praktische Strategien, um sie korrekt zu implementieren.

Wie HTTP-Caching funktioniert: Das große Ganze

Wenn ein Browser eine Ressource anfordert, kann er sie entweder vom Origin-Server abrufen oder eine lokal gespeicherte Kopie verwenden. HTTP-Caching definiert die Regeln, wann eine gespeicherte Kopie als frisch gilt und wann sie revalidiert werden muss.

Es gibt zwei Hauptarten des Cachings:

• Browser-Caching (privat): Der Browser des Nutzers speichert Ressourcen lokal. Dies kommt einem einzelnen Nutzer über mehrere Seiten oder Besuche hinweg zugute.
• Shared Caching (CDN, Proxy): Zwischenserver cachen Ressourcen für mehrere Nutzer. Dies reduziert die Last auf Ihrem Origin und beschleunigt die Auslieferung weltweit.

Beide verlassen sich auf HTTP-Header, um Frische und Revalidierung zu entscheiden. Die beiden wichtigsten Header sind Cache-Control und ETag.

Cache-Control: Die Frische-Regeln

Cache-Control ist der primäre Header zur Definition von Caching-Richtlinien. Es ist ein direktivenbasierter Header, der Caches mitteilt, wie sie eine Antwort behandeln sollen.

Wichtige Direktiven

• max-age: Die Anzahl der Sekunden, in denen eine Antwort als frisch gilt. Zum Beispiel bedeutet Cache-Control: max-age=3600, dass die Antwort 1 Stunde lang frisch ist.
• s-maxage: Wie max-age, aber speziell für Shared Caches (CDNs). Überschreibt max-age für Shared Caches.
• public: Die Antwort kann von jedem Cache gespeichert werden, auch von Shared Caches.
• private: Die Antwort ist für einen einzelnen Nutzer bestimmt und sollte nicht von Shared Caches gespeichert werden.
• no-cache: Die Antwort kann gespeichert werden, muss aber vor jeder Verwendung mit dem Origin revalidiert werden.
• no-store: Die Antwort darf in keinem Cache gespeichert werden. Verwenden Sie dies für sensible Daten.
• must-revalidate: Sobald veraltet, darf der Cache die Antwort nicht ohne Revalidierung verwenden.
• immutable: Die Antwort wird sich während ihrer Frische-Lebensdauer nicht ändern. Nützlich für versionierte Assets.

Beispiel: Cache-Control: public, max-age=31536000, immutable ist ideal für statische Assets mit gehashten Dateinamen.

ETag und bedingte Anfragen

Ein ETag (Entity Tag) ist eine Kennung für eine bestimmte Version einer Ressource. Wenn sich eine Ressource ändert, ändert sich das ETag. Browser verwenden ETags, um bedingte Anfragen zu stellen: Sie senden das gespeicherte ETag in einem If-None-Match-Header. Wenn sich die Ressource nicht geändert hat, antwortet der Server mit 304 Not Modified und ohne Body, was Bandbreite spart.

Ähnlich funktioniert Last-Modified mit If-Modified-Since, aber ETags sind präziser (sie können Änderungen innerhalb derselben Sekunde erkennen).

Wie man ETags generiert

Die meisten Webserver und Frameworks generieren ETags automatisch. In Express.js können Sie es beispielsweise mit app.set('etag', 'strong') aktivieren. In Nginx sind ETags für statische Dateien standardmäßig aktiviert.

Starke ETags (z. B. "abc123") garantieren Byte-für-Byte-Identität. Schwache ETags (z. B. W/"abc123") zeigen semantische Äquivalenz an, nicht exakte Bytes.

CDN-Caching: Shared Cache im großen Maßstab

CDNs (Content Delivery Networks) fungieren als global verteilte Shared Caches. Sie cachen Ihre Inhalte an Edge-Standorten und liefern sie von einem nahegelegenen Point of Presence an Nutzer aus. Dies reduziert die Latenz und entlastet Ihren Origin.

CDNs respektieren Cache-Control-Header, haben aber oft ihre eigene Konfiguration. Wichtige Konzepte:

• Edge-Cache: Der lokale Cache des CDN. Er speichert Antworten basierend auf Cache-Schlüsseln (normalerweise URL + Header wie Accept-Encoding).
• Origin Shield: Eine zusätzliche Caching-Schicht, die Anfragen an Ihren Origin reduziert.
• Cache-Invalidierung: CDNs bieten APIs zum Löschen von gecachten Inhalten, wenn Sie Ressourcen aktualisieren.

Bei der Verwendung eines CDN setzen Sie Cache-Control mit s-maxage, um die Frische des Shared Caches getrennt vom Browser-Cache zu steuern. Zum Beispiel: Cache-Control: public, max-age=600, s-maxage=3600 bedeutet, dass Browser 10 Minuten cachen, das CDN aber 1 Stunde.

Vergleich der Caching-Header

Hinweis: Expires wird von Cache-Control abgelöst, aber noch von älteren Clients verwendet.

Praktische Caching-Strategie für Web-Apps

Befolgen Sie diese Schritte, um effektives Caching zu implementieren:

1. Fingerprinting statischer Assets: Verwenden Sie gehashte Dateinamen (z. B. app.a1b2c3.js) und setzen Sie eine lange max-age mit immutable. Wenn sich die Datei ändert, ändert sich der Hash und umgeht den Cache.
2. Setzen Sie angemessenes Cache-Control für HTML: HTML sollte normalerweise no-cache oder eine kurze max-age haben, damit Nutzer schnell Updates erhalten. Verwenden Sie ETag zur Revalidierung.
3. Verwenden Sie Vary: Accept-Encoding: Wenn Sie komprimierte und unkomprimierte Versionen ausliefern, stellt dies sicher, dass Caches sie getrennt speichern.
4. Nutzen Sie CDN mit s-maxage: Setzen Sie eine längere s-maxage für Shared Caches, um die Origin-Last zu reduzieren, während Sie den Browser-Cache bei Bedarf kürzer halten.
5. Invalidieren Sie mit Bedacht: Verwenden Sie CDN-Purge-APIs bei der Bereitstellung kritischer Updates. Für statische Assets vermeidet Fingerprinting die Notwendigkeit von Purges.
6. Überwachen Sie die Cache-Hit-Ratio: Nutzen Sie CDN-Analysen, um sicherzustellen, dass Ihr Cache effektiv ist. Eine niedrige Hit-Ratio deutet auf falsch konfigurierte Header hin.

Häufige Fallstricke und wie man sie vermeidet

• Übermäßiges Caching von HTML: Nutzer sehen veraltete Inhalte. Verwenden Sie no-cache oder kurze max-age.
• Unter-Caching statischer Assets: Setzen Sie eine lange max-age (z. B. 1 Jahr) mit Fingerprinting.
• Ignorieren von Vary: Caches könnten falsche Inhalte ausliefern (z. B. gzip vs. plain). Setzen Sie immer Vary: Accept-Encoding.
• Vergessen von private für nutzerspezifische Daten: Shared Caches könnten Daten preisgeben. Verwenden Sie Cache-Control: private für authentifizierte Antworten.
• Missbrauch von no-store: Es verhindert jegliches Caching, was die Performance beeinträchtigen kann. Verwenden Sie es nur für sensible Daten.

Testen Ihrer Caching-Einrichtung

Verwenden Sie die Browser-DevTools (Netzwerk-Tab), um Antwort-Header zu überprüfen und zu sehen, ob Ressourcen aus dem Cache geliefert werden (suchen Sie nach "(from disk cache)" oder "(from memory cache)"). Für das CDN-Verhalten verwenden Sie curl -I, um Header wie X-Cache oder CF-Cache-Status zu prüfen. Tools wie WebPageTest können das Caching über mehrere Besuche hinweg visualisieren.

FAQ

Was ist der Unterschied zwischen ETag und Last-Modified?

ETag ist eine undurchsichtige Kennung, die sich ändert, wenn sich die Ressource ändert, während Last-Modified ein Zeitstempel ist. ETags sind präziser, weil sie Änderungen innerhalb derselben Sekunde erkennen können und nicht auf Uhrensynchronisation angewiesen sind.

Wann sollte ich no-cache vs. no-store verwenden?

Verwenden Sie no-cache, wenn der Cache die Antwort speichern, aber vor jeder Verwendung mit dem Origin revalidieren soll. Verwenden Sie no-store für sensible Daten, die niemals von einem Cache auf Festplatte oder in den Speicher geschrieben werden dürfen.

Wie handhaben CDNs die Cache-Invalidierung?

CDNs bieten Purge-APIs, mit denen Sie bestimmte URLs oder ganze Verzeichnisse aus ihren Edge-Caches entfernen können. Einige unterstützen auch Soft-Purges, die Inhalte als veraltet markieren und bei der nächsten Anfrage revalidieren. Das Fingerprinting von Assets ist oft effizienter als das Purgen.

Fazit

Die Beherrschung von HTTP-Caching mit ETag, Cache-Control und CDNs ist wesentlich für den Aufbau schneller, skalierbarer Webanwendungen. Beginnen Sie damit, geeignete Header für Ihre statischen Assets und HTML festzulegen, nutzen Sie CDN-Shared-Caches mit s-maxage und testen Sie stets Ihre Konfiguration. Kleine Änderungen an den Caching-Headern können zu erheblichen Leistungssteigerungen führen.

Müssen Sie schnell Ihre Server-Logs analysieren, um Cache-Hit-Ratios zu sehen? Probieren Sie unseren Nginx Log Analyzer, um Ihre Zugriffslogs zu parsen und zu visualisieren.