Buforowanie skryptu service worker i buforowanie HTTP

Zalety i wady stosowania spójnej lub różnej logiki wygasania w warstwach pamięci podręcznej Service Worker i pamięci podręcznej HTTP.

Jonathan Chen

Chociaż service worker i aplikacje PWA stają się standardem nowoczesnych aplikacji internetowych, buforowanie zasobów jest bardziej złożone niż kiedykolwiek. W tym artykule znajdziesz ogólne informacje o pamięci podręcznej przeglądarki, w tym:

• przypadki użycia i różnice między buforowaniem za pomocą mechanizmu Service Worker a buforowaniem HTTP;
• Porównanie zalet i wad różnych strategii wygasania pamięci podręcznej service workera ze zwykłymi strategiami buforowania HTTP.

Omówienie procesu buforowania

Ogólnie rzecz biorąc, przeglądarka postępuje zgodnie z poniższą kolejnością buforowania, gdy wysyła żądanie zasobu:

1. Pamięć podręczna service workera: service worker sprawdza, czy zasób znajduje się w jego pamięci podręcznej, i na podstawie zaprogramowanych strategii buforowania decyduje, czy zwrócić sam zasób. Pamiętaj, że nie dzieje się to automatycznie. Musisz utworzyć w usłudze Service Worker moduł obsługi zdarzeń pobierania i przechwytywać żądania sieciowe, aby były one obsługiwane z pamięci podręcznej usługi Service Worker, a nie z sieci.
2. Pamięć podręczna HTTP (znana też jako pamięć podręczna przeglądarki): jeśli zasób znajduje się w pamięci podręcznej HTTP i nie wygasł, przeglądarka automatycznie używa zasobu z pamięci podręcznej HTTP.
3. Po stronie serwera: jeśli w pamięci podręcznej service workera lub w pamięci podręcznej HTTP nic nie zostanie znalezione, przeglądarka przechodzi do sieci, aby poprosić o zasób. Jeśli zasób nie jest przechowywany w pamięci podręcznej sieci CDN, żądanie musi zostać przesłane z powrotem do serwera źródłowego.

Zapisywanie warstw w pamięci podręcznej

Zapisywanie w pamięci podręcznej skryptu service worker

Service worker przechwytuje żądania HTTP typu sieciowego i używa strategii buforowania, aby określić, jakie zasoby powinny zostać zwrócone do przeglądarki. Pamięć podręczna skryptu service worker i pamięć podręczna HTTP służą temu samemu ogólnemu celowi, ale pamięć podręczna skryptu service worker oferuje więcej możliwości buforowania, takich jak szczegółowa kontrola nad tym, co jest buforowane i jak to się odbywa.

Sterowanie pamięcią podręczną skryptu service worker

Service worker przechwytuje żądania HTTP za pomocą detektorów zdarzeń (zwykle zdarzenia fetch). Ten fragment kodu pokazuje logikę strategii buforowania Cache-First.

Zdecydowanie zalecamy używanie Workbox, aby uniknąć ponownego wymyślania koła. Możesz na przykład zarejestrować ścieżki URL zasobów za pomocą jednego wiersza kodu wyrażenia regularnego.

import {registerRoute} from 'workbox-routing';

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

Strategie buforowania skryptu service worker i przypadki użycia

W tabeli poniżej znajdziesz typowe strategie buforowania w przypadku skryptów service worker i informacje o tym, kiedy każda z nich jest przydatna.

Dodatkowe korzyści z pamięci podręcznej skryptu service worker

Oprócz precyzyjnej kontroli logiki buforowania buforowanie za pomocą skryptu service worker zapewnia też:

• Więcej pamięci i miejsca na dane w przypadku punktu początkowego: przeglądarka przydziela zasoby pamięci podręcznej HTTP na podstawie punktu początkowego. Inaczej mówiąc, jeśli masz kilka subdomen, wszystkie korzystają z tej samej pamięci podręcznej HTTP. Nie ma gwarancji, że zawartość Twojej domeny lub źródła pozostanie w pamięci podręcznej HTTP przez długi czas. Użytkownik może na przykład wyczyścić pamięć podręczną, ręcznie usuwając dane w interfejsie ustawień przeglądarki lub wymuszając ponowne wczytanie strony. W przypadku pamięci podręcznej service worker prawdopodobieństwo, że treści pozostaną w pamięci podręcznej, jest znacznie większe. Więcej informacji znajdziesz w artykule Pamięć trwała.
• Większa elastyczność w przypadku niestabilnych sieci lub korzystania z aplikacji w trybie offline: w przypadku pamięci podręcznej HTTP masz tylko 2 możliwości: zasób jest zapisany w pamięci podręcznej lub nie. Dzięki buforowaniu za pomocą service workerów możesz łatwiej radzić sobie z drobiazgami (za pomocą strategii „nieaktualne podczas ponownej weryfikacji”), oferować pełną obsługę offline (za pomocą strategii „tylko pamięć podręczna”) lub nawet coś pośredniego, np. dostosowane interfejsy z częściami strony pochodzącymi z pamięci podręcznej service workerów i niektórymi częściami wykluczonymi (za pomocą strategii „ustawienie procedury obsługi catch”) 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 została wyraźnie wyłączona przez użytkownika.

