ETag im HTTP verständlich erklärt: Validierung und bedingte Anfragen

Der HTTP-Header ETag (Entity Tag) ist ein wichtiges Werkzeug zur Cache-Validierung. Er fungiert als digitaler Fingerabdruck (Hashwert) einer spezifischen Dateiversion auf dem Webserver. Mithilfe von ETags können Webbrowser und CDNs den Server effizient fragen, ob sich eine Datei seit dem letzten Herunterladen geändert hat, um unnötige Datenübertragungen über das Netzwerk zu vermeiden.

ETags ergänzen die zeitbasierte Steuerung über Cache-Control: Während Cache-Control festlegt, wie lange eine Datei als frisch gilt, klärt der ETag nach Ablauf dieser Frist, ob sich überhaupt etwas geändert hat. Zusammen bilden sie das Fundament eines effizienten Browser-Cachings.

Der ETag-Validierungsprozess im Detail

Das Zusammenspiel zwischen ETag und dem Browser basiert auf sogenannten bedingten HTTP-Anfragen (Conditional Requests) unter Verwendung des Headers If-None-Match:

sequenceDiagram
    participant B as Browser
    participant S as Webserver
    B->>S: 1. GET /styles.css
    Note right of S: 2. Generiere Hash "a8f9b2"
    S-->>B: 3. HTTP 200 OK + ETag: "a8f9b2"
    Note left of B: Speichert Datei + ETag im Cache
    B->>S: 4. GET /styles.css<br/>If-None-Match: "a8f9b2"
    Note right of S: 5. Hash immer noch "a8f9b2"? (Ja!)
    S-->>B: 6. HTTP 304 Not Modified
    Note left of B: Lädt styles.css aus lokalem Cache

1. Erste Anfrage: Der Browser fordert eine Datei an. Der Server generiert einen ETag-Wert für diese Datei (meist basierend auf dem Dateigrösse und dem letzten Änderungsdatum) und sendet die Datei zusammen mit dem Header ETag: "a8f9b2" zurück.
2. Zweite Anfrage (nach Cache-Ablauf): Der Browser stellt fest, dass die Cache-Dauer (max-age) abgelaufen ist. Er sendet eine neue Anfrage, fügt jedoch den ETag im Header If-None-Match: "a8f9b2" hinzu.
3. Die Prüfung: Der Server vergleicht den gesendeten ETag mit dem aktuellen ETag der Datei auf der Festplatte.
4. Die Antwort:
   • Identisch: Der Server sendet keinen Payload (Inhalt), sondern antwortet lediglich mit dem Statuscode 304 Not Modified. Der Browser nutzt die Datei aus seinem Cache.
   • Geändert: Der ETag unterscheidet sich. Der Server sendet die neue Datei mit dem Statuscode 200 OK und dem neuen ETag zurück.

---

Starke vs. Schwache ETags

Der HTTP-Standard unterscheidet zwei Stufen der Validierung:

1. Starke ETags (Strong ETags)

Ein starker ETag (z. B. ETag: "123456") erfordert, dass die Ressource Byte für Byte exakt identisch ist. Jede minimale Änderung – selbst wenn sie das Aussehen oder die Funktion nicht beeinflusst (z. B. ein geändertes Erstelldatum im Datei-Header eines Bildes) – führt zu einem neuen ETag. Starke ETags sind Voraussetzung für Byte-Range-Requests (teilweises Laden grosser Dateien).

2. Schwache ETags (Weak ETags)

Ein schwacher ETag wird durch ein vorangestelltes W/ gekennzeichnet (z. B. ETag: W/"123456"). Er signalisiert, dass die Ressource semantisch (inhaltlich) äquivalent ist, sich auf Binärebene jedoch unterscheiden darf. Dies wird häufig bei dynamisch komprimierten Textinhalten (z. B. Gzip oder Brotli auf Nginx-Ebene) genutzt, da sich der Hashwert durch die Komprimierung ändert, der Inhalt für den Nutzer aber identisch bleibt.

---

ETag vs. Last-Modified im Vergleich

Für die Cache-Validierung stehen zwei Mechanismen zur Verfügung, die sich in Präzision und Funktionsweise unterscheiden:

Kriterium	ETag (If-None-Match)	Last-Modified (If-Modified-Since)
Grundlage	Inhalts-Hash / Fingerabdruck	Zeitstempel der letzten Änderung
Auflösung	Beliebig genau (Byte-Ebene)	Maximal eine Sekunde
Erkennt Mini-Änderungen	Ja	Nein, wenn < 1 s
Priorität bei beiden Headern	Höher	Fallback
Overhead	Hash-Berechnung nötig	Minimal

Faustregel: ETags sind präziser und robuster, kosten den Server aber eine Hash-Berechnung. Bei statischen Dateien generieren Webserver wie Nginx oder Apache den ETag automatisch und effizient.

---

Caching-Strategien: wann ETag, wann lange Cache-Zeit?

Die Wahl der richtigen Strategie hängt davon ab, wie oft sich eine Ressource ändert:

Ressourcentyp	Empfehlung	Begründung
HTML-Dokumente	Cache-Control: no-cache + ETag	Inhalt ändert sich häufig, ETag prüft günstig
Versionierte Assets (app.7f3a.js)	max-age=31536000, immutable	Dateiname ändert sich bei Update, kein Revalidieren nötig
Unversionierte Bilder	Kurzes max-age + ETag	Kompromiss aus Frische und Bandbreite
APIs (JSON)	ETag bei teuren Berechnungen	Spart Serverlast bei unveränderten Daten

Bei modernen Build-Pipelines mit Datei-Hashing im Namen (Cache Busting) wird der ETag für Assets teilweise überflüssig, da bei jeder Änderung ohnehin eine neue URL entsteht.

---

Praxisbeispiel: bedingte Anfrage Schritt für Schritt

So sieht ein vollständiger Validierungszyklus auf der Leitung aus. Erste Antwort des Servers:

HTTP/1.1 200 OK
Content-Type: text/css
ETag: "a8f9b2"
Cache-Control: no-cache

Die zweite Anfrage des Browsers nach Ablauf der Frische:

GET /styles.css HTTP/1.1
If-None-Match: "a8f9b2"

Hat sich nichts geändert, antwortet der Server ohne Inhalt:

HTTP/1.1 304 Not Modified
ETag: "a8f9b2"

Statt 50 KB CSS gehen nur wenige hundert Byte über die Leitung – ein wichtiger Baustein für gute Ladezeiten und Core Web Vitals.

[!TIP] Die Kombination aus Cache-Control: no-cache und ETags ist die perfekte Lösung für Webmaster, um sicherzustellen, dass Nutzer inhaltliche Updates sofort sehen, ohne Bandbreite zu verschwenden. Analysieren Sie die ETags Ihrer Webseiten live mit dem HTTP Header Check auf balou.tools.