Czym jest cache przeglądarki i jak prawidłowo konfigurować nagłówki HTTP Cache-Control?

Jak działa pamięć podręczna przeglądarki?

Gdy przeglądarka pobiera zasób (np. plik CSS, obrazek lub plik skryptu), analizuje nagłówki odpowiedzi HTTP przesłane przez serwer webowy. Na ich podstawie decyduje, czy dany plik może zostać zapisany na dysku lub w pamięci RAM, jak długo pozostaje „świeży” (fresh) oraz w jaki sposób należy weryfikować jego ważność po upływie tego czasu.

Serwowanie plików bezpośrednio z pamięci lokalnej (Memory Cache lub Disk Cache) eliminuje rzutujące na wydajność opóźnienia RTT (Round Trip Time), co przekłada się na natychmiastowe ładowanie powracających wizyt i stabilizację metryk wydajnościowych. Ograniczenie niepotrzebnych powtórnych pobrań chroni stronę przed spowolnieniami, na które tak wrażliwa jest optymalizacja LCP na urządzeniach mobilnych.

Anatomia nagłówka Cache-Control

Podstawowym dyrektywem sterującym zachowaniem przeglądarek i serwerów pośredniczących (CDN, proxy) jest nagłówek Cache-Control. Zawiera on zestaw instrukcji oddzielonych przecinkami, które określają dostępność i czas życia zasobu.

Najważniejsze dyrektywy i ich znaczenie:

• max-age=<seconds>: Określa czas (w sekundach), przez jaki zasób jest uznawany za świeży i może być serwowany bez kontaktu z serwerem (np. max-age=31536000 dla 1 roku).
• no-cache: Wbrew nazwie nie zabrania zapisywania pliku w cache. Nakazuje jednak przeglądarce obowiązkową rewalidację (sprawdzenie na serwerze za pomocą ETag lub Last-Modified) przed każdym ponownym użyciem zasobu.
• no-store: Całkowity zakaz zapisywania zasobu w jakiejkolwiek pamięci podręcznej. Stosowany bezwzględnie dla wrażliwych danych osobowych, paneli logowania czy danych finansowych.
• public / private: public oznacza, że odpowiedź może być buforowana przez serwery CDN i proxy. private zastrzega, że odpowiedź jest przeznaczona wyłącznie dla końcowej przeglądarki użytkownika.
• immutable: Informuje przeglądarkę, że zasób nigdy się nie zmieni w trakcie trwania jego max-age. Zapobiega niepotrzebnemu wysyłaniu zapytań sprawdzających przy ręcznym odświeżaniu strony przez użytkownika (F5).

Sprawdzona strategia: Versioned Assets vs Unversioned HTML

Współczesne podejście do architektury zasobów opiera się na dwóch przeciwstawnych, ale uzupełniających się wzorcach konfiguracji:

1. Zasoby ze zmienną nazwą (Cache-Busting / Haszowanie)

Nowoczesne bundlery kodu (np. Webpack, Vite) dodają do nazw plików unikalny hasz z zawartości (np. main.a8f3b2.js lub style.9c2d11.css). W przypadku zmiany chociażby jednego znaku w kodzie nazwa pliku ulega zmianie, tworząc nowy zasób.

Dla takich plików stosujemy agresywną, maksymalną strategię buforowania:

Cache-Control: public, max-age=31536000, immutable

2. Dokumenty HTML (Brak niezmiennego hasza)

Plik index.html musi zawierać odnośniki do najnowszych nazw plików z haszem. Gdybyśmy zabuforowali plik HTML na rok, użytkownicy nigdy nie zobaczyliby nowej wersji aplikacji! Dlatego pliki HTML powinny zawsze wymuszać rewalidację:

Cache-Control: no-cache

Dzięki temu przeglądarka przy każdej wizycie wysyła ultra-szybkie zapytanie walidacyjne do serwera (zwykle odpowiadającego lekkim kodem statusu 304 Not Modified), upewniając się, że pobiera aktualne odnośniki do kodu.

Rewalidacja zasobów za pomocą ETag i Last-Modified

Gdy czas max-age zasobu wygaśnie (lub gdy używamy dyrektywy no-cache), przeglądarka wysyła zapytanie nagłówkowe do serwera z prośbą o sprawdzenie, czy plik uległ zmianie.

Służą do tego dwa nagłówki walidacji:

• ETag (Entity Tag): Unikalny token (hasz) reprezentujący dokładny stan zawartości pliku na serwerze. Przeglądarka przesyła go w nagłówku If-None-Match.
• Last-Modified: Data ostatniej modyfikacji pliku na dysku serwera. Przeglądarka przesyła ją w nagłówku If-Modified-Since.

Jeśli zawartość na serwerze jest identyczna z zapisaną lokalnie, serwer zwraca odpowiedź z kodem statusu 304 Not Modified bez treści (empty body). Przeglądarka wie wtedy, że może bezpiecznie użyć pliku z dysku, minimalizując zużycie transferu.

Nowoczesna dyrektywa: stale-while-revalidate

Aby połączyć zalety błyskawicznego serwowania z pamięci lokalnej z pewnością posiadania aktualnych danych, warto wykorzystać rozszerzenie stale-while-revalidate:

Cache-Control: max-age=3600, stale-while-revalidate=86400

Taka konfiguracja mówi przeglądarce: „Jeśli plik ma mniej niż godzinę (max-age=3600), użyj go od razu. Jeśli ma od 1 do 24 godzin, natychmiast wyświetl nieświeży plik użytkownikowi, ale w tle wyślij ciche zapytanie do serwera i zaktualizuj lokalną pamięć podręczną na przyszłość”.

Wdrożenie przemyślanej polityki buforowania eliminuje zbędne obciążenie serwerów i zapobiega gromadzeniu barier wydajnościowych, drastycznie redukując zalegający dług technologiczny w obszarze infrastruktury i optymalizacji aplikacji.