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

Schemat obrazują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ść.

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

Baner powitalny autorstwa Samuela Zellera.