====== 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 ====
* **Gut:** ETag vorhanden und HTTP 304 im zweiten Abruf → effizient & standardkonform
* **Mittel:** ETag vorhanden, aber Server ignoriert If-None-Match → Konfigurationsproblem
* **Schwach:** Kein ETag → Caching funktioniert nicht optimiert
==== Empfehlung ====
* Nutze ETags für alle statischen Assets (.css, .js, .jpg, .svg etc.)
* Stelle sicher, dass Reverse-Proxies oder CDNs ETags nicht deaktivieren
* Prüfe, ob deine Server-Software (z. B. nginx, Apache, Varnish) richtig konfiguriert ist
==== 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 ====
* **Gut:** Wenn du `ETag`-Header + `304 Not Modified` beim zweiten Abruf bekommst, funktioniert der ETag-Mechanismus wie gewünscht.
* **Mittelmäßig:** Der ETag ist vorhanden, aber wird nicht korrekt vom Server verarbeitet → Konfiguration prüfen.
* **Schlecht:** Es wird kein ETag ausgeliefert, oder jede Anfrage bekommt einen neuen → Caching ist ineffektiv.
==== Empfehlung ====
* Stelle sicher, dass dein Server (Apache/nginx/CDN) ETags unterstützt und identische Ressourcen über identische ETags referenziert.
* Teste typische Dateitypen wie `.css`, `.js`, `.png` oder `.svg`.
* Nutze den Check auch nach Änderungen an Cache-Headern, Deployments oder CDN-Wechseln.
===== 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.