Ta dokumentacja wcześniej omówiła stosowanie zachwalania, ale nie zawiera wystarczającej ilości informacji, aby robić to prawidłowo. Jest to ważne, ponieważ niezależnie od tego, czy używasz Workbox, możesz łatwo buforować zbyt dużo danych i przepustowości. Zachowaj ostrożność w zakresie wpływu ładunku wstępnego na wygodę użytkowników.
Czytając ten dokument, pamiętaj, że są to ogólne wskazówki. Architektura i wymagania Twojej aplikacji mogą wymagać wykonania innych czynności niż sugerujemy, ale te wskazówki stanowią dobre wartości domyślne.
Zalecane działanie: buforuj najważniejsze zasoby statyczne w pamięci podręcznej
Najlepsze są zasoby statyczne o znaczeniu krytycznym, ale co z kolei uznaje się za zasoby „krytyczne”? Z punktu widzenia programisty cała aplikacja może być kusząca, ale najważniejsza jest perspektywa użytkownika. Zastanów się nad zasobami o znaczeniu krytycznym, które są niezbędne, aby zapewnić użytkownikom komfort korzystania z aplikacji:
- Globalne arkusze stylów.
- Pliki JavaScript, które zapewniają funkcjonalność globalną.
- Kod HTML powłoki aplikacji, jeśli ma zastosowanie do Twojej architektury.
Uwaga: to tylko ogólne wskazówki, a nie sztywne zalecenia. Podczas zapisywania zasobów w pamięci podręcznej najlepiej jest ograniczyć ilość pamięci podręcznej do mniejszej.
Zalecane działanie: wczytuj w pamięci podręcznej reklamę zastępczą offline w przypadku witryn wielostronicowych
W przypadku typowych witryn wielostronicowych do obsługi żądań nawigacji możesz stosować strategię buforowania dotyczącą tylko sieci lub tylko sieci.
W takich przypadkach musisz się upewnić, że skrypt service worker wstępnie zapisuje dane w pamięci podręcznej, a gdy użytkownik wysyła żądanie nawigacji w trybie offline, wyświetla stronę zastępczą offline. Jednym ze sposobów na to w Workbox może być zastosowanie strategii obejmującej tylko sieć z zastępczą opcją offline z zastosowaniem wstępnego wczytywania nawigacji:
import {PrecacheFallbackPlugin, precacheAndRoute} from 'workbox-precaching';
import {registerRoute, Route} from 'workbox-routing';
import {NetworkOnly} from 'workbox-strategies';
import * as navigationPreload from 'workbox-navigation-preload';
navigationPreload.enable();
// Ensure that /offline.html is part of your precache manifest!
precacheAndRoute(self.__WB_MANIFEST);
// The network-only callback should match navigation requests, and
// the handler for the route should use the network-only strategy, but
// fall back to a precached offline page in case the user is offline.
const networkOnlyNavigationRoute = new Route(({request}) => {
return request.mode === 'navigate';
}, new NetworkOnly({
plugins: [
new PrecacheFallbackPlugin({
fallbackURL: '/offline.html'
})
]
}));
registerRoute(networkOnlyNavigationRoute);
Dzięki temu, jeśli użytkownik przejdzie w tryb offline i wejdzie na stronę, której nie ma w pamięci podręcznej, będzie mógł pobrać pewną treść offline.
Być może: rozważ użycie spekulacyjnych precencji
To oczywista prawda, ale jest potencjalna korzyść związana z wstępnym zapisywaniem w pamięci podręcznej zasobów, które są używane tylko w określonych sytuacjach. Spójrz na to w ten sposób: użytkownicy będą z góry pobierać dodatkowe dane, a spekulacyjna korzyść będzie polegać na przyspieszeniu przesyłania żądań dotyczących tych zasobów w przyszłości.
Poważna uwaga: jeśli podejmiesz decyzję o zakupie, zachowaj bardzo ostrożność. Łatwo jest w ten sposób zmarnować dane, a decyzja ta powinna być oparta na danych. Unikaj też spekulacyjnego wstępnego buforowania zasobów, które często się zmieniają, ponieważ użytkownik poniesie dodatkowe zużycie danych za każdym razem, gdy kod wstępnego buforowania wykryje nową wersję. Obserwuj w statystykach przepływ użytkowników, aby wiedzieć, dokąd zwykle trafiają. Jeśli masz jakiekolwiek wątpliwości co do spekulatywnego blokowania zasobów, to prawdopodobnie nie warto tego robić.
Być może nie należy: buforuj statyczny kod HTML w pamięci podręcznej
Ta wskazówka dotyczy raczej witryn statycznych, w których dyskretne pliki HTML są generowane ręcznie lub generowane ręcznie przez generator witryn statycznych, a nie generowane dynamicznie lub dostarczane przez zaplecze aplikacji. Jeśli tak wygląda Twoja architektura, to prawdopodobnie najlepiej jest nie zapisywać w pamięci podręcznej wszystkich plików HTML witryny.
Problem z wstępnym zapisywaniem w pamięci podręcznej plików HTML całej witryny polega na tym, że znaczniki, które teraz zostały zapisane w pamięci podręcznej, będą zawsze udostępniane z pamięci podręcznej później, dopóki skrypt service worker nie zostanie zaktualizowany. Zwiększa to wydajność, ale może prowadzić do znacznego rezygnacji z pamięci podręcznej, jeśli często zmienia się kod HTML witryny.
Jest jednak kilka wyjątków od tej reguły. Jeśli wdrażasz małą witrynę z kilkoma statycznymi plikami HTML, dobrze jest załadować wszystkie strony do pamięci podręcznej, aby były dostępne offline. Jeśli masz wyjątkowo dużą witrynę, rozważ spekulacyjne wstępne buforowanie kilku cennych stron i zastępowanie konfiguracji offline. Możesz też skorzystać z buforowania w czasie działania, aby buforować inne strony.
Nie zapisuj elastycznych obrazów i favikon w pamięci podręcznej
To nie jest ogólna wskazówka, lecz zasada. Obrazy elastyczne to złożone rozwiązanie złożonego problemu: wielu użytkowników korzysta z różnych urządzeń, a każdy z nich różni się rozmiarem ekranu, gęstością pikseli i obsługą formatów alternatywnych. Jeśli umieścisz w pamięci podręcznej cały zestaw obrazów elastycznych, prawdopodobnie spowoduje to zapisywanie kilku obrazów w pamięci podręcznej, gdy użytkownik pobierze tylko jeden z nich.
Podobną sytuację pełni favikony – na stronach internetowych często jest używany cały zestaw favikon dla różnych scenariuszy. Najczęściej jest wysyłane tylko 1 favikona, więc zachowywanie całego zestawu favikony jest w podobny sposób niepotrzebne.
Wyświadcz użytkownikom przysługę i nie zapisuj w pamięci podręcznej zestawów obrazów i favikon. Zamiast tego polegaj na pamięci podręcznej środowiska wykonawczego. Jeśli musisz wstępnie buforować obrazy, wstaw w pamięci podręcznej często używane obrazy, które nie należą do zestawu elastycznych obrazów ani favikon. Pliki SVG są mniej ryzykowne pod względem użycia danych – pojedynczy plik SVG renderuje się optymalnie niezależnie od gęstości pikseli na danym ekranie.
Nie zapisuj wstępnie polyfill w pamięci podręcznej
Różnorodność obsługi interfejsów API w przeglądarkach to stałe wyzwanie dla programistów stron internetowych, a polyfill to jeden ze sposobów na radzenie sobie z tym wyzwaniem. Jednym ze sposobów na zminimalizowanie kosztu wydajności polyfill jest sprawdzanie funkcji i wczytywanie takich elementów tylko w przeglądarkach, które ich potrzebują.
Warunkowe wczytywanie elementów polyfill ma miejsce w czasie działania względem bieżącego środowiska, dlatego wstępne wypełnianie pamięci podręcznej to ryzyko. Niektórzy użytkownicy będą z tego korzystać, a inni będą marnować przepustowość na niepotrzebne przypadki polyfill.
Nie zapisuj wstępnie elementów polyfill w pamięci podręcznej. Używaj pamięci podręcznej środowiska wykonawczego, aby mieć pewność, że są one zapisywane tylko w przeglądarkach, które wymagają od nich marnowania danych.
Podsumowanie
Stosowanie przewidywań wymaga wcześniejszego przemyślenia z wyprzedzeniem zasobów, których faktycznie potrzebują użytkownicy, ale z pewnością wszystko będzie działało jak należy, a jednocześnie da Ci to priorytet w przyszłości i wydajności.
Jeśli nie masz pewności, czy określone zasoby powinny być wstępnie buforowane, najlepiej będzie poinstruować zespół Workbox, aby wykluczył te zasoby i utworzył ścieżkę buforowania w czasie działania w celu ich obsługi. W obu przypadkach wstępnie omówię szczegółowo te zasady w dalszej części tej dokumentacji, dzięki czemu z łatwością będzie Ci się w przyszłości umożliwić stosowanie tych zasad.