Jedną z funkcji mechanizmów Service Worker jest możliwość zapisywania plików w pamięci podręcznej podczas jej instalowania. Jest to nazywane „wstępnym zapisywaniem w pamięci podręcznej”. Umożliwia ono wyświetlanie w przeglądarce plików z pamięci podręcznej bez konieczności łączenia się z siecią. Użyj wstępnego buforowania w przypadku kluczowych zasobów, których witryna potrzebuje nawet w trybie offline: strony głównej, stylów, obrazu zastępczego i najważniejszych skryptów.
Dlaczego warto używać Workbox?
Używanie Workbox do wstępnego buforowania jest opcjonalne. Możesz napisać własny kod, aby wstępnie zapisywać w pamięci podręcznej kluczowe zasoby podczas instalowania skryptu service worker. 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 środowisku Workbox natrafisz na znacznie mniej problemów niż w przypadku samodzielnego zarządzania wersjami i aktualizowaniem tych plików.
Pliki manifestu wstępnej pamięci podręcznej
Wstępne zapisywanie w pamięci podręcznej działa na podstawie listy adresów URL wraz z powiązanymi informacjami o wersji dla każdego adresu URL. Te informacje są określane jako plik manifestu precache. Plik manifestu jest „źródłem prawdy” stanu wszystkiego, który powinien znajdować się w pamięci podręcznej danej wersji aplikacji internetowej. Plik manifestu typu 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 skryptu service worker w pamięci podręcznej dla każdego z 3 wymienionych adresów URL są tworzone 3 wpisy w pamięci podręcznej. Adres URL pierwszego zasobu zawiera już informacje o wersji (app to rzeczywista nazwa pliku, a .abcd1234 zawiera informacje o wersji tuż przed rozszerzeniem pliku .js). Narzędzia do kompilacji Workbox mogą to wykryć 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 jedna z części procesu wstępnego buforowania – gdy zasoby zostaną zapisane w pamięci podręcznej, muszą odpowiadać na żądania wychodzące. Wymaga to detektora zdarzeń fetch w skrypcie service worker, który może sprawdzać, które adresy URL zostały wstępnie umieszczone w pamięci podręcznej, i niezawodnie zwracać te odpowiedzi w pamięci podręcznej z pominięciem sieci w trakcie tego procesu. Skrypt service worker sprawdza, czy w pamięci podręcznej są odpowiedzi (i używa ich przed siecią), dlatego jest to nazywane strategią skoncentrowaną na 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ć. Aby określić, które adresy URL zapisane w pamięci podręcznej należy odświeżyć, wystarczy jedno żądanie sieciowe, które przeglądarka wykonuje automatycznie w ramach sprawdzania dostępności aktualizacji skryptu service worker.
Aktualizacje zasobów w pamięci podręcznej
W miarę publikowania nowych wersji aplikacji internetowej musisz zadbać o aktualność adresów URL zapisanych w pamięci podręcznej, wstępnie zapisywać nowe zasoby w pamięci podręcznej 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 istnieje już adres URL z nowym polem wersji albo którykolwiek z adresów URL został dodany lub usunięty z pliku manifestu, jest to sygnał dla skryptu service worker, że należy wykonać aktualizacje w ramach modułów obsługi zdarzeń install i activate. Na przykład po wprowadzeniu i zrekompilowaniu witryny w najnowszym pliku manifestu w pamięci podręcznej ostatnio wprowadzone zostały te zmiany:
[{
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 wysł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 zapewniasz użytkownikom wrażenia, które w innym przypadku byłyby trudne do zrealizowania poza instalacją „sklepu z aplikacjami”. Gdy użytkownik po raz pierwszy odwiedzi dowolną stronę w Twojej aplikacji internetowej, możesz potencjalnie wstępnie zapisać w pamięci podręcznej wszystkie adresy URL potrzebne do z wyprzedzeniem wyświetlenia dowolnego widoku aplikacji internetowej, bez konieczności czekania, aż wyświetli każdy z nich.
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 się zorientować, które adresy URL najlepiej wstępnie buforować, zajrzyj do przewodnika Sprawdzanie, co jest wczytywane. Ogólną regułą jest wstępne wczytywanie kodu HTML, JavaScript i CSS, które są wczytywane na wczesnym etapie, jest kluczowe dla wyświetlania podstawowej struktury strony.
Najlepiej unikać wstępnego buforowania multimediów i innych zasobów, które są wczytywane później (chyba że jest to niezbędne do działania 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.
Zawsze pamiętaj, że wstępne wczytywanie wiąże się z wykorzystaniem przepustowości sieci i pamięci urządzenia użytkownika (tak samo jak w przypadku instalowania aplikacji ze sklepu z aplikacjami). To Ty jako deweloper ma obowiązek ostrożnego wstępnego buforowania i unikania przedłużonego pliku manifestu.
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.
Użytkownicy, którzy wielokrotnie korzystają z Twojej aplikacji internetowej, odnoszą na dłuższą metę korzyści z wcześniejszych kosztów wstępnego buforowania, ponieważ możliwość unikania sieci szybko zwraca się z upływem czasu zaoszczędzoną przepustowość.