Jak działa HTTP stale-while-revalidate

W tym artykule wyjaśnię, jak działa mechanizm HTTP stale-while-revalidate, jakie ma zastosowania w praktyce, jakie są jego ograniczenia oraz jak go poprawnie wdrożyć po stronie serwera i w sieciach dystrybucji treści. Skupię się na aspektach technicznych i operacyjnych: nagłówkach HTTP, zachowaniu przeglądarek i serwerów pośredniczących, integracji z systemami typu CDN oraz z narzędziami po stronie klienta, takimi jak service worker. Celem jest pokazanie, kiedy warto użyć tej strategii, jak ją skonfigurować i na co zwracać uwagę, aby nie narazić aplikacji na nieoczekiwane problemy z consistency i bezpieczeństwem.

Czym jest stale-while-revalidate i jak działa

Mechanizm stale-while-revalidate został opisany w RFC 5861 jako rozszerzenie semantyki nagłówka Cache-Control. Pozwala on podmiotom pośredniczącym (przeglądarkom, proxy, CDN) na serwowanie przeterminowanej, ale dostępnej wersji zasobu (ang. stale) jednocześnie inicjując w tle proces odświeżania kopii z serwera źródłowego. Dzięki temu końcowy użytkownik otrzymuje odpowiedź szybko, a serwer wykonuje aktualizację cache bez blokowania odpowiedzi.

W praktyce nagłówek wygląda zwykle tak: Cache-Control: max-age=60, stale-while-revalidate=30. Oznacza to, że przez pierwsze 60 sekund zasób jest świeży i może być serwowany bez rewalidacji. Po upływie tych 60 sekund, przez następne 30 sekund proxy lub przeglądarka może zwrócić przeterminowaną wersję natychmiast, a jednocześnie wykonać w tle żądanie do serwera źródłowego, aby pobrać nową wersję i zaktualizować cache. Po upływie 90 sekund (60 + 30) zasób jest uważany za przeterminowany i zwykle musi być ponownie pobrany przed wysłaniem odpowiedzi, chyba że inne dyrektywy pozwalają inaczej.

Kluczowe pojęcia związane z tym mechanizmem to: wiek zasobu (Age), czas życia w cache (TTL / max-age), oraz proces rewalidacji (np. użycie nagłówków ETag lub Last-Modified z warunkowymi żądaniami If-None-Match / If-Modified-Since). Stale-while-revalidate wpływa głównie na doświadczenie użytkownika — zmniejsza latency, a więc opóźnienie, które odczuwa użytkownik oczekujący na odpowiedź.

Dlaczego i kiedy stosować stale-while-revalidate

Zwiększenie szybkości i dostępności

Główną zaletą stosowania stale-while-revalidate jest możliwość serwowania treści natychmiast, nawet jeśli są one już nieco przeterminowane, przy jednoczesnym zapewnieniu, że kopia w cache zostanie zaktualizowana w tle. To rozwiązanie jest przydatne tam, gdzie priorytetem jest szybkie wyświetlanie strony lub odpowiedzi API, a niewielka nieświeżość treści jest akceptowalna.

Uspokojenie obciążenia źródła danych

W scenariuszach, gdy wiele żądań trafia jednocześnie do jednego zasobu (np. popularna strona główna, plik JavaScript czy JSON z danymi), stale-while-revalidate ogranicza nagły wzrost liczby żądań do serwera źródłowego. Proxy lub CDN mogą serwować przeterminowaną wersję, a następnie zaktualizować cache tylko raz (lub ograniczoną liczbę razy), zamiast dopuszczać do wielu równoległych odświeżeń.

Przykłady zastosowań

Pliki statyczne: skrypty, style, obrazy — tam, gdzie drobna opóźniona aktualizacja jest akceptowalna.
API zwracające dane niekrytyczne, np. listy artykułów, metadane — aby poprawić percepcję szybkości aplikacji.
Edge caching na CDN: serwowanie starej kopii użytkownikom z różnych regionów, podczas gdy edge node odświeża zasób wobec origin.

Współpraca z innymi dyrektywami i mechanizmami

Mechanizm ten nie działa w próżni — warto rozumieć, jak współdziała z innymi nagłówkami i mechanizmami HTTP:

