W tej dokumentacji omawialiśmy już wstępne zapisywanie w pamięci podręcznej, jednak nie wystarczą nam informacje o prawidłowym stosowaniu tej funkcji. To ważne, ponieważ niezależnie od tego, czy korzystasz z Workbox, możesz łatwo wstępnie zapisać zbyt wiele danych w pamięci podręcznej i potencjalnie zużyć dane i przepustowość. Zachowaj ostrożność, jeśli chodzi o wpływ ładunku wstępnego buforowania na wrażenia użytkownika.
Czytając ten dokument, pamiętaj, że są to ogólne wskazówki. Architektura Twojej aplikacji i jej wymagania mogą wymagać podjęcia pewnych działań innych niż sugerowane w tym artykule, ale te wytyczne są dobrym rozwiązaniem domyślnym.
Zalecane: wstępne buforowanie krytycznych zasobów statycznych
Najlepszymi kandydatami do wstępnego buforowania są zasoby statyczne, które jednak uznaje się za „krytyczne”. ? Z punktu widzenia dewelopera może się wydawać kuszące, że cała aplikacja jest „krytyczna”, ale najważniejsze jest to z perspektywy użytkownika. Kluczowe zasoby to te, które są niezbędne, aby zapewnić wygodę użytkownikom:
- Globalne arkusze stylów.
- Pliki JavaScript zapewniające funkcje globalne.
- kod HTML powłoki aplikacji, jeśli ma to zastosowanie w Twojej architekturze.
Pamiętaj: to są ogólne wskazówki, a nie sztywne zalecenia. Podczas wstępnego buforowania zasobów lepiej jest zaryzykować, a nie robić znacznie mniej.
Zalecane działanie: wstępne buforowanie kreacji zastępczej offline w przypadku witryn wielostronicowych
W przypadku typowych witryn wielostronicowych do obsługi żądań nawigacji możesz polegać na strategii buforowania na pierwszym miejscu sieci lub tylko sieci.
W takich przypadkach warto zadbać o to, by mechanizm Service Worker wstępował w pamięci podręcznej i odpowiadał stronie zastępczej offline, gdy użytkownik wysyła żądanie nawigacji w trybie offline. Aby to zrobić w Workbox, możesz na przykład użyć strategii obejmującej tylko sieć z kreacją zastępczą offline, wykorzystując w tym celu wstępne wczytywanie 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 przejdzie na stronę, której nie ma w pamięci podręcznej, zobaczy przynajmniej część treści offline.
Być może: rozważ spekulacyjne wstępne buforowanie
To może być bardzo fajne w pamięci podręcznej, ale są one potencjalne i są używane tylko w określonych sytuacjach. Myśl o tym w ten sposób: użytkownicy na początku narażą się na dodatkowe pobieranie danych, co może przynieść spekulacyjne korzyści w postaci przyspieszenia realizacji żądań dotyczących tych zasobów w przyszłości.
A teraz jedno z wielkich zastrzeżeń: zachowaj bardzo ostrożność przy podejmowaniu decyzji. Łatwo jest marnować dane w taki sposób, a decyzja powinna zostać podjęta na podstawie danych. Unikaj też spekulacyjnego wstępnego buforowania zasobów, które często się zmieniają, ponieważ użytkownik będzie pobierać dodatkowe dane za każdym razem, gdy kod wstępnego buforowania wykryje nową wersję. Obserwuj przepływy użytkowników w statystykach, aby wiedzieć, dokąd najczęściej idą użytkownicy. Jeśli masz wątpliwości co do spekulacyjnego wstępnego buforowania zasobów, prawdopodobnie nie warto tego robić.
Tego nie używaj: wstępnie buforuj statyczny kod HTML
Ta wskazówka odnosi się bardziej do witryn statycznych, w których dyskretne pliki HTML są generowane przez generator statyczny lub ręcznie tworzone (a nie generowane dynamicznie lub udostępniane przez aplikację). Jeśli właśnie to opisuje Twoją architekturę, najlepiej jest nie zapisywać w pamięci podręcznej wszystkich plików HTML witryny.
Jednym z problemów ze wstępnym zapisywaniem plików HTML całej witryny jest to, że znaczniki, które są teraz wstępnie wczytywane w pamięci podręcznej, są zawsze wyświetlane z pamięci podręcznej później, dopóki skrypt service worker nie zostanie zaktualizowany. Takie rozwiązanie zwiększa wydajność, ale może prowadzić do istotnego rezygnacji z pamięci podręcznej w przypadku częstych zmian kodu HTML w witrynie.
Jest jednak kilka wyjątków od tej reguły. Jeśli wdrażasz małą witrynę z kilkoma statycznymi plikami HTML, najlepiej wstępnie umieścić je w pamięci podręcznej, aby były dostępne offline. Jeśli masz wyjątkowo dużą witrynę, rozważ wstępne zapisywanie w pamięci podręcznej kilku stron o dużej wartości oraz kreacji zastępczej offline. Następnie używaj pamięci podręcznej środowiska wykonawczego, by zapisywać inne strony w pamięci podręcznej.
Nie należy umieszczać w pamięci podręcznej elastycznych obrazów ani favikon
To bardziej ogólna zasada, a mniej ogólna. Obrazy elastyczne to złożone rozwiązanie złożonego problemu. Korzysta z nich wielu użytkowników, którzy różnią się rozmiarem ekranu, gęstością pikseli i obsługą alternatywnych formatów. Jeśli wstępnie umieszczasz w pamięci podręcznej cały zestaw obrazów elastycznych, w pamięci podręcznej będzie znajdować się kilka obrazów, a użytkownik może w końcu pobrać tylko jeden z nich.
Podobną sytuację mają favikony – strony internetowe często stosują cały zestaw favikon w różnych sytuacjach. Najczęściej wysyłane jest żądanie tylko 1 favikony, przez co wstępne zapisywanie w pamięci podręcznej całego zestawu favikon jest równie marne.
Wyświadcz użytkownikom przysługę i nie zapisuj wstępnie elastycznych obrazów i favikon w pamięci podręcznej. Zdaj się na pamięć podręczną środowiska wykonawczego. Jeśli musisz wstępnie zapisywać obrazy w pamięci podręcznej, umieść w pamięci podręcznej często używane obrazy, które nie są częścią zestawu obrazów elastycznych ani favikon. Pliki SVG są mniej ryzykowne pod względem wykorzystania danych – pojedynczy obraz SVG renderuje się optymalnie niezależnie od gęstości pikseli na danym ekranie.
Nie warto: buforować elementy polyfill w pamięci podręcznej
Różnorodna obsługa interfejsów API w przeglądarkach to nieustające wyzwanie dla programistów stron internetowych, a jednym ze sposobów na spełnienie tego wymogu jest stosowanie kodu polyfill. Jednym ze sposobów na zminimalizowanie kosztów polyfill jest sprawdzanie funkcji i ładowanie takich elementów tylko w przypadku przeglądarek, które ich potrzebują.
Warunkowe wczytywanie elementów polyfill odbywa się w czasie działania w odniesieniu do bieżącego środowiska, więc wstępne wczytywanie tych elementów to ryzyko. Niektórzy użytkownicy będą z niej korzystać, a inni będą tracić przepustowość na potrzeby niepotrzebnego uzupełniania kodu polyfill.
Nie zapisuj wstępnie elementów polyfill w pamięci podręcznej. Korzystaj z pamięci podręcznej środowiska wykonawczego, aby mieć pewność, że będą one zapisywane w pamięci podręcznej tylko w przeglądarkach, które wymagają od nich unikania marnowania danych.
Podsumowanie
Wstępne zapisywanie w pamięci podręcznej wymaga wcześniejszego zastanowienia się nad tym, jakich zasobów użytkownicy faktycznie potrzebują, ale możesz to z pewnością zrobić dobrze, ponieważ kładzie nacisk na skuteczność i niezawodność w przyszłości.
Jeśli nie masz pewności, czy niektóre zasoby powinny być wstępnie zapisywane w pamięci podręcznej, najlepiej poprosić aplikację Workbox o wykluczenie tych zasobów i utworzenie trasy do buforowania środowiska wykonawczego, która będzie je obsługiwać. W obu przypadkach wstępne zapisywanie w pamięci podręcznej zostało szczegółowo omówione w dalszej części tej dokumentacji, dzięki czemu możesz zastosować te zasady w przyszłości w swojej logice wstępnego buforowania.