Określanie buforowania za pomocą skrzynki roboczej

Jedną z funkcji usług serwisowych jest możliwość zapisywania plików w pamięci podręcznej podczas instalowania usługi. Nazywa się to „wstępnym buforowaniem”. Dzięki temu pliki z pamięci podręcznej mogą być dostarczane do przeglądarki bez korzystania z sieci. Wykorzystaj wstępny bufor do zasobów, których Twoja witryna potrzebuje nawet offline: strony głównej, stylów, obrazu zapasowego i niezbędnych skryptów.

Korzystanie z Workboxa do wstępnego zapisywania danych jest opcjonalne. Możesz napisać własny kod, który przedwcześnie spowoduje załadowanie najważniejszych zasobów podczas instalowania usługi dla robota. Główną zaletą korzystania z Workboxa jest wbudowana kontrola wersji. Aktualizowanie zasobów z cachem za pomocą Workboxa jest znacznie łatwiejsze niż samodzielne zarządzanie wersjami i aktualizowanie tych plików.

Wczytywanie wstępnie plików manifestu

Wstępne buforowanie jest obsługiwane przez listę adresów URL i powiązanych informacji o wersjach dla każdego adresu URL. Razem te informacje są nazywane przewijażącym plikiem manifestu. Manifest jest „źródłem prawdy” dla stanu wszystkich elementów, które mają znajdować się w precache dla danej wersji aplikacji internetowej. Manifest precache w formacie używanym przez Workbox wygląda mniej więcej tak:

[{
  url: 'app.abcd1234.js'
}, {
  url: 'offline.svg',
  revision: '7836745f'
}, {
  url: 'index.html',
  revision: '518747aa'
}]

Po zainstalowaniu pracownika usługi w pamięci podręcznej tworzone są 3 elementy pamięci podręcznej dla każdego z wymienionych adresów URL. Pierwszy zasób ma informacje o wersji już uwzględnione w swoim adresie URL (app to rzeczywista nazwa pliku, a .abcd1234 zawiera informacje o wersji, tuż przed rozszerzeniem pliku .js). Narzędzia do kompilacji Workbox mogą wykryć te informacje i wykluczyć pole wersji. Pozostałe 2 zasoby nie zawierają w swoich adresach URL żadnych informacji o wersjach, więc narzędzia do kompilacji Workbox tworzą osobne pole revision zawierające hasz zawartości lokalnego pliku.

Wyświetlanie zasobów z cache

Dodawanie zasobów do pamięci podręcznej to tylko jeden z elementów precachingu. Gdy zasoby zostaną zapisane w pamięci podręcznej, muszą odpowiadać na wychodzące żądania. Wymaga to utworzenia w Twoim komponencie service worker listenera zdarzeń fetch, który może sprawdzać, które adresy URL zostały zarchiwizowane, i zwracać te zarchiwizowane odpowiedzi w sposób niezawodny, omijając sieć. Ponieważ skrypt service worker sprawdza odpowiedzi w pamięci podręcznej (i korzysta z nich przed siecią), nazywa się to strategią priorytetowego korzystania z pamięci podręcznej.

Skuteczne aktualizacje

Plik manifestu domyślnego zapewnia dokładne odzwierciedlenie oczekiwanego stanu pamięci podręcznej. Jeśli kombinacja adresu URL lub wersji w pliku manifestu ulegnie zmianie, usługa robocza wie, że poprzedni element w pamięci podręcznej nie jest już prawidłowy i należy go zaktualizować. Wystarczy jedno żądanie sieciowe wysłane automatycznie przez przeglądarkę w ramach sprawdzania dostępności aktualizacji skryptu service worker, aby określić, które z adresów URL w pamięci podręcznej wymagają odświeżenia.

Aktualizacje zasobów z cachem

