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 można przesyłać pliki z pamięci podręcznej do przeglądarki bez korzystania z sieci. Wykorzystaj wstępny bufor do najważniejszych komponentów, których Twoja witryna potrzebuje nawet offline: strony głównej, stylów, obrazu zapasowego i niezbędnych skryptów.
Dlaczego warto używać Workboxa?
Korzystanie z Workboxa do wstępnego zapisywania danych jest opcjonalne. Możesz napisać własny kod, który zapisze w pamięci podręcznej najważniejsze zasoby podczas instalowania usługi dla pracowników. Główną zaletą korzystania z platformy Workbox jest to, że daje ona bezpośrednią kontrolę nad wersjami. Z aktualizowaniem zasobów w pamięci podręcznej w pamięci podręcznej za pomocą Workbox nie będziesz mieć żadnych problemów niż w przypadku samodzielnego zarządzania wersjami i aktualizowaniem tych plików.
Pliki manifestu wstępnego zapisywania 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ć to i wykluczyć pole wersji. Pozostałe 2 zasoby nie zawierają w adresach URL żadnych informacji o wersji, więc narzędzia do kompilacji Workbox tworzą osobne pole revision, które zawiera hasz zawartości pliku lokalnego.
Udostępnianie zasobów w pamięci podręcznej
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 z wyprzedzeniem zapisane w pamięci podręcznej, i zwracać te odpowiedzi z zasobów pamięci podręcznej, 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 precache zawiera dokładną reprezentację oczekiwanego stanu pamięci podręcznej. Jeśli kombinacja adresu URL i wersji w pliku manifestu ulegnie zmianie, mechanizm Service Worker wie, że poprzedni wpis w pamięci podręcznej jest już nieważny 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 w pamięci podręcznej
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. Jeśli przy każdym przebudowywaniu witryny będziesz generować pełny plik manifestu wstępnego pamięci podręcznej, będzie on w każdej chwili „źródłem prawdy” stanu pamięci podręcznej.
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ń install i activate. 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 skrypt service worker, że trzeba wysyłać nowe żądania, aby zaktualizować wpisy znajdujące się w pamięci podręcznej ('offline.svg' i 'index.html') i nowe adresy URL ('app.ffaa4455.js'), a także usunięcia w celu wyczyszczenia nieużywanych adresów URL ('app.abcd1234.js').
Rzeczywista konfiguracja „sklepu z aplikacjami”
Kolejną zaletą wstępnego buforowania jest to, że możesz zapewnić użytkownikom wrażenia, które 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 Twojej aplikacji internetowej, bez konieczności czekania, aż użytkownik otworzy każdy z nich osobno.
Gdy użytkownik instaluje aplikację, oczekuje, że szybko wyświetli się każda jej część, a nie tylko filmy, które wcześniej oglądał. Te same funkcje są dostępne 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 przechowywania danych w czasie działania aplikacji, aby mieć pewność, że zasoby będą buforowane w miarę postępów w pamięci podręcznej.
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 Workbox ułatwiają przekazywanie informacji o liczbie elementów w pliku manifestu wstępnego oraz o całkowitym rozmiarze ładunku pamięci podręcznej.
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 z czasem.