Buforowanie środowiska wykonawczego oznacza stopniowe dodawanie odpowiedzi do pamięci podręcznej „na bieżąco”. Chociaż pamięć podręczna środowiska wykonawczego nie pomaga w zapewnieniu niezawodności bieżącego żądania, może zwiększyć niezawodność kolejnych żądań dotyczących tego samego adresu URL.
Przykładem tego typu pamięci jest pamięć podręczna HTTP przeglądarki. jest tylko wypełniony po przesłaniu żądania dotyczącego danego adresu URL. Skrypty service worker pozwalają buforowanie środowiska wykonawczego wykracza poza możliwości oferowane przez samą pamięć podręczną HTTP.
Podejmowanie strategicznych działań
W przeciwieństwie do wstępnego zapisywania w pamięci podręcznej (która zawsze próbuje do udostępniania zestawu wstępnie zdefiniowanych plików z pamięci podręcznej), buforowanie środowiska wykonawczego może łączyć dostępu przez sieć i pamięć podręczną na wiele sposobów. Każda kombinacja jest ogólnie nazywa się strategią buforowania. Najważniejsze strategie buforowania obejmują:
- Koncentracja na sieci
- Pierwsza pamięć podręczna
- Nieaktualne – w trakcie ponownej weryfikacji
Koncentracja na sieci
W tym podejściu skrypt service worker najpierw próbuje pobrać odpowiedź z w sieci. Jeśli żądanie sieciowe zostanie zrealizowane, to świetnie. Odpowiedź jest zwracana do aplikacji internetowej, a kopia odpowiedzi jest przechowywana w pamięci podręcznej interfejsu API – utworzenie nowego wpisu lub zaktualizowanie poprzedniego wpisu dla tego samego wpisu; Adres URL.
jeśli żądanie sieciowe nie powiedzie się albo trwa to zbyt długo zwracana jest odpowiedź z pamięci podręcznej, .
Pierwsza pamięć podręczna
Strategia skoncentrowana na pamięci podręcznej jest w praktyce przeciwieństwem strategii koncentrującej się na sieci. W tym Gdy skrypt service worker przechwytuje żądanie, najpierw używa pamięci podręcznej Storage API, aby sprawdzić, czy dostępna jest odpowiedź z pamięci podręcznej. Jeśli tak, ta odpowiedź jest zwracana do aplikacji internetowej.
Jeśli jednak brakuje pamięci podręcznej, skrypt service worker przejdzie do sieci i spróbuj pobrać odpowiedź. Zakładając, że żądanie sieciowe jest jest zwracany do aplikacji internetowej, a jego kopia jest zapisywana w pamięci podręcznej. Ten zostanie użyta do ominięcia sieci przy następnym wysyłaniu żądania te same adresy URL.
Nieaktualne – w trakcie ponownej weryfikacji
Funkcja „nieaktualne w trakcie ponownej weryfikacji” jest czymś w rodzaju hybrydowego. Gdy z niej korzystasz, instancja robocza natychmiast sprawdzi, czy odpowiedź znajduje się w pamięci podręcznej i jeśli ją znajdzie, z powrotem do aplikacji internetowej.
Tymczasem, niezależnie od tego, czy znaleziono dopasowanie pamięci podręcznej, inicjator uruchamia też żądanie sieciowe, by odzyskać „świeże” . Ten jest używana do aktualizacji dowolnej odpowiedzi wcześniej przechowywanej w pamięci podręcznej. Jeśli początkowa pamięć podręczna nie udało się sprawdzić, kopia odpowiedzi sieci jest przesyłana z powrotem do Twojej sieci aplikacji.
Dlaczego warto używać Workbox?
Te strategie buforowania obejmują przepisy, które normalnie w dowolnym mechanizmie Service Worker. Zamiast uciekać się do jako część pakietu narzędzi, bibliotekę strategii, możesz przejść do skryptu service worker.
Workbox zapewnia też obsługę wersji, dzięki czemu możesz automatycznie expire, wpisy w pamięci podręcznej lub powiadamiać aplikację internetową, aktualizacje wcześniej w pamięci podręcznej.
Które strategie powinny być przechowywane w pamięci podręcznej?
Buforowanie środowiska wykonawczego można traktować jako uzupełnienie wstępnego buforowania. Jeśli wszystkie zasoby są już wstępnie buforowane, to wszystko – nie trzeba nic do buforowania w czasie działania. Bardzo możliwe, że w przypadku stosunkowo złożonych aplikacji internetowych nie będziemy jednak wstępnie zapisywać wszystko.
większe pliki multimedialne, zasoby udostępniane z hosta zewnętrznego, np. sieci CDN, lub odpowiedzi interfejsu API, to tylko kilka przykładów typów zasobów, których nie można skutecznie wstępnie buforowane. Używanie panelu Sieć w Narzędziach deweloperskich do identyfikowania żądań które należą do tej kategorii, i w przypadku każdej z nich zastanów się, jaki kompromis aktualność lub wiarygodność jest odpowiednia.
Użyj funkcji „Nieaktualne, gdy trwa ponowne weryfikowanie”, aby nadać priorytet niezawodności zamiast aktualności
Strategia „nieaktualny w trakcie ponownej weryfikacji” zwraca odpowiedź z pamięci podręcznej niemal natychmiast – gdy pamięć podręczna zostanie zapełniona przez pierwsze żądanie – odnotowując przy zastosowaniu tej strategii odpowiednią skuteczność. Efekt w porównaniu z danymi odpowiedzi, które mogłyby być nieaktualne w porównaniu z jakie dane zostałyby pobrane z sieci. Ta strategia sprawdza się najlepiej takich jak obrazy profilowe użytkowników czy początkowe odpowiedzi interfejsu API używane do wypełniają widok, gdy wiesz, że wyświetlenie czegoś natychmiast jest kluczowe, nawet jeśli jest to starsza wartość.
Używaj konfiguracji koncentrującej się na sieci, aby traktować priorytetowo aktualność, a nie niezawodność
W pewnym sensie strategia skoncentrowana na sieci oznacza przyjęcie porażki w walce w porównaniu z siecią – ma on priorytet, ale to wiąże się z niepewnością na temat niezawodności. W przypadku niektórych typów komponentów nowa odpowiedź jest to dobry sposób na odzyskanie nieaktualnych informacji. Wolisz aktualność, gdy wysyłanie do interfejsu API żądań często aktualizowanych tekstów artykułów, na przykład instancji.
Przez zastosowanie strategii skoncentrowanej na sieci wewnątrz skryptu service worker, a nie tylko bezpośrednio, możesz też spaść do czegoś, nawet jeśli jest to potencjalnie nieaktualna odpowiedź. Nie będziesz niezawodnie, ale też offline.
Używaj najpierw pamięci podręcznej w przypadku adresów URL z wersją
W strategii skoncentrowanej na pamięci podręcznej wpis zapisany w pamięci podręcznej nigdy nie jest aktualizowany. Do tego celu
dlatego używaj jej tylko w przypadku zasobów, o których wiesz, że raczej nie będą
. Najlepiej sprawdza się w przypadku adresów URL zawierających wersje
– ten sam adres URL, który powinny być też przesyłane z tagiem
Nagłówek odpowiedzi Cache-Control: max-age=31536000.