Jedną z funkcji mechanizmów Service Worker jest możliwość zapisywania plików w pamięci podręcznej podczas ich instalacji. Jest to tzw. „wstępowanie”. Takie działanie umożliwia wyświetlanie w przeglądarce plików z pamięci podręcznej bez połączenia z siecią. Używaj wstępnego buforowania w przypadku kluczowych zasobów, których Twoja witryna potrzebuje, nawet w trybie offline: strona główna, style, obraz zastępczy i niezbędne skrypty.
Dlaczego warto korzystać z Workbox?
Korzystanie z obszaru roboczego do wstępnego buforowania jest opcjonalne. Możesz napisać własny kod, który będzie wczytywać najważniejsze zasoby w pamięci podręcznej podczas instalacji skryptu service worker. Główną zaletą korzystania z Workbox jest gotowa do użycia kontrola wersji. Na pewno będziesz mieć znacznie mniej problemów przy aktualizowaniu zasobów w pamięci podręcznej w Workbox niż w przypadku samodzielnego zarządzania wersjami tych plików.
Pliki manifestu Precache
Działanie w pamięci podręcznej jest oparte na liście adresów URL i powiązanych z nimi informacjach o wersjach każdego z nich. Te informacje są zebrane razem jako plik manifestu precache. Plik manifestu to „źródło danych” stanu wszystkich treści, które mają być w pamięci podręcznej dla danej wersji aplikacji internetowej. Plik manifestu 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 dla każdego z trzech wymienionych adresów URL tworzone są 3 wpisy pamięci podręcznej. Pierwszy zasób ma w adresie URL informacje o obsłudze wersji (app to rzeczywista nazwa pliku, a .abcd1234 zawiera informacje o wersji przed rozszerzeniem pliku .js). Narzędzia do kompilacji w Workbox mogą wykryć tę informację i wykluczyć pole wersji. Dwa pozostałe zasoby nie zawierają żadnych informacji o obsłudze wersji w adresach URL, więc narzędzia do kompilacji w Workbox tworzą osobne pole revision z identyfikatorem 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 historii 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 sprawdza, które adresy URL zostały zapisane w pamięci podręcznej, i niezawodnie zwraca odpowiedzi z pamięci podręcznej, omijając w tym czasie sieć. Skrypt service worker sprawdza pamięć podręczną pod kątem odpowiedzi (i używa ich przed siecią), dlatego jest to tzw. strategia ukierunkowana na pamięć podręczną.
Wydajne aktualizacje
Plik manifestu precache zawiera dokładną reprezentację oczekiwanego stanu pamięci podręcznej. Jeśli w pliku manifestu zmieni się kombinacja adresu URL i wersji, skrypt service worker wie, że poprzedni wpis w pamięci podręcznej jest już nieważny i trzeba go zaktualizować. Wystarczy jedno żądanie sieciowe, które przeglądarka wysyła automatycznie w ramach sprawdzania dostępności aktualizacji w skrypcie service worker, aby określić, które wstępnie zapisane adresy URL wymagają odświeżenia.
Aktualizacje zasobów w pamięci podręcznej
W miarę publikowania nowych wersji aplikacji internetowej musisz dbać o aktualność adresów URL wstępnie zapisanych w pamięci podręcznej, usuwać nowe zasoby w pamięci podręcznej i usuwać nieaktualne wpisy. Jeśli za każdym razem, gdy odbudowujesz witrynę, generujesz pełny plik manifestu precache, będzie on w dowolnym momencie „źródłem danych” dla Twojego stanu pamięci podręcznej.
Jeśli jest adres URL z nowym polem wersji albo jakieś adresy URL zostały dodane lub usunięte 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 zmian w witrynie i jej przebudowie, w ostatnim pliku manifestu Precache
mogły wystąpić 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 należy wysłać nowe żądania aktualizacji wpisów znajdujących się w pamięci podręcznej ('offline.svg' i 'index.html') oraz buforować nowe adresy URL ('app.ffaa4455.js'), a także usunąć nieużywane adresy URL ('app.abcd1234.js').
Faktyczna instalacja aplikacji ze sklepu z aplikacjami
Kolejną zaletą wstępnego buforowania jest zapewnienie użytkownikom środowiska, które w innym przypadku byłoby trudne do osiągnięcia poza instalacją „sklepu z aplikacjami”. Gdy użytkownik po raz pierwszy odwiedza dowolną stronę w Twojej aplikacji internetowej, możesz z wyprzedzeniem zapisać w pamięci podręcznej wszystkie adresy URL potrzebne do wyświetlenia dowolnego widoku aplikacji z wyprzedzeniem bez konieczności czekania, aż użytkownik otworzy każdy z nich.
Gdy użytkownik zainstaluje aplikację, oczekuje, że jej wszystkie elementy szybko się wyświetlą, a nie tylko te, które oglądali w przeszłości. Takie samo działanie wprowadza w aplikacjach internetowych.
Które z zasobów powinny być wstępnie zapisane w pamięci podręcznej?
Zapoznaj się z przewodnikiem Sprawdzanie, co jest wczytywane, aby dowiedzieć się, które adresy URL najlepiej buforować. Ogólna zasada jest taka, że kod HTML, JavaScript lub CSS wczytywany na początku jest zapisywany w pamięci podręcznej. Ma to kluczowe znaczenie dla wyświetlania podstawowej struktury strony.
Zalecamy unikanie zapisywania multimediów lub innych zasobów wczytywanych w późniejszym czasie (chyba że jest to niezbędne do działania aplikacji internetowej). Zamiast tego użyj strategii buforowania w czasie działania, aby mieć pewność, że te zasoby będą zapisywane w pamięci podręcznej na bieżąco.
Zawsze pamiętaj, że buforowanie wiąże się z wykorzystaniem przepustowości sieci i miejsca na dane na urządzeniu użytkownika (tak jak w przypadku instalowania aplikacji ze sklepu z aplikacjami). Jako deweloper musisz rozmyśleć o przechowywaniu danych w pamięci podręcznej i unikaniu rozmaitych plików manifestu Precache.
Narzędzia do tworzenia w skrzynce roboczej zawierają informacje o liczbie elementów w pliku manifestu precache oraz o łącznym rozmiarze ładunku w pamięci podręcznej.
W dłuższej perspektywie powracający użytkownicy mogą korzystać z Twojej aplikacji internetowej bez ponoszenia z góry kosztów wynikającego z zapamiętywania danych. Umożliwia to szybkie unikanie sieci, co pozwala zwiększyć oszczędności w miarę upływu czasu.