dodatkowe narzędzie, które pomoże Ci zachować równowagę między aktualnością a świeżością podczas wyświetlania aplikacji internetowej;
Co zostało wysłane?
stale-while-revalidate
pomaga deweloperom znaleźć równowagę między natychmiastowością (natychmiastowe wczytywanie treści z pamięci podręcznej) a świeżością (zapewnienie, że aktualizacje treści z pamięci podręcznej będą używane w przyszłości). Jeśli korzystasz z usługi internetowej lub biblioteki innej firmy, która jest regularnie aktualizowana, lub jeśli Twoje zasoby własne mają krótki okres ważności, możesz użyć opcji stale-while-revalidate
, aby uzupełnić swoje dotychczasowe zasady dotyczące buforowania.
Obsługa ustawiania wartości stale-while-revalidate
obok wartości max-age
w nagłówku odpowiedzi Cache-Control
jest dostępna w Chrome 75 i Firefox 68.
Przeglądarki, które nie obsługują wartości stale-while-revalidate
, będą ignorować tę wartość konfiguracji i używać wartości max-age
, co wyjaśnię za chwilę.
Co to oznacza?
Rozłóżmy stale-while-revalidate
na 2 części: pomysł, że odpowiedź z pamięci podręcznej może być nieaktualna, oraz proces ponownej weryfikacji.
Po pierwsze, jak przeglądarka wie, czy odpowiedź w pamięci podręcznej jest „nieaktualna”? Nagłówek odpowiedzi Cache-Control
, który zawiera stale-while-revalidate
, powinien też zawierać max-age
, a liczba sekund określona w max-age
określa, jak bardzo dane są nieaktualne. Każda odpowiedź z pamięci podręcznej nowsza niż max-age
jest uważana za świeżą, a starsze odpowiedzi z pamięci podręcznej są nieaktualne.
Jeśli odpowiedź z pamięci podręcznej na urządzeniu lokalnym jest nadal aktualna, można jej użyć do zrealizowania żądania przeglądarki. Z perspektywy stale-while-revalidate
w tym scenariuszu nie ma nic do zrobienia.
Jeśli jednak odpowiedź z pamięci podręcznej jest nieaktualna, przeprowadzana jest kolejna kontrola wieku: czy wiek odpowiedzi z pamięci podręcznej mieści się w dodatkowym oknie czasowym ustawionym w opcji stale-while-revalidate
?
Jeśli wiek nieaktualnej odpowiedzi mieści się w tym przedziale, zostanie ona użyta do zrealizowania żądania przeglądarki. Jednocześnie wysyłane jest żądanie „ponownego uwierzytelnienia” do sieci w taki sposób, aby nie opóźniać korzystania z odpowiedzia z pamięci podręcznej. Zwrócona odpowiedź może zawierać te same informacje co wcześniej zapisana w pamięci podręcznej, ale może też być inna. W obu przypadkach odpowiedź sieci jest przechowywana lokalnie, zastępując wcześniejszą zawartość pamięci podręcznej, i resetuje zegar „świeżości” używany podczas kolejnych porównań max-age
.
Jeśli jednak nieaktualna odpowiedź z pamięci podręcznej jest na tyle stara, że wykracza poza okno czasowestale-while-revalidate
, nie spełni ona żądania przeglądarki. Zamiast tego przeglądarka pobierze odpowiedź z sieci i użyje jej do zrealizowania początkowego żądania oraz do wypełnienia lokalnej pamięci podręcznej nową odpowiedzią.
Przykład na żywo
Poniżej znajdziesz prosty przykład interfejsu API HTTP służącego do zwracania bieżącego czasu, a ściślej mówiąc bieżącej liczby minut po godzinie.
W tym scenariuszu serwer WWW używa nagłówka Cache-Control
w odpowiedzi HTTP:
Cache-Control: max-age=1, stale-while-revalidate=59
To ustawienie oznacza, że jeśli żądanie dotyczące czasu zostanie powtórzone w ciągu 1 sekundy, wcześniej zapisane w pamięci podręcznej dane będą nadal aktualne i użyte bez ponownej weryfikacji.
Jeśli żądanie zostanie powtórzone w ciągu 1–60 sekund, wartość z poziomu pamięci podręcznej będzie nieaktualna, ale zostanie użyta do realizacji żądania interfejsu API. Jednocześnie w tle zostanie wysłane żądanie ponownej weryfikacji, aby wypełnić pamięć podręczną świeżą wartością na przyszłość.
Jeśli żądanie zostanie powtórzone po upływie ponad 60 sekund, nieużyteczna odpowiedź nie zostanie w ogóle wykorzystana, a spełnienie żądania przeglądarki i potwierdzanie pamięci podręcznej będą zależeć od otrzymania odpowiedzi od sieci.
Oto opis tych 3 stanów wraz z okresem, w którym każdy z nich ma zastosowanie w naszym przykładzie:
Jakie są typowe zastosowania?
Powyższy przykład usługi interfejsu API „minuty po godzinie” jest wymyślony, ale obrazuje oczekiwany przypadek użycia – usługi, które dostarczają informacji, które wymagają odświeżenia, ale w przypadku których dopuszczalna jest pewna nieaktualność.
Mniej wymyślnym przykładem może być interfejs API do sprawdzania aktualnych warunków pogodowych lub najpopularniejszych nagłówków wiadomości z ostatniej godziny.
Ogólnie rzecz biorąc, każda odpowiedź, która jest aktualizowana w znanym interwale, jest prawdopodobnie żądana wielokrotnie i jest statyczna w tym zakresie, jest dobrym kandydatem do krótkotrwałego buforowania za pomocą max-age
. Użycie stale-while-revalidate
oprócz max-age
zwiększa prawdopodobieństwo, że przyszłe żądania będą mogły być realizowane z poziomu pamięci podręcznej z aktualniejszymi treściami, bez blokowania odpowiedzi sieci.
Jak działa on w połączeniu z usługami działającymi w tle?
Jeśli słyszałeś(-aś) o stale-while-revalidate
, prawdopodobnie było to w kontekście przepisów używanych w elementach service worker.
Używanie nagłówka Cache-Control
w celu ponownej weryfikacji w przypadku nieaktualnych danych ma pewne podobieństwa do używania tego mechanizmu w usługach w tle. Obowiązują też podobne zasady dotyczące kompromisów w zakresie świeżości i maksymalnego czasu trwania. Należy jednak wziąć pod uwagę kilka kwestii, aby zdecydować, czy zastosować podejście oparte na serwisie workera, czy tylko polegać na konfiguracji nagłówka Cache-Control
.
Użyj podejścia opartego na serwisach działających w tle, jeśli:
- W aplikacji internetowej używasz już skryptu service worker.
- Chcesz mieć precyzyjną kontrolę nad zawartością pamięci podręcznej i wdrożyć zasadę wygasania, np. zasadę dotyczącą najmniej ostatnio używanych. W tym przypadku może Ci pomóc moduł Wygasanie pamięci podręcznej w Workbox.
- Chcesz otrzymywać powiadomienia, gdy nieaktualna odpowiedź zmieni się w tle podczas kroku ponownej weryfikacji. W tym przypadku może Ci pomóc moduł Broadcast Cache Update w Workbox.
- Musisz mieć to
stale-while-revalidate
w przypadku wszystkich nowoczesnych przeglądarek.
Użyj podejścia Cache-Control, jeśli:
- Nie chcesz zajmować się dodatkowymi kosztami związanymi z wdrażaniem i utrzymywaniem skryptu service worker w przypadku swojej aplikacji internetowej.
- zgadzasz się na automatyczne zarządzanie pamięcią podręczną przeglądarki, aby zapobiec zbyt dużemu wzrostowi rozmiaru pamięci podręcznej na urządzeniu.
- akceptujesz podejście, które nie jest obecnie obsługiwane we wszystkich nowoczesnych przeglądarkach (stan na lipiec 2019 r.; w przyszłości może być obsługiwane w większym zakresie).
Jeśli używasz usługi workera i masz włączoną usługę stale-while-revalidate
dla niektórych odpowiedzi za pomocą nagłówka Cache-Control
, usługa workera będzie ogólnie pierwsza w odpowiedzi na żądanie. Jeśli pracownik usługi zdecyduje się nie odpowiadać lub w trakcie generowania odpowiedzi wyśle żądanie sieci za pomocą fetch()
, zadziała zachowanie skonfigurowane za pomocą nagłówka Cache-Control
.
Więcej informacji
stale-while-revalidate
w specyfikacji Fetch API.- RFC 5861, który zawiera pierwszą specyfikację
stale-while-revalidate
. - Pamięć podręczna HTTP: pierwsza linia obrony z poradnika „Sprawdzanie poprawności sieci” na tej stronie.
Baner powitalny autorstwa Samuela Zellera.