W miarę wydawania nowych wersji aplikacji internetowej musisz aktualizować wcześniej wyprzedzająco z pamięci podręcznej zapisane adresy URL, wyprzedzająco zapisywać nowe zasoby i usuwać nieaktualne wpisy. Dopóki za każdym razem, gdy odtwarzasz witrynę, generujesz pełny plik manifestu do pamięci podręcznej, ten plik manifestu będzie „wiarygodnym źródłem” stanu pamięci podręcznej w dowolnym momencie.

Jeśli w pliku manifestu jest istniejący adres URL z nowym polem rewizji lub jeśli jakieś adresy URL zostały dodane lub usunięte z pliku manifestu, jest to sygnał dla skryptu service worker, że należy wprowadzić aktualizacje w ramach obsługi zdarzeń installactivate. Jeśli na przykład wprowadzisz w witrynie pewne zmiany i ją odbudujesz, najnowszy plik manifestu domyślnego do wcześniejszego buforowania może ulec następującym zmianom:

[{
  url: 'app.ffaa4455.js'
}, {
  url: 'offline.svg',
  revision: '7836745f'
}, {
  url: 'index.html',
  revision: '518747aa'
}]

Każda z tych zmian informuje pracownika usługi, że trzeba wysłać nowe żądania, aby zaktualizować wcześniej zapisane w pamięci podręcznej wpisy ('offline.svg''index.html'), zapisać w pamięci podręcznej nowe adresy URL ('app.ffaa4455.js'), a także usunąć adresy URL, których już nie używasz ('app.abcd1234.js').

Prawdziwe wrażenia z instalowania aplikacji ze sklepu

Kolejną zaletą wstępnego buforowania jest to, że możesz zapewnić użytkownikom wrażenia, których trudno byłoby osiągnąć bez instalacji „sklepu z aplikacjami”. Gdy użytkownik po raz pierwszy otworzy dowolną stronę w Twojej aplikacji internetowej, możesz z wyprzedzeniem przechwycić wszystkie adresy URL potrzebne do wyświetlenia dowolnych widoków aplikacji internetowej, bez konieczności czekania, aż użytkownik otworzy każdy z nich osobno.

Gdy użytkownik instaluje aplikację, oczekuje, że wszystkie jej części będą się wyświetlać szybko, a nie tylko widoki, które były używane w przeszłości. Dzięki wstępnemu pobieraniu użytkownicy mogą korzystać z tych samych funkcji w aplikacjach internetowych.

Które zasoby powinny być wstępnie buforowane?

Aby dowiedzieć się, które adresy URL warto przechowywać w buforze podręcznym, zapoznaj się z przewodnikiem po identyfikowaniu tego, co jest wczytywane. Ogólna zasada jest taka, aby przechowywać w pamięci podręcznej wszystkie elementy HTML, JavaScript i CSS, które są wczytywane wcześnie i są kluczowe dla wyświetlania podstawowej struktury danej strony.

Unikaj wstępnego buforowania multimediów lub innych komponentów, które są wczytywane później (chyba że są one kluczowe dla funkcjonalności Twojej aplikacji internetowej). Zamiast tego użyj strategii buforowania w czasie wykonania, aby mieć pewność, że te zasoby będą buforowane w miarę potrzeb.

Pamiętaj, że wstępne buforowanie wiąże się z korzystaniem z przepustowości sieci i pamięci na urządzeniu użytkownika (podobnie jak instalowanie aplikacji ze sklepu z aplikacjami). Jako deweloper musisz rozważnie korzystać z precachingu i unikać przeciążonego pliku manifestu precachingu.

Narzędzia do kompilacji w Workbox pomagają określić liczbę elementów w pliku manifestu wstępnego buforowania oraz łączny rozmiar ładunku wstępnego buforowania.

Powtarzający się użytkownicy Twojej aplikacji internetowej odnoszą długoterminowe korzyści z poprzedniego kosztu wstępnego buforowania, ponieważ możliwość uniknięcia sieci szybko się zwraca dzięki zaoszczędzeniu przepustowości.