Cache-Control: max-age — definiuje okres, w którym odpowiedź jest uważana za świeżą. stale-while-revalidate zaczyna działać po przekroczeniu max-age.
ETag i Last-Modified — pozwalają na wydajną rewalidację: serwer może zwrócić 304 Not Modified, co minimalizuje transfer.
stale-if-error — podobna dyrektywa, która pozwala na serwowanie przeterminowanej kopii w sytuacji błędu przy odświeżaniu origin (np. gdy origin zwraca 500). To przydatne do zachowania dostępności.
Vary — decyduje, które nagłówki wpływają na wariant odpowiedzi w cache; przy niewłaściwej konfiguracji może prowadzić do nieefektywnego cachowania.

Implementacja po stronie serwera i CDN

Stosowanie stale-while-revalidate wymaga skonfigurowania odpowiednich nagłówków na serwerze origin lub reguł na CDN/edge. W większości rozwiązań wystarczy dodać/zmodyfikować nagłówek Cache-Control w odpowiedzi HTTP. Przykład prostego nagłówka: Cache-Control: public, max-age=60, stale-while-revalidate=30.

W praktycznych wdrożeniach należy pamiętać o kilku kwestiach:

Jeśli używasz CDN, sprawdź, czy CDN honoruje dyrektywę stale-while-revalidate; nie wszystkie dostawcy implementują ją identycznie. Niektóre platformy mają własne mechanizmy edge revalidation i dodatkowe opcje konfiguracji.
Ustawienia rewalidacji mogą być różne dla typów plików: dłuższy max-age dla zasobów statycznych, krótszy dla dynamicznych odpowiedzi API.
Używaj nagłówków ETag lub Last-Modified, aby rewalidacja była ekonomiczna (304 Not Modified zamiast pełnego pobierania treści).
Upewnij się, że odpowiedź jest oznaczona jako public lub private w zależności od tego, czy może być cachowana przez pośredników.

Popularne CDN-y (Cloudflare, Fastly, Akamai) często oferują zaawansowane opcje: reguły cache na poziomie edge, synchronizację purges, oraz zaawansowane polityki rewalidacji. W konfiguracji Varnish czy Nginx można dodatkowo obsłużyć logikę background fetch lub stale-while-revalidate na poziomie serwera pośredniczącego, co pozwala kontrolować liczbę jednoczesnych odświeżeń i zachowanie przy błędach.

Zachowanie przeglądarek i po stronie klienta

Warto odróżnić dwa miejsca, gdzie caching zachodzi: po stronie klienta (przeglądarka, service worker) i po stronie sieci (CDN/proxy). Przeglądarki webowe częściowo implementują dyrektywy typu stale-while-revalidate, ale rzadziej niż serwery pośredniczące. Dlatego w aplikacjach webowych często stosuje się dodatkowo service worker, aby zrealizować logikę Stale-While-Revalidate po stronie klienta.

Service worker: wzorzec Stale-While-Revalidate

W service workerze można zaimplementować strategię, która najpierw zwraca kopię z cache, a równolegle pobiera z sieci i aktualizuje cache. Biblioteki takie jak Workbox oferują gotowe strategie o tej nazwie. Implementacja po stronie klienta daje pełną kontrolę nad tym, które zasoby mogą być serwowane przeterminowane, jak często je odświeżać i jak obsługiwać błędy.

Zaleta: pełna kontrola, lepsze UX (szybkie ładowanie), możliwość dostosowania logiki do rodzaju zasobu.
Wada: większa złożoność, konieczność testowania scenariuszy offline i konfliktów wersji danych.

Należy pamiętać, że celem service workera nie jest zastąpienie mechanizmów serwerowych, lecz uzupełnienie ich tam, gdzie wymagana jest większa kontrola klienta.

Ryzyka i pułapki

Choć stale-while-revalidate jest potężnym narzędziem poprawiającym wydajność, istnieją pułapki, na które warto zwrócić uwagę:

Niepożądana nieświeżość danych — w zależności od aplikacji, nawet krótki okres przeterminowania może prowadzić do widocznych rozbieżności w treści (np. w systemach finansowych, koszykach zakupów, statusach zamówień).
Cache poisoning — jeśli mechanizmy weryfikacji tożsamości lub Vary są źle ustawione, można przypadkowo serwować zawartość dla niewłaściwego użytkownika. Ważne, by odpowiedzi zawierające dane wrażliwe miały nagłówek private lub były wyłączone z cachowania.
Stormy revalidation — gdy wiele edge node’ów jednocześnie stara się zrevalidować ten sam zasób, może to prowadzić do chwilowego wzrostu obciążenia origin. Mechanizmy takie jak single-flight deduplication na edge mogą temu zapobiec.
Niewystarczające monitorowanie — bez metryk trudno ocenić, czy stale-while-revalidate poprawia rzeczywiste metryki UX i jednocześnie nie wprowadza błędów. Monitoruj wskaźniki 200 vs 304, hit ratio cache, czas odpowiedzi i błędy origin.

