304 Not Modified: dlaczego to sukces, nie błąd

Jak dochodzi do 304

304 to druga połowa dwuetapowej rozmowy. Przy pierwszym żądaniu serwer zwraca zasób razem z walidatorem: ETag, czyli nieprzezroczystym identyfikatorem tej dokładnej wersji, i często datą Last-Modified. Klient zapisuje odpowiedź razem z tymi walidatorami.

Później, gdy zapisana kopia wymaga ponownej walidacji, klient powtarza żądanie i dołącza to, co ma:

• If-None-Match: "abc123" niesie zapisany ETag. To preferowany walidator, bo jest dokładny.
• If-Modified-Since: Wed, 03 Sep 2026 10:00:00 GMT niesie zapisaną datę, używaną, gdy nie ma ETag.

Jeśli zasób się nie zmienił, serwer odpowiada 304 Not Modified z samymi nagłówkami i bez treści, a klient renderuje swoją zapisaną kopię. Jeśli się zmienił, serwer odpowiada 200 z nową treścią i nowymi walidatorami. Oba wyniki to poprawne zachowanie.

Dlaczego 304 to dobra wiadomość, nie błąd

Ludzie widzą 304 w panelu sieci przeglądarki albo analizatorze logów, zauważają, że to nie 200, i zakładają, że coś zawiodło. Nic nie zawiodło. 304 to najtańsza użyteczna odpowiedź w internecie: żadna treść odpowiedzi nie przechodzi przez sieć, więc transfer to kilkaset bajtów zamiast pełnego zasobu, a serwer zwykle unika ponownego generowania zasobu, więc kosztuje mniej CPU niż 200. Strona renderuje się szybciej, bo przeglądarka ponownie używa bajtów, które już ma. Korzystają też roboty indeksujące, bo stabilny ETag dający 304 pozwala wyszukiwarce wydać swój budżet indeksowania na strony, które się zmieniły.

Wysoki odsetek 304 na zasobach statycznych to znak, że cache'owanie jest dobrze skonfigurowane. Jedyne, na co warto zwrócić uwagę, to czy w ogóle potrzebujesz przejścia rewalidacji: dla zasobów wersjonowanych albo z odciskiem palca w nazwie, długie Cache-Control: max-age z immutable pozwala uniknąć nawet 304, bo przeglądarka w ogóle nie pyta.

Kiedy 304 jest problemem

• Nieaktualna strona, która się nie odświeża. Jeśli Twój HTML jest serwowany z walidatorem, który nigdy się nie zmienia, podczas gdy treść się zmienia, przeglądarki wciąż dostają 304, a użytkownicy wciąż widzą starą stronę. To klasyczny błąd "wdrożyłem, ale nikt tego nie widzi".
• 304 bez pasującej zapisanej kopii. Jeśli klient wysyła żądanie warunkowe, do którego nie miał podstaw, albo proxy usuwa treść z 200, klientowi nie zostaje nic do wyrenderowania i strona wygląda na pustą.
• Słabe albo niestabilne ETagi za load balancerem. Gdy kilka backendów generuje różne ETagi dla identycznej treści, każda rewalidacja chybia i dostajesz pełne 200 tam, gdzie oczekiwano 304. Ruch rośnie bez powodu.
• Kompresja zmieniająca walidator. Jeśli ETag różni się między wersją skompresowaną a nieskompresowaną bez poprawnego Vary: Accept-Encoding, pamięci podręczne mogą serwować niewłaściwą rzecz.

Jak testować żądania warunkowe

1. Pobierz zasób i odczytaj jego walidatory:

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

2. Powtórz żądanie z otrzymanym ETag i potwierdź, że serwer odpowiada 304:

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

   Podstaw dokładną wartość ETag, łącznie z cudzysłowami. 200 tutaj oznacza, że rewalidacja nie działa.
3. Jeśli dostajesz 200, gdy oczekiwałeś 304, sprawdź, czy proxy albo CDN usuwa If-None-Match, i czy Twoje backendy zgadzają się co do ETag dla tego samego pliku.
4. Jeśli dostajesz nieaktualną stronę, spraw, żeby walidator zmieniał się razem ze zmianą treści. Nazwy plików z odciskiem palca to najbardziej niezawodna naprawa; w przeciwnym razie wyprowadź ETag z samej treści.
5. Utrzymuj HTML na krótkim czasie świeżości, a zasobom pozwól nieść długi. HTML cache'owany na dzień to coś, co sprawia, że wdrożenie staje się niewidoczne.

Dlaczego kontrole uptime nigdy nie widzą 304

Kontrola uptime żąda strony jak pierwszy odwiedzający, bez If-None-Match i bez If-Modified-Since, więc serwer nie ma z czym porównywać i zawsze odpowiada 200. To właściwe zachowanie domyślne dla dostępności. Oznacza też, że regresje cache'owania w ogóle nie pojawiają się w danych uptime: strona może serwować wszystkim nieaktualną wersję, podczas gdy każde sprawdzenie pozostaje zielone. Asercjonuj treść strony, a nie tylko status, a strona, która przestała się aktualizować, stanie się widoczna jako niezgodność treści. HostTracker oferuje 13 typów monitorów i monitoruje strony internetowe od 2004 roku. Przetestuj nagłówki i status za pomocą narzędzia do kontroli HTTP i zobacz co naprawdę dowodzi 200 OK oraz pełny poradnik o rodzinie 3xx.