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 natychmiastowym działaniem a aktualnością podczas udostępniania aplikacji internetowej.

Jeff Posnick

Co zostało wysłane?

stale-while-revalidate pomaga deweloperom zachować równowagę między szybkością (natychmiastowe wczytywanie treści z pamięci podręcznej) a aktualnością (zapewnienie, że aktualizacje treści z pamięci podręcznej będą używane w przyszłości). Jeśli utrzymujesz usługę internetową lub bibliotekę innej firmy, która jest regularnie aktualizowana, lub Twoje zasoby własne mają zwykle krótki okres ważności, stale-while-revalidate może być przydatnym dodatkiem do istniejących zasad buforowania.

Obsługa ustawienia stale-while-revalidate obok max-age w nagłówku odpowiedzi Cache-Control jest dostępna w Chrome 75 i Firefox 68.

Przeglądarki, które nie obsługują stale-while-revalidate, będą ignorować tę wartość konfiguracji i używać max-age, co wyjaśnię za chwilę.

Co to oznacza?

Podzielmy stale-while-revalidate na 2 części: koncepcję, że odpowiedź z pamięci podręcznej może być nieaktualna, oraz proces ponownej weryfikacji.

Po pierwsze, skąd przeglądarka wie, czy odpowiedź z 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 przez max-age określa nieaktualność. Każda odpowiedź z pamięci podręcznej, która jest nowsza niż max-age, jest uznawana za aktualną, a starsze odpowiedzi z pamięci podręcznej są nieaktualne.

Jeśli odpowiedź zapisana lokalnie w pamięci podręcznej jest nadal aktualna, można jej użyć w niezmienionej postaci do spełnienia żądania przeglądarki. Z perspektywy stale-while-revalidate w tym scenariuszu nie trzeba nic robić.

Jeśli jednak odpowiedź w pamięci podręcznej jest nieaktualna, przeprowadzane jest kolejne sprawdzenie na podstawie wieku: czy wiek odpowiedzi w pamięci podręcznej mieści się w dodatkowym przedziale czasu określonym przez ustawienie stale-while-revalidate?

Jeśli wiek nieaktualnej odpowiedzi mieści się w tym oknie, zostanie ona użyta do spełnienia żądania przeglądarki. Jednocześnie do sieci zostanie wysłane żądanie „ponownej weryfikacji” 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 odpowiedź zapisana wcześniej w pamięci podręcznej lub może się od niej różnić. W obu przypadkach odpowiedź sieci jest przechowywana lokalnie, zastępując poprzednią zawartość pamięci podręcznej i resetując licznik czasu „aktualności” używany podczas przyszłych porównań max-age.

Jeśli jednak nieaktualna odpowiedź z pamięci podręcznej jest na tyle stara, że wykracza poza przedział czasu stale-while-revalidate, nie spełni żądania przeglądarki. Zamiast tego przeglądarka pobierze odpowiedź z sieci i użyje jej zarówno do spełnienia początkowego żądania, jak i do wypełnienia lokalnej pamięci podręcznej nową odpowiedzią.

Przykład na żywo

Poniżej znajdziesz prosty przykład interfejsu HTTP API, który zwraca bieżący czas, a dokładniej bieżącą liczbę minut po godzinie.

W tym scenariuszu serwer WWW używa w odpowiedzi HTTP 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 następnej sekundy, wcześniej zapisana w pamięci podręcznej wartość będzie nadal aktualna i zostanie użyta bez ponownej weryfikacji.

Jeśli żądanie zostanie powtórzone po upływie od 1 do 60 sekund, wartość w pamięci podręcznej będzie nieaktualna, ale zostanie użyta do realizacji żądania do interfejsu API. Jednocześnie „w tle” zostanie wysłane żądanie ponownej weryfikacji, aby wypełnić pamięć podręczną nową wartością do wykorzystania w przyszłości.

