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

Dodatkowe narzędzie, które pomaga zrównoważyć szybkość i aktualność aplikacji internetowych.

Jeff Posnick

Co zostało wysłane?

stale-while-revalidate pomaga deweloperom zachować równowagę między natychmiastowym załadowaniem treści z pamięci podręcznej a ich aktualnością i zapewnieniem wykorzystania w przyszłości aktualizacji treści przechowywanych w pamięci podręcznej. Jeśli korzystasz z usługi internetowej lub biblioteki innej firmy, która jest regularnie aktualizowana lub Twoje zasoby własne mają zwykle krótki czas życia, stale-while-revalidate może być przydatnym uzupełnieniem dotychczasowych zasad buforowania.

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

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

Co to oznacza?

Podzielmy funkcję 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, skąd przeglądarka wie, czy odpowiedź w pamięci podręcznej jest „nieaktualna”? Nagłówek odpowiedzi Cache-Control, który zawiera stale-while-revalidate, też powinien zawierać max-age, a o nieaktualności decyduje liczba sekund określona w max-age. Każda odpowiedź w pamięci podręcznej późniejsza niż max-age jest uznawana za nową, a starsze odpowiedzi w pamięci podręcznej są nieaktualne.

Jeśli lokalna odpowiedź z pamięci podręcznej jest wciąż aktualna, można jej użyć w niezmienionej postaci do spełnienia żądania przeglądarki. Z perspektywy organizacji stale-while-revalidate nie trzeba nic robić w tej sytuacji.

Jeśli jednak odpowiedź z pamięci podręcznej jest nieaktualna, przeprowadzana jest kolejna kontrola na podstawie wieku. Czy czas odpowiedzi z pamięci podręcznej mieści się w dodatkowym przedziale czasu określonym przez ustawienie stale-while-revalidate?

Jeśli wiek nieaktualnej odpowiedzi znajdzie się w tym oknie, zostanie ona użyta do zrealizowania żądania przeglądarki. Jednocześnie do sieci wysyłane jest żądanie „ponownej weryfikacji” w sposób, który nie opóźni wykorzystania odpowiedzi z pamięci podręcznej. Zwrócona odpowiedź może zawierać te same informacje co odpowiedź wcześniej przechowywana w pamięci podręcznej lub być inna. W obu przypadkach odpowiedź sieci jest przechowywana lokalnie, zastępując zawartość wcześniej pamięci podręcznej i resetując licznik czasu „aktualności” używany podczas przyszłych porównań funkcji max-age.

Jeśli jednak nieaktualna odpowiedź z pamięci podręcznej jest wystarczająco stara, że nie mieści się w przedziale czasu stale-while-revalidate, nie spełni żądania przeglądarki. Przeglądarka pobierze zamiast tego odpowiedź z sieci i użyje jej zarówno do wykonania początkowego żądania, jak i do zapełnienia lokalnej pamięci podręcznej nową odpowiedzią.

Przykład na żywo

Poniżej znajduje się prosty przykład interfejsu API HTTP, który zwraca bieżącą godzinę, 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 tego czasu zostanie powtórzone w ciągu 1 sekundy, wartość z pamięci podręcznej pozostanie aktualna i używana w niezmienionej postaci bez konieczności ponownego weryfikowania.

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

Jeśli żądanie zostanie powtórzone po ponad 60 sekundach, nieaktualna odpowiedź w ogóle nie będzie używana, a spełnienie żądania przeglądarki i ponowna weryfikacja pamięci podręcznej będą zależały od otrzymania odpowiedzi z sieci.

Poniżej przedstawiliśmy zestawienie tych 3 stanów wraz z przedziałem czasowym, w którym każdy z nich ma zastosowanie w naszym przykładzie:

Diagram przedstawiający informacje z poprzedniej sekcji.

Jakie są typowe przypadki użycia?

Powyższy przykład związany z usługą API „minuty po godzinie” ilustruje oczekiwany przypadek użycia – usługi, które dostarczają informacji, które wymagają odświeżenia, ale w przypadku których akceptowany jest pewien nieaktualność danych.

Mniej niejasnymi przykładami mogą być interfejsy API dotyczące bieżących warunków pogodowych lub nagłówki najważniejszych wiadomości napisane w ciągu ostatniej godziny.

Ogólnie każda odpowiedź aktualizowana w znanym odstępie czasu może być wielokrotnie żądana i statyczna w tym przedziale czasu dobrze nadaje się do krótkoterminowego buforowania za pomocą max-age. Użycie stale-while-revalidate oprócz max-age zwiększa prawdopodobieństwo realizacji przyszłych żądań z pamięci podręcznej z nowszą zawartością, bez blokowania odpowiedzi sieci.

W jaki sposób wchodzi on w interakcje z mechanizmami Service Worker?

Jeśli zdarzyło Ci się słyszeć o tagu stale-while-revalidate, prawdopodobnie było ono w kontekście przepisów używanych w skrypcie service worker.

Używanie nieaktualnego atrybutu w trakcie ponownej weryfikacji za pomocą nagłówka Cache-Control ma pewne podobieństwo do jego stosowania w skrypcie service worker, ale ma też zastosowanie wiele kwestii związanych z koniecznością aktualizacji oraz maksymalnym okresem ważności. Jest jednak kilka kwestii, które należy wziąć pod uwagę, podejmując decyzję, czy wdrożyć podejście oparte na mechanizmach Service Worker czy po prostu polegać na konfiguracji nagłówka Cache-Control.

Użyj metody skryptu service worker, jeśli...

  • Używasz już skryptu service worker w swojej aplikacji internetowej.
  • Potrzebujesz szczegółowej kontroli nad zawartością pamięci podręcznych i chcesz wdrożyć coś, na przykład rzadko używaną zasadę wygaśnięcia. Pomóc w tym może moduł Cache Expiration w module Workbox.
  • Chcesz otrzymywać powiadomienia, gdy nieaktualna odpowiedź zmieni się w tle podczas etapu ponownej weryfikacji. Pomoże Ci w tym moduł Broadcast Cache Update (Aktualizacja pamięci podręcznej) w Workbox.
  • To działanie stale-while-revalidate jest wymagane we wszystkich nowoczesnych przeglądarkach.

Użyj metody Cache-Control, jeśli...

  • Nie musisz zajmować się narzutami związanymi z wdrażaniem i obsługą skryptu service worker aplikacji internetowej.
  • Nie ma problemu, jeśli automatyczne zarządzanie pamięcią podręczną przeglądarki zapobiega nadmiernemu powiększaniu się lokalnych pamięci podręcznych.
  • Podejście, które nie jest obecnie obsługiwane we wszystkich nowoczesnych przeglądarkach, nie stanowi problemu (stan na lipiec 2019 r., a w przyszłości obsługa może się zwiększyć).

Jeśli używasz skryptu service worker i masz włączoną funkcję stale-while-revalidate w przypadku niektórych odpowiedzi w nagłówku Cache-Control, to taki skrypt będzie zazwyczaj wywoływał „pierwsze łamanie zabezpieczeń” przy odpowiadaniu na żądanie. Jeśli skrypt service worker zdecyduje się nie odpowiadać lub w trakcie generowania odpowiedzi wyśle żądanie sieciowe przy użyciu fetch(), zadziała działanie skonfigurowane za pomocą nagłówka Cache-Control.

Więcej informacji

Baner powitalny: Samuel Zeller.