Buforowanie skryptu service worker i buforowanie HTTP

Zalety i wady stosowania spójnej lub różnej logiki wygasania na poziomie pamięci podręcznej service workera i pamięci podręcznej HTTP.

Jonathan Chen

Chociaż serwisy i aplikacje PWA stają się standardem w przypadku nowoczesnych aplikacji internetowych, buforowanie zasobów stało się bardziej skomplikowane niż kiedykolwiek. Z tego artykułu dowiesz się więcej o pamięci podręcznej przeglądarki, w tym:

• Przypadki użycia i różnice między buforowaniem w usłudze workera a buforowaniem w protokole HTTP.
• Zalety i wady różnych strategii dotyczących wygasania pamięci podręcznej w usługach workera w porównaniu ze zwykłymi strategiami dotyczącymi pamięci podręcznej HTTP.

Omówienie procesu buforowania

Ogólnie rzecz biorąc, gdy przeglądarka prosi o zasób, stosuje następującą kolejność:

1. Pamięć podręczna usługi: usługa sprawdza, czy zasób znajduje się w pamięci podręcznej, i decyduje, czy zwrócić sam zasób na podstawie zaprogramowanych strategii buforowania. Pamiętaj, że nie dzieje się to automatycznie. W serwisie workera musisz utworzyć moduł obsługi zdarzenia pobierania i przechwytywać żądania sieci, aby były one obsługiwane z poziomu pamięci podręcznej serwisu workera, a nie z sieci.
2. Pamięć podręczna HTTP (zwana też pamięcią podręczną przeglądarki): jeśli zasób zostanie znaleziony w pamięci podręcznej HTTP i nie wygasł jeszcze, przeglądarka automatycznie użyje zasobu z pamięci podręcznej HTTP.
3. Po stronie serwera: jeśli w pamięci podręcznej usługi lub w pamięci podręcznej HTTP nie znaleziono niczego, przeglądarka wysyła żądanie zasobu do sieci. Jeśli zasób nie jest przechowywany w pamięci podręcznej w sieci CDN, żądanie musi wrócić do serwera źródłowego.

Zapisywanie warstw w pamięci podręcznej

Buforowanie skryptu service worker

Usługa workera przechwytuje żądania HTTP typu sieciowego i korzysta z strategii buforowania, aby określić, jakie zasoby należy zwrócić do przeglądarki. Pamięć podręczna skryptu service worker i pamięć podręczna HTTP służą do tych samych ogólnych celów, ale pamięć podręczna skryptu service worker oferuje więcej funkcji buforowania, takich jak szczegółowa kontrola nad tym, co dokładnie jest buforowane i jak odbywa się buforowanie.

Sterowanie pamięcią podręczną service workera

Usługa workera przechwytuje żądania HTTP za pomocą obsługujących zdarzeń (zazwyczaj zdarzenia fetch). Ten fragment kodu pokazuje logikę strategii buforowania Cache-First.

Zdecydowanie zalecamy korzystanie z Workbox, aby uniknąć wymyślania koła na nowo. Możesz na przykład zarejestrować ścieżki adresów URL zasobów za pomocą pojedynczego wiersza kodu wyrażenia regularnego.

import {registerRoute} from 'workbox-routing';

registerRoute(new RegExp('styles/.*\\.css'), callbackHandler);

Strategie i przypadki użycia dotyczące buforowania skryptów service worker

W następującej tabeli przedstawiono typowe strategie buforowania w usługach workerów i okoliczności, w których są one przydatne.

Dodatkowe zalety buforowania w usługach workera

Oprócz precyzyjnej kontroli logiki buforowania buforowanie w ramach skryptu service worker zapewnia też:

• Więcej pamięci i miejsca na dane dla punktu początkowego: przeglądarka przydziela zasoby pamięci podręcznej HTTP na podstawie źródła. Innymi słowy, jeśli masz wiele subdomen, wszystkie korzystają z tego samego pamięci podręcznej HTTP. Nie ma gwarancji, że treści domeny źródłowej pozostaną przez długi czas w pamięci podręcznej HTTP. Użytkownik może na przykład wyczyścić pamięć podręczną, ręcznie usuwając dane z interfejsu ustawień przeglądarki lub inicjując twarde ponowne wczytanie strony. Dzięki pamięci podręcznej usługi workera jest znacznie większe prawdopodobieństwo, że treści w pamięci podręcznej pozostaną w pamięci podręcznej. Więcej informacji znajdziesz w artykule o trwałym miejscu.
• Większa elastyczność w przypadku niestabilnych sieci lub korzystania z urządzenia offline: w przypadku pamięci podręcznej HTTP masz tylko 2 możliwości: zasób jest przechowywany w pamięci podręcznej lub nie. Dzięki buforowaniu w usługach workerów możesz łatwiej łagodzić drobne „problemy” (za pomocą strategii „nieaktualne, ale z potwierdzeniem”) oraz oferować pełne działanie w trybie offline (za pomocą strategii „tylko bufor”) lub nawet coś pośredniego, np. dostosowane interfejsy użytkownika z częściami strony pochodzącymi z bufora usługi workera i z niektórych częściami wykluczonymi (za pomocą strategii „Ustaw uchwyt za pomocą obsługi wyjątków”) w odpowiednich przypadkach.