Korzystanie z pamięci podręcznej HTTP oznacza, że serwer decyduje, kiedy i na 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 ma przechowywać zasób w pamięci podręcznej. Więcej informacji znajdziesz w artykule Nagłówki odpowiedzi: konfigurowanie serwera WWW.

Strategie przechowywania w pamięci podręcznej HTTP i przypadki użycia

Pamięć podręczna HTTP jest znacznie prostsza niż pamięć podręczna skryptu service worker, ponieważ zajmuje się tylko logiką wygasania zasobów na podstawie czasu (TTL). Więcej informacji o strategiach buforowania HTTP znajdziesz w sekcjach Jakich wartości nagłówków odpowiedzi należy używać? i Podsumowanie.

Projektowanie logiki wygasania pamięci podręcznej

W tej sekcji wyjaśniamy zalety i wady stosowania spójnej logiki wygasania w przypadku warstw pamięci podręcznej Service Worker i pamięci podręcznej HTTP, a także zalety i wady stosowania osobnej logiki wygasania w przypadku tych warstw.

Spójna logika wygasania wszystkich warstw pamięci podręcznej

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

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

• Gdy zasób w pamięci podręcznej jest ważny (≤ 30 dni): service worker od razu zwraca zasób z pamięci podręcznej bez łączenia się z siecią.
• Gdy zasób w pamięci podręcznej wygaśnie (po upływie 30 dni): service worker wysyła do sieci żądanie pobrania zasobu. Przeglądarka nie ma kopii zasobu w pamięci podręcznej HTTP, więc pobiera go z serwera.

Wada: w tym scenariuszu buforowanie HTTP ma mniejszą wartość, ponieważ po wygaśnięciu pamięci podręcznej w skrypcie service worker przeglądarka zawsze przekazuje żądanie na serwer.

Scenariusz: zapisywanie w pamięci podręcznej w średnim okresie (Stale-while-revalidate)

• Gdy zasób w pamięci podręcznej jest ważny (≤ 1 dzień): service worker natychmiast zwraca zasób z pamięci podręcznej i przechodzi do sieci, aby pobrać zasób. Przeglądarka ma kopię zasobu w pamięci podręcznej HTTP, więc zwraca ją do modułu service worker.
• Gdy zasób w pamięci podręcznej wygaśnie (po upływie ponad 1 dnia): usługa Service Worker natychmiast zwraca zasób z pamięci podręcznej i pobiera go z sieci. Przeglądarka nie ma kopii zasobu w pamięci podręcznej HTTP, więc pobiera go z serwera.

Wada: skrypt service worker wymaga dodatkowego unieważniania pamięci podręcznej, aby zastąpić pamięć podręczną HTTP i w pełni wykorzystać krok „ponowna weryfikacja”.

Scenariusz: krótkoterminowe buforowanie (sieć wraca do pamięci podręcznej)

• Gdy zasób w pamięci podręcznej jest ważny (≤ 10 minut): service worker wysyła do sieci żądanie pobrania zasobu. Przeglądarka ma kopię zasobu w pamięci podręcznej HTTP, więc zwraca ją do skryptu service worker bez przechodzenia na stronę serwera.
• Gdy zasób w pamięci podręcznej wygaśnie (po upływie ponad 10 minut): service worker natychmiast zwraca zasób z pamięci podręcznej i pobiera go z sieci. Przeglądarka nie ma kopii zasobu w pamięci podręcznej HTTP, więc pobiera go z serwera.

Wada: podobnie jak w przypadku scenariusza buforowania średnioterminowego, usługa Service Worker wymaga dodatkowej logiki unieważniania pamięci podręcznej, aby zastąpić pamięć podręczną HTTP i pobrać najnowszy zasób z serwera.

Service worker we wszystkich scenariuszach

W każdym scenariuszu pamięć podręczna skryptu service worker może zwracać zasoby z pamięci podręcznej, 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 wygasania pamięci podręcznej w warstwach pamięci podręcznej usługi i HTTP

