Pamięć podręczna środowiska wykonawczego odnosi się do stopniowego dodawania odpowiedzi do pamięci podręcznej na bieżąco. Choć buforowanie środowiska wykonawczego nie zwiększa niezawodności bieżącego żądania, może pomóc zwiększyć wiarygodność przyszłych żądań dotyczących tego samego adresu URL.
Przykładem może być pamięć podręczna HTTP przeglądarki. Jest wypełniana dopiero po wysłaniu żądania dotyczącego danego adresu URL. Mechanizmy service worker pozwalają jednak na wdrożenie buforowania w czasie działania aplikacji, które wykracza poza możliwości samej pamięci podręcznej HTTP.
Przygotowanie strategiczne
W odróżnieniu od wstępnego zapisywania (które zawsze próbuje wyświetlać zestaw wstępnie zdefiniowanych plików z pamięci podręcznej), buforowanie w czasie działania może na wiele sposobów łączyć dostęp do sieci i pamięci podręcznej. Każda kombinacja jest zwykle nazywana strategią buforowania. Kluczowe strategie buforowania:
- Priorytetowe w działaniu sieci
- Przede wszystkim w pamięci podręcznej
- Nieaktualny podczas ponownej weryfikacji
Priorytetowe w działaniu sieci
W tym podejściu skrypt service worker najpierw próbuje pobrać odpowiedź z sieci. Jeśli żądanie sieciowe zostanie zrealizowane, to świetnie. Odpowiedź jest zwracana do aplikacji internetowej, a jej kopia jest przechowywana przy użyciu interfejsu Cache Storage API. Może to być utworzenie nowego wpisu lub zaktualizowanie poprzedniego wpisu dla tego samego adresu URL.
Jeśli żądanie sieciowe nie powiedzie się całkowicie lub zwrócenie odpowiedzi trwa zbyt długo, zamiast tego zwracana jest najnowsza odpowiedź z pamięci podręcznej.
Przede wszystkim w pamięci podręcznej
Strategia skoncentrowana na pamięci podręcznej jest w praktyce przeciwieństwem skoncentrowanego na sieci. W tym podejściu, gdy mechanizm Service Worker przechwytuje żądanie, najpierw używa interfejsu Cache Storage API, aby sprawdzić, czy jest dostępna odpowiedź w pamięci podręcznej. Jeśli tak, odpowiedź jest zwracana do aplikacji internetowej.
Jeśli jednak wystąpi brak w pamięci podręcznej, skrypt service worker przejdzie do sieci i spróbuje pobrać w niej odpowiedź. Zakładając, że żądanie sieciowe zostanie zrealizowane, jest zwracane do aplikacji internetowej, a kopia jest zapisywana w pamięci podręcznej. Ta kopia z pamięci podręcznej zostanie użyta do ominięcia sieci, gdy następnym razem zostanie wysłane żądanie tych samych adresów URL.
Nieaktualny podczas ponownej weryfikacji
Nieaktualny podczas ponownej walidacji to typ hybrydowy. Podczas jego używania skrypt service worker natychmiast sprawdza, czy znajduje się w pamięci podręcznej odpowiedź z pamięci podręcznej, a jeśli ją znajdzie, przekazuje ją z powrotem do aplikacji internetowej.
W międzyczasie, niezależnie od tego, czy wystąpiła zgodność z pamięcią podręczną, skrypt service worker uruchamia też żądanie sieciowe, aby uzyskać „świeżą” odpowiedź. Ta odpowiedź służy do aktualizacji odpowiedzi zapisanej w pamięci podręcznej. Jeśli wstępne sprawdzanie pamięci podręcznej się nie udało, kopia odpowiedzi sieciowej jest również przekazywana z powrotem do aplikacji internetowej.
Dlaczego warto korzystać z Workbox?
Takie strategie buforowania odpowiadają przepisom, które normalnie trzeba będzie przepisywać we własnym mechanizmie Service Worker. Zamiast odwoływać się do nich, Workbox oferuje je w pakiecie jako część biblioteki strategii, dzięki czemu można łatwo użyć skryptu service worker.
Workbox zapewnia też obsługę wersji, co pozwala automatycznie wygasać wpisy w pamięci podręcznej lub powiadamiać aplikację internetową o aktualizacji wpisu z pamięci podręcznej.
Które z Twoich zasobów powinny być zapisywane w pamięci podręcznej i w jaki sposób?
Buforowanie środowiska wykonawczego można traktować jako uzupełnienie wstępnego buforowania. Jeśli wszystkie Twoje zasoby są już zapisywane w pamięci podręcznej, nie musisz nic robić. Nie trzeba będzie zapisywać ich w pamięci podręcznej w czasie działania. Może się jednak okazać, że w przypadku stosunkowo złożonych aplikacji internetowych nie będzie trzeba rzeczyć wszystkich.
Większe pliki multimedialne, zasoby wyświetlane z hostów zewnętrznych, np. CDN czy odpowiedzi interfejsu API, to tylko niektóre z przykładów typów zasobów, których nie można odpowiednio przygotować w pamięci podręcznej. Użyj panelu Network (Sieć) w Narzędziach deweloperskich, aby zidentyfikować żądania, które należą do tej kategorii, i zastanów się, jaki stosunek aktualności między aktualnością a niezawodnością jest odpowiedni dla każdego z nich.
Używaj braku aktualizacji podczas ponownej weryfikacji, aby priorytetowo traktować niezawodność, a nie aktualność
Strategia „nieaktualne podczas ponownej weryfikacji” zwraca odpowiedź z pamięci podręcznej niemal natychmiast – po wypełnieniu pamięci podręcznej w ramach pierwszego żądania – w efekcie zastosowanie tej strategii zapewnia stabilną wydajność. Oznacza to kompromis między uzyskaniem danych odpowiedzi, które mogą być nieaktualne w porównaniu z danymi pobranymi z sieci. Ta strategia sprawdza się najlepiej w przypadku komponentów takich jak zdjęcia profilowe użytkowników lub początkowe odpowiedzi interfejsu API używane do wypełniania widoku, gdy wiesz, że kluczowe jest wyświetlenie czegoś natychmiast, nawet jeśli jest to starsza wartość.
Priorytetowe traktowanie sieci: aktualność, a nie niezawodność
W jakimś sensie strategia skoncentrowana na sieci oznacza przyjęcie porażki w walce z siecią – nadajemy jej priorytet, ale wiąże się to z niepewnością co do niezawodności. W przypadku niektórych rodzajów zasobów skorzystanie z nowej odpowiedzi ułatwia uzyskanie nieaktualnych informacji. Podczas tworzenia żądania do interfejsu API tekstu artykułu, który jest często aktualizowany, możesz na przykład preferować aktualność.
Zastosowanie strategii opartej na sieci w skrypcie service worker zamiast po prostu w bezpośredni sposób na działanie sieci sprawia, że możesz korzystać z czegoś, nawet jeśli jest to potencjalnie nieaktualna odpowiedź. Nie będzie działać szybko, ale przynajmniej działać niezawodnie w trybie offline.
W przypadku adresów URL mających różne wersje najpierw z pamięci podręcznej
W strategii koncentrującej się na pamięci podręcznej wpis jest zapisywany w pamięci podręcznej i nigdy nie jest aktualizowany. Dlatego używaj go tylko w przypadku komponentów, których prawdopodobnie nie zmieni. W szczególności najlepiej sprawdza się w przypadku adresów URL, które zawierają informacje o obsłudze wersji – ten sam rodzaj adresów URL, które powinny być podawane z nagłówkiem odpowiedzi Cache-Control: max-age=31536000.