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łudze workera a buforowaniem w protokole 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 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 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 CDN, żądanie musi wrócić do serwera źródłowego.

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 usługi i pamięć podręczna HTTP służą do tych samych ogólnych celów, ale pamięć podręczna usługi 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ęcznej usługi 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.

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 skryptu 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 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 wywołując twarde przeładowanie 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 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ą 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 swojej 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 zasobu wysłane przez przeglądarkę, 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 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, 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 jest mniej przydatne, ponieważ przeglądarka zawsze przekaże żądanie po stronie serwera, gdy pamięć podręczna w skrypcie service worker wygaśnie.

Scenariusz: buforowanie na średnim dystansie (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 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 modułu service worker.
• Gdy zasób w pamięci podręcznej wygasa (> 1 dzień): usługa robocza zwraca zasób w 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 móc zastąpić pamięć podręczną HTTP, skrypt service worker wymaga dodatkowego burzenia pamięci podręcznej, aby w pełni wykorzystać etap „potwierdzania”.

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 wygasł (>10 minut): usługa robocza zwraca zasobów z pamięci podręcznej natychmiast i pobiera zasoby 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 ramach wszystkich scenariuszy

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 żądanie jest wysyłane po stronie serwera.

Zalety i wady:

• Zalety: użytkownicy mogą korzystać z natychmiastowych odpowiedzi, 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: buforowanie pośrednie (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 workera wygaśnie (ponad 30 dni): usługa workera łączy się z 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 mogą korzystać z natychmiastowych odpowiedzi, ponieważ usługa workera zwraca zasobów z pamięci podręcznej natychmiast.
• Zalety: dzięki temu, że walidacja odbywa się „w tle”, pracownik służby może zapewnić, 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 w pamięci podręcznej usługi pracownika usługi wygasa (po ponad 1 dniu): pracownik usługi łą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 zaprojektować 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

• 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