Dbaj o aktualność treści dzięki funkcji nieaktualnej, działającej w ramach ponownej weryfikacji

dodatkowe narzędzie, które pomoże Ci zachować równowagę między aktualnością a świeżością podczas wyświetlania aplikacji internetowej;

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 75Firefox 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:

Diagram prezentujący informacje z poprzedniej sekcji.

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-revalidatew 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

Baner powitalny autorstwa Samuela Zellera.