Aby pokazać zalety i wady, ponownie przyjrzymy się scenariuszom długoterminowym, średnioterminowym i krótkoterminowym.

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

• Gdy zasób w pamięci podręcznej skryptu service worker jest ważny (<= 90 dni): skrypt service worker natychmiast zwraca zasób z pamięci podręcznej.
• Gdy zasób w pamięci podręcznej service workera wygaśnie (po ponad 90 dniach), service worker pobiera go z sieci. Przeglądarka nie ma kopii zasobu w pamięci podręcznej HTTP, więc wysyła żądanie do serwera.

Zalety i wady:

• Zalety: użytkownicy otrzymują natychmiastową odpowiedź, ponieważ service worker od razu zwraca zasoby z pamięci podręcznej.
• Zaleta: service worker ma większą kontrolę nad tym, kiedy używać pamięci podręcznej, a kiedy żądać nowych wersji zasobów.
• Wymaga dobrze zdefiniowanej strategii buforowania w przypadku skryptu service worker.

Scenariusz: zapisywanie w pamięci podręcznej w połowie okresu (Stale-while-revalidate)

• Gdy zasób w pamięci podręcznej skryptu service worker jest ważny (≤ 30 dni): skrypt service worker natychmiast zwraca zasób z pamięci podręcznej.
• Gdy zasób w pamięci podręcznej service workera wygaśnie (po upływie ponad 30 dni): service worker wysyła żądanie zasobu do sieci. Przeglądarka nie ma kopii zasobu w pamięci podręcznej HTTP, więc wysyła żądanie do serwera.

Zalety i wady:

• Zalety: użytkownicy otrzymują natychmiastową odpowiedź, ponieważ service worker od razu zwraca zasoby z pamięci podręcznej.
• Zaleta: service worker może zapewnić, że kolejne żądanie dotyczące danego adresu URL będzie korzystać ze świeżej odpowiedzi z sieci dzięki ponownej weryfikacji, która odbywa się „w tle”.
• Wada: wymagana jest dobrze zdefiniowana strategia buforowania w usłudze Service Worker.

Scenariusz: krótkoterminowe buforowanie (sieć wraca do pamięci podręcznej)

• Gdy zasób w pamięci podręcznej service workera jest ważny (≤ 1 dzień): service worker wysyła żądanie zasobu do sieci. Jeśli zasób znajduje się w pamięci podręcznej HTTP, przeglądarka zwraca go z tej pamięci. Jeśli sieć nie działa, service worker zwraca zasób z pamięci podręcznej service worker.
• Gdy zasób w pamięci podręcznej service workera wygaśnie (po upływie ponad 1 dnia): service worker pobiera zasób z sieci. Przeglądarka pobiera zasoby z sieci, ponieważ wersja w pamięci podręcznej HTTP wygasła.

Zalety i wady:

• Zaleta: gdy sieć jest niestabilna lub niedostępna, service worker natychmiast zwraca zasoby z pamięci podręcznej.
• Wada: usługa Service Worker wymaga dodatkowego unieważniania pamięci podręcznej, aby zastąpić pamięć podręczną HTTP i wysyłać żądania „Najpierw sieć”.

Podsumowanie

Ze względu na złożoność kombinacji scenariuszy buforowania nie można zaprojektować jednej reguły, która obejmowałaby wszystkie przypadki. Na podstawie wniosków z poprzednich sekcji możesz jednak wziąć pod uwagę kilka sugestii podczas projektowania strategii pamięci podręcznej:

• Logika buforowania w usłudze Service Worker nie musi być zgodna z logiką wygasania buforowania HTTP. W miarę możliwości używaj w skrypcie service worker dłuższej logiki wygasania, aby przyznać mu większą kontrolę.
• Pamięć podręczna HTTP nadal odgrywa ważną rolę, ale nie jest niezawodna, gdy sieć jest niestabilna lub niedostępna.
• Sprawdź ponownie strategie buforowania poszczególnych zasobów, aby upewnić się, że strategia buforowania skryptu service worker zapewnia korzyści bez powodowania konfliktów z pamięcią podręczną HTTP.

Więcej informacji

• Niezawodność sieci
• Unikanie zbędnych żądań sieciowych dzięki pamięci podręcznej HTTP
• Ćwiczenia w Codelabs dotyczące pamięci podręcznej HTTP
• Pomiar rzeczywistego wpływu service workerów na wydajność
• Cache-Control a Expires
• Wyjaśnienie działania pamięci podręcznej: sprawdzanie, czyszczenie i wyłączanie pamięci podręcznych