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 zachować równowagę między szybkością ładowania treści z pamięci podręcznej i aktualnością, dzięki czemu aktualizacje treści znajdujących się w pamięci podręcznej są 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ć 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 czas przechowywania 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 zostanie wysłane żądanie „ponownego uwierzytelnienia” do sieci w sposób, który nie opóźni użycia odpowiedzi z pamięci podręcznej. Zwrócona odpowiedź może zawierać te same informacje co wcześniej zapisana w pamięci podręcznej odpowiedź lub może być inna. W obu przypadkach odpowiedź sieci jest przechowywana lokalnie, zastępując wcześniejszą zawartość pamięci podręcznej i resetując 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 stale-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, który zwraca bieżący czas, a konkretnie jest to aktualna liczba minut w przeszłości.
W takim przypadku serwer WWW w odpowiedzi HTTP używa tego nagłówka Cache-Control
:
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żyteczne odpowiedzi nie zostaną w ogóle wykorzystane, a spełnienie żądania przeglądarki i potwierdzanie pamięci podręcznej będą zależeć od otrzymania odpowiedzi od sieci.
Oto zestawienie tych 3 stanów wraz z przedziałem czasu, 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ść.
Mniejszym przykładem może być interfejs API uwzględniający bieżące warunki pogodowe lub nagłówki najważniejszych 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 interwale, jest dobrym kandydatem do krótkotrwałego buforowania za pomocą max-age
. Użycie metody stale-while-revalidate
w połączeniu z zasadą max-age
zwiększa prawdopodobieństwo realizacji przyszłych żądań z pamięci podręcznej przy użyciu nowszych treści bez blokowania odpowiedzi sieciowych.
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. Jest jednak kilka kwestii, które warto wziąć pod uwagę podczas podejmowania decyzji, czy chcesz wdrożyć metodę opartą na skryptach service worker, czy po prostu konfigurację nagłówka Cache-Control
.
Użyj podejścia opartego na serwisach workerów, 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ć zasady wygasania, takie jak zasada wygasania najstarszych elementów. 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. Pomóc w tym może moduł Broadcast Cache Update (Aktualizacja pamięci podręcznej transmisji) 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 czynnościami 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ą przez przeglądarkę, 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.