Der 304 status code ist einer der wichtigsten Mechanismen im modernen Web-Ökosystem. Er erlaubt es Browsern und Caches, unnötige Datenübertragungen zu vermeiden, indem er bestätigt, dass eine bereits geladene Ressource unverändert ist. In diesem umfassenden Leitfaden erfahren Sie, wie der 304 status code funktioniert, wann er sinnvoll eingesetzt wird, welche Header eine Rolle spielen und wie Sie ihn in Server-Konfigurationen wie Apache, Nginx oder IIS optimal nutzen können. Ziel ist es, sowohl das Verständnis als auch die praktische Anwendung zu fördern – damit Ihre Websites schneller laden, weniger Bandbreite verbrauchen und besser skalieren.
Was bedeutet der 304 status code?
Der 304 status code, offiziell als Not Modified beschrieben, signalisiert dem Client (meist dem Browser), dass die angeforderte Ressource seit dem letzten Abruf unverändert geblieben ist. Damit wird der bereits im Cache vorhandene Kopie verwendet, anstatt die Ressource erneut über das Netzwerk zu laden. Der Begriff „304 status code“ taucht in API-Dokumentationen, Blogartikeln und in der Praxis häufig auf, um genau dieses Verhalten zu beschreiben. Die Kernbotschaft des 304 Status Codes lautet: Es gibt keine Veränderung, daher braucht der Client die Ressource nicht erneut herunterzuladen.
Warum ist der 304 status code so wichtig?
- Reduzierte Bandbreite: Netzwerkanfragen werden minimiert, da Inhalte aus dem Cache stammen.
- Schnellere Ladezeiten: Der Client muss keine neue Kopie der Ressource laden, was die Reaktionszeit verbessert.
- Entlastete Serverressourcen: Weniger Anfragen bedeuten weniger Verarbeitungsaufwand für den Ursprungsserver.
Wie funktioniert der 304 Status Code im Webcache?
Der 304 status code ist eng mit Caching-Mechanismen verbunden. Wenn ein Client eine Ressource erstmals herunterlädt, werden Metadaten wie ETag, Last-Modified, Cache-Control und Expires gespeichert. Bei einem späteren Zugriff kann der Client eine bedingte Anfrage senden, um zu prüfen, ob die Ressource unverändert geblieben ist. Falls ja, antwortet der Server mit 304 Not Modified, wodurch der Client die vorhandene Kopie wiederverwenden kann. Dieser Ablauf verhindert unnötige Datenübertragungen und erhöht insgesamt die Effizienz des Netzes.
Bedingte Anfragen und Header
Die zentrale Idee hinter dem 304 status code sind bedingte Anfragen. Die häufigsten Muster sind:
- If-Modified-Since: Der Client sendet das Datum der letzten Änderung. War die Ressource seitdem geändert, erfolgt eine neue Übertragung (z. B. mit 200 OK); andernfalls kommt 304 Not Modified.
- If-None-Match: Der Client nutzt ETag-Werte, die eine eindeutige Versionskennung der Ressource darstellen. Gleiche ETag-Signaturen bedeuten, dass nichts geändert wurde; der Server antwortet mit 304.
- ETag (Entity Tag): Der Server erzeugt eine eindeutige Kennung für eine Ressource. Bei jeder Änderung ändert sich der ETag, wodurch der Cache ungültig wird.
- Last-Modified: Das Datum der letzten Änderung der Ressource. Der Client kann diese Information verwenden, um eine bedingte Anfrage zu formulieren.
Unterschiede: 200, 304, 404 – wann welche Antwort sinnvoll ist
Im Zusammenspiel von Caching-Strategien spielen verschiedene HTTP-Statuscodes eine Rolle. Verstehen Sie die Unterschiede, um die richtige Entscheidung für Ihre Anwendung zu treffen:
304 status code vs. 200 OK
Ein 304 status code zeigt an, dass eine Ressource unverändert ist und der Client bereits eine gültige Kopie besitzt. Die Serverantwort enthält keinen Nachrichtentext, sondern nur Header-Informationen. Im Gegensatz dazu bedeutet 200 OK, dass die Ressource neu geladen wird und der Client den vollständigen Inhalt erhält. In vielen Fällen führt 304 zu einer deutlichen Leistungssteigerung, während 200 eine vollständige Aktualisierung liefert – beispielsweise bei echten Änderungen der Ressource.
304 status code vs. 404 Not Found
Ein 404 Not Found signalisiert, dass die Ressource nicht existiert. Es handelt sich um eine Fehlermeldung, nicht um eine Prüfung auf Aktualität. 304 Not Modified ist hingegen ein positiver Indikator dafür, dass die Ressource vorhanden ist, aber unverändert geblieben ist. Für Caching-Strategien ist der 304 status code in der Regel wünschenswert, während ein 404 eher auf ein Problem der Verfügbarkeit oder des Zugriffs hindeutet.
Wichtige Header rund um den 304 status code
Um den 304 status code effektiv zu nutzen, spielen Header eine zentrale Rolle. Die Kombination aus Cache-Control, ETag/Last-Modified und weiteren Headern definiert, wie lange Inhalte im Cache bleiben und wann eine Validierung stattfinden soll.
Cache-Control, Expires und Max-Age
Cache-Control ist der modernere Standard und ersetzt viele ältere Mechanismen. Der Directive max-age bestimmt, wie lange eine Ressource im Cache gültig ist. Expires setzt ein konkretes Verfalldatum, das zusammen mit anderen Headern interpretiert wird. Wenn ein Client eine Ressource mit gültigem Cache-Control oder Expires erneut anfragt, kann der Server einen 304 status code verwenden, sofern sich die Ressource seither nicht geändert hat.
ETag, Last-Modified und If-None-Match
ETag ist eine starke Validierung: Jede Ressource erhält eine eindeutige Signatur. Wenn der Client eine If-None-Match-Anfrage mit dem ETag sendet und der Server feststellt, dass die Ressource identisch ist, antwortet er mit 304 Not Modified. Last-Modified funktioniert ähnlich, nutzt aber Datumsangaben statt Signaturen. In vielen Umgebungen kombinieren Webmaster beide Mechanismen, um maximale Genauigkeit bei der Validierung von Caches zu erzielen.
Vary-Header und Cache-Verhalten
Der Vary-Header beeinflusst, wie Caches unterschiedliche Varianten einer Ressource speichern. Bei Inhalten, die von Accept-Encoding, User-Agent oder anderen Faktoren abhängen, sorgt Vary dafür, dass unterschiedliche Versionen nicht verwechselt werden. Ein fälschlich gesetzter Vary-Header kann dazu führen, dass 304 Not Modified fälschlicherweise genutzt wird oder Ressourcen inkorrekt ausgeliefert werden.
Praktische Beispiele: Der Ablauf einer bedingten Anfrage
Nachfolgend finden Sie zwei typische Abläufe, wie der 304 status code in der Praxis auftreten kann. Die Beispiele helfen zu verstehen, wie Client und Server handeln, wenn Inhalte bereits vorhanden sind und ob sie aktualisiert werden müssen.
Beispiel 1: If-Modified-Since
Client-Anfrage: GET /assets/logo.png HTTP/1.1 Host: example.com If-Modified-Since: Wed, 21 Oct 2023 07:28:00 GMT Server-Antwort (wenn unverändert): HTTP/1.1 304 Not Modified Date: Thu, 26 Jan 2026 12:00:00 GMT Cache-Control: max-age=3600
Der Client verwendet die vorhandene Kopie, da das Datum der letzten Änderung nicht überschritten wurde. Die reduzierte Bandbreite spart Zeit und Ressourcen.
Beispiel 2: If-None-Match (ETag)
Client-Anfrage: GET /index.html HTTP/1.1 Host: example.com If-None-Match: "abc123-def456" Server-Antwort (wenn unverändert): HTTP/1.1 304 Not Modified Date: Thu, 26 Jan 2026 12:00:00 GMT Cache-Control: max-age=600 ETag: "abc123-def456"
Der ETag-Ansatz sorgt für eine präzise Validierung. Wenn sich das Ressourcen-Exemplar nicht geändert hat, bleibt der Cache gültig und der Server spart Rechenleistung.
Konfiguration auf Servern: Wie Sie den 304 status code gezielt nutzen
Um den 304 status code effektiv zu unterstützen, müssen Sie richtigen Caching-Strategien in der Serverkonfiguration implementieren. Im Folgenden finden Sie grundlegende Anleitungen für gängige Serverumgebungen.
Apache
In Apache können Sie Cache-Control-Header und ETags aktivieren. Wichtige Schritte:
- Aktivieren Sie das Modul mod_headers, um Cache-Control-Header zu setzen.
- Stellen Sie sicher, dass das Modul mod_deflate oder mod_gzip für effizientes Encoding verwendet wird.
- Verwenden Sie ETag oder Last-Modified, um bedingte Anfragen zu ermöglichen.
Beispielkonfiguration (ausschnitt):
Header set Cache-Control "max-age=3600, public" FileETag MTime Size
Nginx
Nginx verwendet in der Regel das Cache-Control-Verhalten in der Server- oder Location-Konfiguration. Wichtige Punkte:
- Aktivieren Sie das Kompressionsmodul, um Bandbreite zu sparen.
- Nutzen Sie ETag bzw. Last-Modified, um bedingte Anforderungen zu ermöglichen.
- Definieren Sie eine sinnvolle Cache-Strategie pro Ressourcentyp (Statische Dateien vs. dynamische Inhalte).
Beispielkonfiguration (ausschnitt):
location ~* \.(css|js|png|jpg|gif|ico|woff2)$ {
expires 7d;
add_header Cache-Control "public";
}
IIS (Windows Server)
Bei IIS können Sie Caching über die IIS-Verwaltungskonsole konfigurieren oder Web.config-Dateien verwenden, um Cache-Control, ETag und Last-Modified festzulegen. Achten Sie darauf, dass bedingte Anfragen unterstützt werden und der 304 status code sinnvoll ausgelöst wird.
Best Practices für Entwickler und Site-Owner
Um das volle Potenzial des 304 status code auszuschöpfen, folgen hier bewährte Vorgehen, die häufig zu spürbaren Leistungsverbesserungen führen:
Verlässliche Versionskennungen verwenden
ETag und Last-Modified sollten zuverlässig gesetzt werden. Vermeiden Sie häufige unnötige Änderungen an Dateien, die kaum Inhalte verändern, da jede Änderung einen neuen ETag erzeugt und Caching-Validierungen neu beginnen lässt.
Statische Ressourcen priorisieren
Statische Ressourcen wie Stylesheets, Skripte, Bilder und Schriftarten profitieren besonders von 304-Not-Modified-Antworten, da sie oft wiederkehrend abgerufen werden. Planen Sie eine klare Cache-Dauer (z. B. 1 Tag bis mehrere Wochen) für Dateien mit stabilen Inhalten.
Versionierung von Assets
Um Caching-Vorteile bei Änderungen zu erhalten, nutzen Sie einen Cache-Busting-Mechanismus durch Dateinamen- oder Query-Parameter-Änderungen (z. B. style.v2.css). Dadurch können Sie lange Cache-Dauern beibehalten, ohne dass Nutzer veraltete Inhalte sehen.
Vary-Header sinnvoll einsetzen
Der Vary-Header sollte nur dann eingesetzt werden, wenn Ressourcen wirklich abhängig von bestimmten Headern wie Accept-Encoding oder User-Agent sind. Andernfalls kann er das Caching unnötig fragmentieren und Performanceverlust verursachen.
SEO und der 304 status code
Für Suchmaschinen ist der 304 status code ein wichtiger Baustein für schnelle Seiten. Suchmaschinen-Crawler respektieren bedingte Anfragen und profitieren von kürzeren Ladezeiten. Folgende SEO-Aspekte sollten Sie beachten:
Langsame Seiten vermeiden
Eine bemessene Caching-Strategie, die den 304 status code sinnvoll nutzt, reduziert Ladezeiten erheblich. Schnell ladende Seiten verbessern die Nutzererfahrung und unterstützen ein besseres Ranking in Suchmaschinen. 304 Not Modified trägt dazu bei, dass Ressourcen nur bei tatsächlicher Änderung erneut übertragen werden müssen.
Verlässliche Indizes durch klare Header
Saubere ETag- oder Last-Modified-Watter-Header erleichtern Suchmaschinen-Crawlern das Verständnis, wann eine Ressource aktualisiert wurde. Dadurch vermeiden Sie unnötige Neurationen und verbessern die Crawling-Effizienz.
Caching-Hygiene und Duplicate Content
Stellen Sie sicher, dass der Caching-Ansatz keine Duplicate Content-Szenarien erzeugt. Falsche oder widersprüchliche Cache-Header können dazu führen, dass Suchmaschinen veraltete Versionen indexieren oder Ressourcen inkorrekt darstellen. Klare Regeln für Cache, Validierung und Header-Verhalten verhindern diese Probleme.
Häufige Missverständnisse rund um den 304 status code
Beim Arbeiten mit dem 304 status code tauchen immer wieder ähnliche Fehlannahmen auf. Hier klären wir die gängigsten Irrtümer:
304 bedeutet immer, dass Inhalte unverändert bleiben
Ja, 304 Not Modified bedeutet, dass die Ressource seit der letzten Abfrage nicht geändert wurde. Allerdings hängt dies vom korrekten Einsatz der bedingten Anfragen und der richtigen Validierungslogik ab. Fehlerhafte Implementierungen können zu veralteten Caches oder falschen Versionen führen.
304 ist schädlich für dynamische Seiten
Auch für dynamische Inhalte lässt sich der 304 status code sinnvoll nutzen, wenn diese Inhalte in der Regel stabil bleiben und eine Validierungskette vorhanden ist. Wichtige dynamische Bereiche sollten sorgfältig konfiguriert werden, um sicherzustellen, dass Änderungen korrekt erkannt werden und Caching nicht zu Inkonsistenzen führt.
Jeder 200-Status-Response muss 304 ersetzen
Nicht jede Situation verlangt einen 304-Statuscode. In vielen Fällen ist eine vollständige Neuauslieferung sinnvoll, z. B. bei echten Updates, sehr häufigen Änderungen oder personalisierten Inhalten. Der 304 status code ist ein Werkzeug unter vielen, kein Allheilmittel.
Zusammenfassung: Warum der 304 status code Ihr Web-Erlebnis verbessern kann
Der 304 status code ist ein leistungsstarkes Werkzeug, das hilft, Web-Anwendungen schneller, effizienter und benutzerfreundlicher zu gestalten. Durch bedingte Anfragen, robuste Validierungsmechanismen wie ETag und Last-Modified sowie kluge Cache-Control-Strategien können Sie Bandbreite sparen, Ladezeiten verkürzen und Ihre Serverressourcen entlasten. In der Praxis bedeutet das: weniger Datenverkehr, schnellere Seiten, bessere Nutzerzufriedenheit und potenziell bessere SEO-Rankings. Wenn Sie Ihre Web-Anwendungen optimieren, sollten Sie den 304 status code als integralen Bestandteil Ihrer Cache-Strategie betrachten und ihn gezielt dort einsetzen, wo Inhalte stabil bleiben und Wiederverwendung sinnvoll ist.