Najlepsze praktyki

Dobierz wartości max-age i stale-while-revalidate odpowiednio do charakteru zasobu. Dla plików statycznych można przyjąć dłuższe okresy, dla dynamicznych skrócić TTL i dodać krótkie stale-while-revalidate.
Stosuj ETag lub Last-Modified, aby rewalidacja była lekka.
Oznaczaj zasoby jako public lub private zgodnie z wymaganiami bezpieczeństwa.
Testuj scenariusze błędów: co się stanie, gdy origin nie odpowiada lub zwraca błąd? Rozważ użycie stale-if-error jako uzupełnienia.
Wprowadź mechanizmy ograniczające jednoczesne odświeżenia (throttling, single-flight) po stronie edge lub serwera pośredniczącego.
Monitoruj metryki cache: hit ratio, liczba revalidacji, transfer origin, czasy odpowiedzi. Dane te pomogą dobrać optymalne wartości polityk.

Przykładowe scenariusze i porównania

Przykład 1 — dynamiczne API z dużą liczbą odczytów i rzadkimi zmianami: zastosuj Cache-Control: public, max-age=10, stale-while-revalidate=30. To pozwoli serwować szybkie odpowiedzi przy dużej liczbie odczytów, a origin będzie aktualizowany w tle. Jeśli zmiany są krytyczne, rozważ krótszy max-age lub dodatkowe mechanizmy push/invalidacji.

Przykład 2 — strona z często aktualizowanymi cenami: tutaj ryzyko jest wyższe. Lepiej ustawić niższy max-age i rozważyć brak stale-while-revalidate lub bardzo krótki czas stale, by uniknąć prezentacji nieaktualnych cen.

Porównanie z innymi strategiami:

no-cache / must-revalidate — gwarantują, że serwer sprawdzi aktualność przed wydaniem odpowiedzi, ale kosztują dodatkowe żądania i zwiększone opóźnienia.
long max-age bez rewalidacji — daje wysoką wydajność, ale ryzyko długotrwałej nieświeżości.
stale-while-revalidate — kompromis: niskie opóźnienia przy umiarkowanym poziomie nieświeżości.

Operacyjne aspekty wdrożenia i testowania

Przed wdrożeniem na produkcję przeprowadź testy obciążeniowe i scenariusze awaryjne. Sprawdź, jak zachowuje się aplikacja, gdy origin zwraca błędy, gdy sieć jest wolna, oraz jak CDN obsługuje revalidation. Upewnij się, że logowanie i metryki pozwalają na śledzenie, ile odpowiedzi zostało podane z cache jako stale, ile spowodowało rewalidację i ile zwrócono 304 vs 200. To istotne dla zrozumienia wpływu mechanizmu na koszty transferu i obciążenie serwera.

Ważne jest także planowanie procesów czyszczenia cache: purge, invalidation i wersjonowanie zasobów (np. fingerprinting plików statycznych). Niezależnie od stale-while-revalidate, wdrożenie mechanizmu wersjonowania plików zapewnia natychmiastową aktualizację dla zasobów, które nie mogą być przeterminowane.

Podsumowanie technicznych korzyści bez konkluzji

Mechanizm stale-while-revalidate daje możliwość poprawy percepcji szybkości aplikacji i zmniejszenia opóźnień dzięki natychmiastowemu serwowaniu dostępnej kopii zasobu, jednocześnie zapewniając, że cache będzie zaktualizowany w tle. Aby jednak osiągnąć oczekiwane korzyści, konieczne jest świadome dobieranie parametrów, testy i monitorowanie. Współpraca z CDN i odpowiednia konfiguracja nagłówków HTTP oraz użycie mechanizmów takich jak ETag i stale-if-error znacząco poprawiają efektywność i odporność rozwiązania, a implementacje po stronie klienta przy użyciu service worker pozwalają uzyskać większą kontrolę nad zachowaniem cache na poziomie przeglądarki. Zachowaj ostrożność przy danych krytycznych i stosuj polityki cachowania zgodne z wymaganiami bezpieczeństwa i prywatności.