Jeśli żądanie zostanie powtórzone po upływie ponad 60 sekund, nieaktualna odpowiedź nie zostanie w ogóle użyta, a zarówno spełnienie żądania przeglądarki, jak i ponowna weryfikacja pamięci podręcznej będą zależeć od otrzymania odpowiedzi z sieci.

Oto zestawienie tych 3 stanów wraz z okresem, w którym każdy z nich obowiązuje w naszym przykładzie:

Schemat ilustrujący informacje z poprzedniej sekcji.

Jakie są typowe przypadki użycia?

Chociaż powyższy przykład usługi interfejsu API „minuty po godzinie” jest wymyślony, ilustruje oczekiwany przypadek użycia – usługi, które dostarczają informacje wymagające odświeżenia, ale w których dopuszczalny jest pewien stopień nieaktualności.

Mniej wymyślne przykłady to interfejs API do sprawdzania aktualnych warunków pogodowych lub najważniejszych nagłówków wiadomości z ostatniej godziny.

Ogólnie rzecz biorąc, każda odpowiedź, która jest aktualizowana w znanych odstępach czasu, prawdopodobnie będzie żądana wielokrotnie i jest statyczna w tych odstępach czasu, jest dobrym kandydatem do krótkoterminowego 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 pamięci podręcznej z nowszą zawartością, bez blokowania odpowiedzi sieci.

Jak działa w połączeniu ze skryptami service worker?

Jeśli znasz już stale-while-revalidate, to prawdopodobnie w kontekście przepisów używanych w skrypcie service worker.

Używanie nagłówka Cache-Control do obsługi strategii stale-while-revalidate jest pod pewnymi względami podobne do używania jej w skrypcie service worker. Wiele z tych samych kwestii dotyczących kompromisów związanych ze świeżością i maksymalnym czasem życia ma zastosowanie w obu przypadkach. Jednak przy podejmowaniu decyzji, czy wdrożyć podejście oparte na skryptach service worker, czy po prostu polegać na konfiguracji nagłówka Cache-Control, należy wziąć pod uwagę kilka kwestii.

Użyj skryptu service worker, jeśli:

  • W aplikacji internetowej używasz już skryptu service worker.
  • Potrzebujesz szczegółowej kontroli nad zawartością pamięci podręcznych i chcesz wdrożyć coś w rodzaju zasady wygaszania najmniej używanych elementów. Może w tym pomóc moduł Cache Expiration Workboxa.
  • Chcesz otrzymywać powiadomienia, gdy nieaktualna odpowiedź zmieni się w tle podczas etapu ponownej weryfikacji. Może w tym pomóc moduł Broadcast Cache Update Workboxa.
  • To zachowanie stale-while-revalidate jest potrzebne we wszystkich nowoczesnych przeglądarkach.

Użyj podejścia Cache-Control, jeśli…

  • Nie chcesz zajmować się wdrażaniem i utrzymywaniem skryptu service worker w aplikacji internetowej.
  • Nie masz nic przeciwko temu, aby automatyczne zarządzanie pamięcią podręczną przeglądarki zapobiegało zbyt dużemu rozmiarowi lokalnej pamięci podręcznej.
  • Nie przeszkadza Ci, że to podejście nie jest obecnie obsługiwane we wszystkich nowoczesnych przeglądarkach (stan na lipiec 2019 r.; w przyszłości może się to zmienić).

Jeśli używasz skryptu service worker i masz też włączoną funkcję stale-while-revalidate w przypadku niektórych odpowiedzi za pomocą nagłówka Cache-Control, skrypt service worker będzie zazwyczaj „pierwszy w kolejce” do odpowiedzi na żądanie. Jeśli skrypt service worker zdecyduje się nie odpowiadać lub jeśli w procesie generowania odpowiedzi wyśle żądanie sieciowe za pomocą fetch(), zachowanie skonfigurowane za pomocą nagłówka Cache-Control zacznie obowiązywać.

Więcej informacji