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 poziomu 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ługach workera a buforowaniem HTTP.
  • Zalety i wady różnych strategii dotyczących wygasania pamięci podręcznej usługi w porównaniu ze standardowymi 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.

Proces zapisywania w pamięci podręcznej

Buforowanie warstw

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 robocza przechwytuje żądania HTTP za pomocą obsługujących zdarzeń (zazwyczaj zdarzenia fetch). Ten fragment kodu pokazuje logikę strategii buforowania Cache-First.

Diagram pokazujący, jak skrypty service worker przechwytują żądania HTTP

Zdecydowanie zalecamy używanie 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.

Strategie Uzasadnienie dotyczące aktualności Przypadki użycia
Tylko sieć Treści muszą być zawsze aktualne.
  • Płatności i płatności
  • Wyciągi z salda
Sieć używająca pamięci podręcznej Lepiej jest wyświetlać aktualne treści. Jeśli jednak sieć nie działa lub jest niestabilna, możesz wyświetlać nieco starsze treści.
  • Dane aktualne
  • ceny i stawki (wymagają wyłączenia odpowiedzialności);
  • Stany zamówień
Stale-while-revalidate Możesz od razu wyświetlać treści z pamięci podręcznej, ale w przyszłości używaj zaktualizowanych treści z pamięci podręcznej.
  • kanały wiadomości,
  • strony z informacjami o produktach,
  • Wiadomości
Najpierw pamięć podręczna, potem sieć Treści nie są krytyczne i mogą być dostarczane z poziomu pamięci podręcznej, aby zwiększyć wydajność, ale pracownik obsługi powinien od czasu do czasu sprawdzać dostępność aktualizacji.
  • Powłoki aplikacji
  • Zasoby wspólne
Tylko pamięć podręczna Treści rzadko się zmieniają.
  • Zawartość statyczna

Dodatkowe zalety buforowania w usługach workerów

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 załadowanie strony. Dzięki pamięci podręcznej dla serwisu workera masz 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 na dane.
  • 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ą uchwytu”).

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 daty 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ż zajmuje się tylko logiką wygasania zasobów opartą 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 oraz zalety i wady stosowania oddzielnej logiki wygasania na tych poziomach.

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

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

Aby pokazać zalety i wady, przyjrzymy się 3 scenariuszom: długookresowemu, średnioterminowemu i krótkoterminowemu.

Scenariusze Buforowanie długoterminowe Buforowanie na średnim dystansie Pamięć podręczna krótkoterminowa
Strategia dotycząca pamięci podręcznej skryptu service worker Pamięć podręczna, powrót do sieci Nieaktualny podczas ponownego sprawdzania ważności Sieć przechodzi na pamięć podręczną
Czas życia danych w pamięci podręcznej skryptu service worker 30 dni 1 dzień 10 minut
Czas ważności pamięci podręcznej HTTP 30 dni 1 dzień 10 minut

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 (ponad 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 mniejszą wartość, ponieważ przeglądarka zawsze przekaże żądanie po stronie serwera, gdy pamięć podręczna w skrypcie service worker wygaśnie.

Scenariusz: średnioterminowe przechowywanie w pamięci podręcznej (sprawdzanie poprawności po upływie określonego czasu)

  • Gdy zasób w pamięci podręcznej jest ważny (do 1 dnia): usługa robocza zwraca zasob z pamięci podręcznej natychmiast 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 wygasł (> 1 dzień): usługa robocza zwraca zasobów z pamięci podręcznej natychmiast i pobiera zasób z sieci. Przeglądarka nie ma kopii zasobu w pamięci podręcznej HTTP, więc pobiera go po stronie serwera.

Wady: aby zapewnić optymalne działanie etapu „potwierdzania”, skrypt service worker wymaga dodatkowego usuwania danych z pamięci podręcznej, aby zastąpić pamięć podręczną HTTP.

Scenariusz: krótkoterminowe buforowanie (przejście do pamięci podręcznej)

  • Gdy zasób w pamięci podręcznej jest prawidłowy (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 zasób 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ć bufor HTTP i pobrać najnowszy zasób po stronie serwera.

Usługa w każdym scenariuszu

W każdym scenariuszu pamięć podręczna service workera 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.

Inna 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.

Scenariusze Buforowanie długoterminowe Buforowanie na średnim dystansie Pamięć podręczna krótkoterminowa
Strategia dotycząca pamięci podręcznej skryptu service worker Pamięć podręczna, powrót do sieci Nieaktualny podczas ponownego sprawdzania ważności Sieć przechodzi na pamięć podręczną
Czas życia danych w pamięci podręcznej skryptu service worker 90 dni 30 dni 1 dzień
Czas ważności pamięci podręcznej HTTP 30 dni 1 dzień 10 minut

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 usługi (>90 dni) wygaśnie: 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 workerowa 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: pośrednie przechowywanie w pamięci podręcznej (sprawdzanie poprawności po upływie określonego czasu)

  • 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 pracujących w tle wygaśnie (po ponad 30 dniach): usługa pracująca w tle łączy się z siecią, aby pobrać zasób. 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 workera wygasa (>1 dzień): usługa workera łą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: aby zastąpić pamięć podręczną HTTP i wykonać żądania „najpierw sieć”, skrypt service worker wymaga dodatkowego burzenia pamięci podręcznej.

Podsumowanie

Ze względu na złożoność kombinacji scenariuszy buforowania nie można opracować jednego reguły, która obejmowałaby wszystkie przypadki. Na podstawie wniosków z poprzednich sekcji podajemy kilka sugestii dotyczących projektowania 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