Określanie buforowania za pomocą skrzynki roboczej

Jedną z funkcji mechanizmów Service Worker jest możliwość zapisywania plików w pamięci podręcznej, gdy instalowany jest skrypt service worker. 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 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 używać Workbox?

Używanie Workbox do wstępnego buforowania jest opcjonalne. Możesz napisać własny kod na stronie zastosuj wstępne zasoby w pamięci podręcznej 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 jeśli musisz samodzielnie zarządzać obsługą wersji i aktualizowaniem tych plików.

Pliki manifestu wstępnej pamięci podręcznej

Wstępne buforowanie działa na podstawie listy adresów URL i powiązanych informacji o wersji każdego adresu URL. Wszystkie te informacje są określane jako plik manifestu precache. Plik manifestu jest „źródłem prawdy” dla stanu wszystkiego, co miało się stać w pamięci podręcznej danej wersji aplikacji internetowej. Plik manifestu wstępnej pamięci podręcznej w 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'
}]

Gdy instalowany jest skrypt service worker, w interfejsie API są tworzone 3 wpisy pamięci podręcznej Pamięć podręczna dla każdego z 3 wymienionych adresów URL. Pierwszy zasób ma obsługę wersji informacje już zawarte w jego adresie URL (app to rzeczywista nazwa pliku, .abcd1234 zawiera informacje o wersji tuż przed rozszerzeniem pliku. .js). Narzędzia do kompilacji w Workbox mogą to wykryć i wykluczyć pole wersji. Pozostałe zasoby nie zawierają w adresach URL żadnych informacji o wersji, więc funkcja Workbox narzędzia do kompilacji tworzą osobne pole revision, które zawiera skrót wartości lokalnej do zawartości pliku.

Udostępnianie zasobów w pamięci podręcznej

Dodanie zasobów do pamięci podręcznej to tylko jeden z elementów procesu wstępnego buforowania – zasoby są przechowywane w pamięci podręcznej, muszą odpowiadać na żądania wychodzące Wymaga to detektor zdarzeń fetch w skrypcie service worker, który może sprawdzić, które adresy URL zostały wstępnie zapisane w pamięci podręcznej i zwrócono te odpowiedzi w pamięci podręcznej, omijając w danej sieci. Skrypt service worker sprawdza pamięć podręczną odpowiedzi (i wykorzystuje te sprzed sieci), jest to tzw. strategii opartej na pamięci podręcznej.

Skuteczne aktualizacje

Plik manifestu wstępnej pamięci podręcznej przedstawia dokładną reprezentację oczekiwanej pamięci podręcznej state; jeśli zmieni się kombinacja adresu URL i wersji w pliku manifestu, skrypt service worker wie, że poprzedni wpis w pamięci podręcznej jest już nieważny i trzeba go Zaktualizowano. Potrzebne jest tylko jedno żądanie sieciowe, które jest wykonywane automatycznie przez przeglądarka jako część skryptu service worker sprawdzanie dostępności aktualizacji, aby określić, które adresy URL z pamięci podręcznej należy odświeżyć.

Aktualizacje zasobów w pamięci podręcznej

Przy wdrażaniu nowych wersji aplikacji internetowej musisz pamiętać aktualne adresy URL w pamięci podręcznej, w pamięci podręcznej nowe zasoby i usuwanie nieaktualnych wpisów. Za każdym razem, gdy będziesz generować pełny plik manifestu wstępnej pamięci podręcznej przebudowujesz witrynę, plik manifestu jest „źródłem prawdy” dla stanu precache w dowolnym momencie.

Jeśli istnieje istniejący adres URL z nowym polem wersji lub jakiekolwiek adresy URL zostały dodany lub usunięty z pliku manifestu, jest to oznaka dla skryptu service worker, które wymagają aktualizacji, install oraz activate modułów obsługi zdarzeń. Przykładowo po wprowadzeniu zmian w witrynie po ponownym utworzeniu, ostatni plik manifestu Precache mógł zostać zaktualizowany w taki sposób: 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 nowe żądania muszą być wprowadzone w celu zaktualizowania wpisów wcześniej w pamięci podręcznej ('offline.svg' i 'index.html') i buforowanie nowych adresów URL ('app.ffaa4455.js'), a także usunięcia w celu wyczyszczenia adresów URL nieużywane ('app.abcd1234.js').

Prawda „sklep z aplikacjami” proces instalacji

Inną zaletą wstępnego buforowania jest to, że możesz zapewnić użytkownikom wrażenia, które w innej sytuacji byłyby trudne do zrealizowania poza „sklepem z aplikacjami” instalacji. Gdy użytkownik po raz pierwszy odwiedzi dowolną stronę w aplikacji internetowej, możesz wstępnie zapisać w pamięci podręcznej wszystkie adresy URL potrzebne do wyświetlenia dowolnego użytkowników z aplikacji internetowej z wyprzedzeniem, bez konieczności czekania, aż z konkretnego widoku.

Gdy użytkownik instaluje aplikację, oczekuje, że każda część aplikacji wyświetli się szybko, a nie tylko na widokach z przeszłości. Te same funkcje są dostępne dzięki wstępnemu buforowaniu. z aplikacjami internetowymi.

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

Patrz: Identyfikowanie wczytanego przewodnika. i dowiedz się, które adresy URL najlepiej użyć w pamięci podręcznej. Ogólna zasada jest taka, wstępnie buforować kod HTML, JavaScript i CSS załadowany na wczesnym etapie i ma kluczowe pokazującą podstawową strukturę danej 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 środowiska wykonawczego buforowanie, aby zapewnić są zapisywane w pamięci podręcznej na bieżąco.

Zawsze pamiętaj, że wstępne wczytywanie wymaga użycia przepustowości sieci i pamięci masowej na urządzeniu użytkownika (tak samo jak w przypadku instalowania aplikacji ze sklepu z aplikacjami). To Ty jako deweloper ma obowiązek ostrożnie korzystać z buforowania w pamięci podręcznej i uniknąć nadmiernego .

Narzędzia do tworzenia kompilacji Workbox pomagają uzyskać informacje o liczbie elementów w pamięci podręcznej pliku manifestu oraz całkowitego rozmiaru ładunku Precache.

Regularni użytkownicy Twojej aplikacji internetowej odnoszą w dłuższej perspektywie koszty, wstępnego zapisywania w pamięci podręcznej, ponieważ możliwość unikania sieci w zaoszczędzonej przepustowości w czasie.