Buforowanie HTTP

Gdy przeglądarka po raz pierwszy wczytuje stronę internetową i powiązane z nią zasoby, zapisuje je w pamięci podręcznej HTTP. Pamięć podręczna HTTP jest zwykle włączana automatycznie przez przeglądarki, chyba że użytkownik w wyraźny sposób ją wyłączy.

Korzystanie z pamięci podręcznej HTTP oznacza, że serwer decyduje, kiedy i jak długo ma przechowywać zasób w pamięci podręcznej.

Kontrolowanie wygaśnięcia pamięci podręcznej HTTP za pomocą nagłówków odpowiedzi HTTP

Gdy serwer odpowiada na żądanie przeglądarki dotyczące zasobu, używa nagłówków odpowiedzi HTTP, aby poinformować przeglądarkę, jak długo powinna ona przechowywać zasób w pamięci podręcznej. Więcej informacji znajdziesz w artykule Nagłówki odpowiedzi: konfigurowanie serwera WWW.

Strategie i przypadki użycia dotyczące buforowania HTTP

Buforowanie HTTP jest znacznie prostsze niż buforowanie w ramach skryptu service worker, ponieważ dotyczy tylko logiki wygasania zasobów opartej na czasie (TTL). Aby dowiedzieć się więcej o strategiach buforowania HTTP, przeczytaj artykuły Których wartości nagłówka odpowiedzi należy używać? i Podsumowanie.

Projektowanie logiki wygasania pamięci podręcznej

W tej sekcji opisano zalety i wady stosowania spójnej logiki wygasania na poziomie pamięci podręcznej service workera i pamięci podręcznej HTTP, a także zalety i wady oddzielnej logiki wygasania na tych poziomach.

Film poniżej pokazuje, jak działa buforowanie w usługach workera i buforowanie HTTP w różnych scenariuszach:

spójna logika wygasania dla wszystkich warstw pamięci podręcznej;

Aby pokazać zalety i wady, przeanalizujemy 3 scenariusze: długoterminowy, średnioterminowy i krótkoterminowy.

Scenariusz: długoterminowe buforowanie (pamięć podręczna, powrót do sieci)

• Gdy zasób w pamięci podręcznej jest ważny (do 30 dni): usługa robocza zwraca zasób w pamięci podręcznej natychmiast, bez łączenia się z siecią.
• Gdy zasób w pamięci podręcznej wygasa (> 30 dni): usługa robocza łączy się z siecią, aby pobrać zasób. Przeglądarka nie ma kopii zasobu w pamięci podręcznej HTTP, więc pobiera go po stronie serwera.

Wady: w tym scenariuszu buforowanie HTTP ma mniejsze znaczenie, ponieważ przeglądarka zawsze przekaże żądanie po stronie serwera, gdy wygaśnie czas ważności pamięci podręcznej w skrypcie service worker.

Scenariusz: średnioterminowe przechowywanie w pamięci podręcznej (Stale-while-revalidate)

• Gdy zasób w pamięci podręcznej jest ważny (do 1 dnia): usługa robocza zwraca zasobów z pamięci podręcznej natychmiast i wysyła żądanie do sieci, aby pobrać zasób. Przeglądarka ma kopię zasobu w pamięci podręcznej HTTP, więc zwraca tę kopię do usługi.
• Gdy zasób w pamięci podręcznej wygasa (> 1 dzień): usługa robocza zwraca zasob z pamięci podręcznej natychmiast i pobiera go z sieci. Przeglądarka nie ma kopii zasobu w pamięci podręcznej HTTP, więc pobiera go po stronie serwera.

Wady: aby zapewnić pełną skuteczność etapu „potwierdzania”, skrypt service worker wymaga dodatkowego burzenia pamięci podręcznej, aby zastąpić pamięć podręczną HTTP.

Scenariusz: krótkoterminowe buforowanie (przejście do buforowania w sieci)

• Gdy zasób w pamięci podręcznej jest ważny (do 10 minut): usługa robocza łączy się z siecią, aby pobrać zasób. Przeglądarka ma kopię zasobu w pamięci podręcznej HTTP, więc zwraca ją skryptowi service worker bez korzystania z serwera.
• Gdy zasób w pamięci podręcznej wygaśnie (> 10 minut): usługa robocza zwraca zasob z pamięci podręcznej natychmiast i pobiera go z sieci. Przeglądarka nie ma kopii zasobu w pamięci podręcznej HTTP, więc pobiera go po stronie serwera.

Wady: podobnie jak w przypadku średnioterminowego buforowania, usługa workera wymaga dodatkowej logiki buforowania, aby zastąpić pamięć podręczną HTTP i pobrać najnowszy zasób po stronie serwera.

Usługa w każdym scenariuszu

