Inhaltsverzeichnis

ETag-Check

Der ETag-Check prüft, ob dein Webserver korrekt auf wiederholte Anfragen reagiert und sogenannte *ETags* zur intelligenten Cache-Kontrolle verwendet. Das Tool hilft dabei, unnötige Datenübertragungen zu vermeiden und die Ladezeiten deiner Website durch effizientes Caching zu verbessern.

Funktionen und technische Details

Merkmal Beschreibung
Eingabe Vollständige URL zu einer Ressource (z. B. `https://www.example.de/assets/logo.png`)
Verfahren Das Tool führt zwei HTTP-Requests durch: einmal „normal“ und einmal mit einem `If-None-Match`-Header, der das zuvor empfangene ETag überträgt.
Erwartetes Verhalten Der Webserver sollte beim zweiten Request mit `304 Not Modified` antworten, wenn sich die Datei nicht geändert hat.
Ziel Überprüfung, ob statische Inhalte sinnvoll gecached werden können und der Webserver standardkonform mit ETags arbeitet.

Typische Anwendungsfälle (Use Cases)

Anwendungsfall Beschreibung
Ladezeit-Optimierung Erkenne, ob deine Website Ressourcen unnötig bei jedem Aufruf neu lädt, anstatt vorhandene Browser-Caches zu verwenden.
HTTP-Caching testen Prüfe gezielt, ob deine Webserver- oder CDN-Konfiguration korrekt auf Caching-Header reagiert.
DevOps- und CDN-Analyse Ermittle, ob Reverse Proxies, Loadbalancer oder CDNs wie Cloudflare, Akamai oder Varnish korrekt mit ETags umgehen.

Nutzungshinweise und Einschränkungen

Hinweis Beschreibung
URL erforderlich Es muss eine vollständige, direkt aufrufbare URL zu einer Datei angegeben werden (nicht nur die Domain).
ETag notwendig Funktioniert nur bei Servern, die ETag-Header aktiv ausliefern.
Kein Caching bei dynamischem Content PHP- oder API-Endpunkte ohne statische Inhalte liefern i. d. R. keine ETags – was korrekt ist.
Nicht jede Ressource verwendet ETags Manchmal wird `Last-Modified` statt `ETag` genutzt – das ist zulässig, aber das Tool testet gezielt auf ETags.

Ergebnisse interpretieren

Der ETag-Check simuliert zwei aufeinanderfolgende HTTP-Anfragen und analysiert, wie der Webserver beim zweiten Abruf auf den gesetzten Cache-Hinweis (`If-None-Match`) reagiert.

Typischer Ablauf

1. Initialer Abruf

Das Tool ruft die Datei normal ab. Der Server antwortet z. B. mit folgendem Header: 

GET /assets/logo.png HTTP/1.1  
Host: www.example.de

HTTP/1.1 200 OK  
Content-Type: image/png  
Content-Length: 14500  
ETag: "abc123"  
Cache-Control: public, max-age=86400

→ Der Server liefert die Datei vollständig aus und gibt einen ETag (`„abc123“`) mit.

2. Wiederholter Abruf mit ETag

Das Tool wiederholt den Request und sendet den zuvor empfangenen ETag im `If-None-Match`-Header: 

GET /assets/logo.png HTTP/1.1  
Host: www.example.de  
If-None-Match: "abc123"

HTTP/1.1 304 Not Modified  
ETag: "abc123"

→ Der Server erkennt: Die Ressource hat sich nicht verändert. Er liefert keine Datei, sondern nur einen Statuscode zurück.

Optimales Ergebnis

Merkmal Bedeutung
HTTP 304 Not Modified Bestätigung, dass der Server den ETag richtig erkannt und das Caching respektiert hat.
Keine Dateiübertragung Der Browser kann auf den lokalen Cache zugreifen, was Ladezeit spart.
Konformer ETag-Mechanismus Die ETag-Logik funktioniert wie vorgesehen.

Bewertung für die Praxis

Empfehlung

Optimales Ergebnis

Bedingung Bedeutung
Status: `304 Not Modified` Der Server erkennt, dass sich die Ressource nicht verändert hat und sendet nur die Header – keine Datei wird erneut übertragen.
Effizienter Caching-Mechanismus Der Browser kann die Datei aus seinem lokalen Cache laden. Das spart Bandbreite, reduziert Ladezeiten und entlastet den Server.
ETag wird korrekt interpretiert Die ETag-Verwaltung auf dem Server funktioniert wie vorgesehen.

Suboptimales Ergebnis

Problem Auswirkung
Status: `200 OK` mit vollständiger Datei Der Server ignoriert den übermittelten ETag oder erkennt ihn nicht korrekt. Die Ressource wird erneut geladen.
Fehlender oder dynamischer ETag Einige Server erzeugen bei jedem Abruf neue ETags, was die Vergleichbarkeit verhindert.
Caching funktioniert nur eingeschränkt Der Browser kann nicht zuverlässig entscheiden, ob er die Datei neu laden muss. Das führt zu unnötigen Ladezeiten.

Interpretation für die Praxis

Empfehlung

Typische Fehlerursachen bei 304-Test

Problem Mögliche Ursache
Kein `ETag`-Header vorhanden Server oder CDN liefert keine ETags (z. B. deaktiviert in nginx, Apache oder durch .htaccess)
Kein `304` bei zweitem Request ETag wird ignoriert oder nicht verglichen – falsche Serverkonfiguration
Unterschiedliche ETags bei jeder Anfrage Dynamische Generierung von ETags (z. B. basierend auf Session oder Zeit)

Verknüpfung mit anderen SEOLizer-Modulen

Funktion Beschreibung
Pagespeed-Analyse Fehlerhafte ETag-Konfiguration kann zu langsamer Ladezeit führen – erkenne Zusammenhänge über Pagespeed-Reports
Domainprofil Im technischen Abschnitt eines Domainprofils werden HTTP-Header, ETags und Caching-Verhalten erfasst
Berichtsmodul Ergebnisse lassen sich in automatisierte Technikberichte integrieren und exportieren (sofern verfügbar)
 
Tipp: Nutze den ETag-Check regelmäßig, wenn du Serverkonfigurationen änderst oder auf neue Hosting-Umgebungen oder CDNs umstellst. ETag-Verhalten unterscheidet sich je nach Umgebung deutlich.