304 Not Modified: warum es ein Erfolg ist, kein Fehler

Wie ein 304 zustande kommt

Ein 304 ist die zweite Hälfte eines zweistufigen Austauschs. Beim ersten Request gibt der Server die Ressource mit einem Validator zurück: einem ETag, einem undurchsichtigen Bezeichner für genau diese Version, und oft einem Last-Modified-Datum. Der Client speichert die Antwort zusammen mit diesen Validatoren.

Später, wenn die zwischengespeicherte Kopie neu validiert werden muss, wiederholt der Client den Request und legt bei, was er hat:

• If-None-Match: "abc123" trägt das gespeicherte ETag. Das ist der bevorzugte Validator, weil er exakt ist.
• If-Modified-Since: Wed, 03 Sep 2026 10:00:00 GMT trägt das gespeicherte Datum, verwendet, wenn es kein ETag gibt.

Hat sich die Ressource nicht geändert, antwortet der Server mit 304 Not Modified, nur mit Headern und ohne Body, und der Client rendert seine zwischengespeicherte Kopie. Hat sie sich geändert, antwortet der Server mit 200, dem neuen Inhalt und neuen Validatoren. Beide Ausgänge sind korrektes Verhalten.

Warum ein 304 eine gute Nachricht ist, kein Fehler

Leute sehen 304 im Netzwerk-Panel eines Browsers oder in einem Log-Analyzer, bemerken, dass es kein 200 ist, und nehmen an, etwas sei fehlgeschlagen. Nichts ist fehlgeschlagen. Ein 304 ist die billigste nützliche Antwort im Web: Kein Antwort-Body durchquert das Netzwerk, die Übertragung sind also ein paar hundert Byte statt des vollständigen Assets, und der Server vermeidet meist, die Ressource neu zu erzeugen, was weniger CPU kostet als ein 200. Die Seite rendert schneller, weil der Browser Bytes wiederverwendet, die er bereits hat. Auch Crawler profitieren, denn ein stabiles ETag, das 304er erzeugt, lässt eine Suchmaschine ihr Crawl-Budget für Seiten ausgeben, die sich geändert haben.

Ein hoher Anteil an 304ern bei statischen Assets ist ein Zeichen, dass Caching gut konfiguriert ist. Das Einzige, worauf zu achten ist, ist, ob Sie den Revalidierungs-Umlauf überhaupt brauchen: Für versionierte oder fingerabdruckversehene Assets vermeidet ein langes Cache-Control: max-age mit immutable sogar das 304, weil der Browser gar nicht erst fragt.

Wann ein 304 ein Problem ist

• Eine veraltete Seite, die sich nicht aktualisiert. Wird Ihr HTML mit einem Validator ausgeliefert, der sich nie ändert, während sich der Inhalt ändert, bekommen Browser weiterhin 304 und Nutzer sehen weiterhin die alte Seite. Das ist der klassische Fehler "ich habe deployed, aber niemand sieht es".
• Ein 304 ohne passende zwischengespeicherte Kopie. Sendet ein Client einen bedingten Request, für den er keine Grundlage hatte, oder entfernt ein Proxy den Body eines 200, bleibt dem Client nichts zum Rendern, und die Seite erscheint leer.
• Schwache oder instabile ETags hinter einem Load Balancer. Erzeugen mehrere Backends unterschiedliche ETags für identischen Inhalt, geht jede Revalidierung fehl, und Sie bekommen volle 200er, wo 304er erwartet wurden. Der Traffic steigt ohne Grund.
• Kompression, die den Validator ändert. Unterscheidet sich das ETag zwischen komprimierter und unkomprimierter Variante ohne korrektes Vary: Accept-Encoding, können Caches das Falsche ausliefern.

Wie Sie bedingte Requests testen

1. Rufen Sie die Ressource ab und lesen Sie ihre Validatoren:

   curl -sI https://example.com/style.css | grep -Ei "^(HTTP|etag|last-modified|cache-control)"

2. Wiederholen Sie den Request mit dem erhaltenen ETag und bestätigen Sie, dass der Server mit 304 antwortet:

   curl -sI -H 'If-None-Match: "abc123"' https://example.com/style.css | head -n 1

   Setzen Sie den exakten ETag-Wert ein, Anführungszeichen eingeschlossen. Ein 200 hier bedeutet, die Revalidierung funktioniert nicht.
3. Erhalten Sie 200, wo Sie 304 erwartet haben, prüfen Sie, ob ein Proxy oder CDN If-None-Match entfernt, und ob sich Ihre Backends beim ETag für dieselbe Datei einig sind.
4. Erhalten Sie eine veraltete Seite, lassen Sie den Validator sich ändern, wenn sich der Inhalt ändert. Fingerabdruckversehene Dateinamen sind die zuverlässigste Lösung; leiten Sie andernfalls das ETag aus dem Inhalt selbst ab.
5. Halten Sie HTML auf einer kurzen Frische-Lebensdauer und lassen Sie Assets die lange tragen. HTML, das einen Tag lang gecacht wird, macht ein Deployment unsichtbar.

Warum Uptime-Prüfungen nie ein 304 sehen

Eine Uptime-Prüfung fordert eine Seite wie ein Erstbesucher an, ohne If-None-Match und ohne If-Modified-Since, der Server hat also nichts zum Vergleichen und antwortet immer mit 200. Das ist die richtige Vorgabe für Erreichbarkeit. Es bedeutet auch, dass Caching-Regressionen in Uptime-Daten überhaupt nicht auftauchen: Eine Website kann jedem eine veraltete Seite ausliefern, während jede Prüfung grün bleibt. Prüfen Sie auch den Seiteninhalt, nicht nur den Status, dann wird eine nicht mehr aktualisierende Seite als Inhaltsabweichung sichtbar. HostTracker bietet 13 Monitortypen und überwacht Websites seit 2004. Testen Sie Header und Status mit dem HTTP-Check-Tool, und lesen Sie, was ein 200 OK wirklich beweist, sowie die vollständige Anleitung zur 3xx-Familie.