W każdym scenariuszu pamięć podręczna skryptu service worker może zwracać zapisane zasoby, gdy sieć jest niestabilna. Z drugiej strony pamięć podręczna HTTP nie jest niezawodna, gdy sieć jest niestabilna lub nie działa.

Różna logika wygaszania pamięci podręcznej na poziomie pamięci podręcznej usługi i warstwy HTTP

Aby pokazać zalety i wady, ponownie przyjrzymy się scenariuszom długo-, średnio- i krótkoterminowym.

Scenariusz: długoterminowe buforowanie (pamięć podręczna, powrót do sieci)

• Gdy zasób w pamięci podręcznej jest prawidłowy w pamięci podręcznej usługi (do 90 dni): usługa worker zwraca zasobów z pamięci podręcznej natychmiast.
• Gdy zasób w pamięci podręcznej w pliku service workera wygaśnie (po ponad 90 dniach): usługa workera łączy się z siecią, aby pobrać zasób. Przeglądarka nie ma kopii zasobu w pamięci podręcznej HTTP, więc przesyłanie odbywa się po stronie serwera.

Zalety i wady:

• Zalety: użytkownicy otrzymują natychmiastową odpowiedź, ponieważ usługa workera zwraca zasobów z pamięci podręcznej natychmiast.
• Zalety: usługa workera ma większą kontrolę nad tym, kiedy używać pamięci podręcznej, a kiedy żądać nowych wersji zasobów.
• Wady: wymagana jest dobrze zdefiniowana strategia buforowania usługi.

Scenariusz: średnioterminowe przechowywanie w pamięci podręcznej (stale weryfikowane)

• Gdy zasób w pamięci podręcznej jest prawidłowy w pamięci podręcznej usługi (do 30 dni): usługa worker zwraca zasobów z pamięci podręcznej natychmiast.
• Gdy zasób w pamięci podręcznej w usługach workera wygaśnie (ponad 30 dni): usługa workera przechodzi do sieci w celu pobrania zasobu. Przeglądarka nie ma kopii zasobu w pamięci podręcznej HTTP, więc żądanie jest wysyłane po stronie serwera.

Zalety i wady:

• Zalety: użytkownicy otrzymują natychmiastową odpowiedź, ponieważ usługa workera zwraca zasobów z pamięci podręcznej natychmiast.
• Zalety: dzięki temu, że walidacja odbywa się „w tle”, worker usług może zadbać o to, aby następne żądanie określonego adresu URL używało nowej odpowiedzi z sieci.
• Wady: wymagana jest dobrze zdefiniowana strategia buforowania usługi.

Scenariusz: krótkoterminowe buforowanie (przejście do buforowania w sieci)

• Gdy zasób w pamięci podręcznej jest prawidłowy w pamięci podręcznej usługi (do 1 dnia): usługa workera łączy się z siecią w celu uzyskania zasobu. Jeśli zasób znajduje się w pamięci podręcznej HTTP, przeglądarka zwraca go z niej. Jeśli sieć jest niedostępna, skrypt service worker zwraca zasób z pamięci podręcznej skryptu service worker.
• Gdy zasób w pamięci podręcznej w usługach pracujących w tle wygasa (po ponad 1 dniu): usługa pracująca w tle łączy się z siecią, aby pobrać zasób. Przeglądarka pobiera zasoby z sieci, ponieważ wersja w pamięci podręcznej w pamięci podręcznej HTTP wygasła.

Zalety i wady:

• Zalety: gdy sieć jest niestabilna lub niedostępna, usługa robocza natychmiast zwraca zapisane w pamięci podręcznej zasoby.
• Wady: usługa workera wymaga dodatkowego burzenia pamięci podręcznej, aby zastąpić pamięć podręczną HTTP i wykonać żądania „najpierw sieć”.

Podsumowanie

Ze względu na złożoność kombinacji scenariuszy buforowania nie można zaprojektować jednego reguły, która obejmowałaby wszystkie przypadki. Na podstawie wniosków z poprzednich sekcji podajemy kilka sugestii dotyczących tworzenia strategii dotyczących pamięci podręcznej:

• Logika buforowania w usługach workera nie musi być zgodna z logiką wygasania buforowania HTTP. Jeśli to możliwe, użyj w skrypcie service worker dłuższej logiki wygasania, aby zapewnić mu większą kontrolę.
• Buforowanie HTTP nadal odgrywa ważną rolę, ale nie jest niezawodne, gdy sieć jest niestabilna lub niedostępna.
• Sprawdź strategie buforowania dla każdego zasobu, aby upewnić się, że strategia buforowania skryptu usługi zapewnia odpowiednią wartość bez konfliktu z buforem HTTP.

Więcej informacji

• Niezawodność sieci
• Unikanie zbędnych żądań sieciowych dzięki pamięci podręcznej HTTP
• Ćwiczenie dotyczące pamięci podręcznej HTTP
• Pomiar wpływu service workerów na wydajność w rzeczywistych warunkach
• Cache-Control a Expires
• Pamięć podręczna wyjaśniona: sprawdzanie, czyszczenie i wyłączanie pamięci podręcznej