Zalety i wady stosowania spójnej lub różnej logiki wygasania w warstwach pamięci podręcznej skryptu service worker i pamięci podręcznej HTTP
Skrypty service worker i PWA stają się standardami nowoczesnych aplikacji internetowych, ale buforowanie zasobów jest teraz bardziej złożone niż kiedykolwiek. Ten artykuł zawiera ogólne informacje o buforowaniu w przeglądarce, w tym:
- przypadki użycia i różnice między buforowaniem za pomocą skryptu service worker a buforowaniem HTTP;
- zalety i wady różnych strategii wygasania buforowania za pomocą skryptu service worker w porównaniu ze zwykłymi strategiami buforowania HTTP.
Omówienie procesu buforowania
Gdy przeglądarka wysyła żądanie zasobu, postępuje zgodnie z poniższą kolejnością buforowania:
- Pamięć podręczna skryptu service worker: skrypt 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ć moduł obsługi zdarzeń pobierania w skrypcie service worker i przechwytywać żądania sieciowe, aby były one obsługiwane z pamięci podręcznej skryptu service worker, a nie z sieci.
- 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 jeszcze nie wygasł, przeglądarka automatycznie używa zasobu z pamięci podręcznej HTTP.
- Po stronie serwera: jeśli nic nie zostanie znalezione w pamięci podręcznej skryptu service worker ani w pamięci podręcznej HTTP, przeglądarka przechodzi do sieci, aby poprosić o zasób. Jeśli zasób nie jest przechowywany w pamięci podręcznej CDN, żądanie musi wrócić do serwera pierwotnego.
Warstwy buforowania
Buforowanie za pomocą skryptu service worker
Skrypt 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.
Kontrolowanie pamięci podręcznej skryptu service worker
Skrypt 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 nie wymyślać koła na nowo. 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 za pomocą skryptu service worker i przypadki użycia
W tabeli poniżej przedstawiamy typowe strategie buforowania za pomocą skryptu service worker oraz sytuacje, w których każda z nich jest przydatna.
| Strategie | Uzasadnienie świeżości | Przypadki użycia |
|---|---|---|
| Tylko sieć | Treści muszą być zawsze aktualne. |
|
| Sieć z powrotem do pamięci podręcznej | Preferowane jest udostępnianie świeżych treści. Jeśli jednak sieć jest niedostępna lub niestabilna, można wyświetlać nieco starsze treści. |
|
| Nieaktualne, ale w trakcie ponownej weryfikacji | Można od razu wyświetlać treści z pamięci podręcznej, ale w przyszłości należy używać zaktualizowanych treści z pamięci podręcznej. |
|
| Najpierw pamięć podręczna, potem sieć | Treści nie są krytyczne i można je wyświetlać z pamięci podręcznej, aby zwiększyć wydajność, ale skrypt service worker powinien od czasu do czasu sprawdzać aktualizacje. |
|
| Tylko pamięć podręczna | Treści rzadko się zmieniają. |
|
Dodatkowe korzyści z buforowania za pomocą skryptu service worker
Oprócz szczegółowej kontroli logiki buforowania buforowanie za pomocą skryptu service worker zapewnia też:
- Więcej pamięci i miejsca na dane w przypadku Twojego źródła: przeglądarka przydziela zasoby pamięci podręcznej HTTP na podstawieźródła. Innymi słowy, jeśli masz kilka subdomen, wszystkie korzystają z tej samej pamięci podręcznej HTTP. Nie ma gwarancji, że treści z Twojego źródła lub domeny będą długo przechowywane w pamięci podręcznej HTTP. 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 załadowanie strony. W przypadku pamięci podręcznej skryptu service worker prawdopodobieństwo, że treści z pamięci podręcznej pozostaną w niej, jest znacznie większe. Więcej informacji znajdziesz w artykule o trwałym przechowywaniu danych.
- Większa elastyczność w przypadku niestabilnych sieci lub trybu offline: w przypadku pamięci podręcznej HTTP masz tylko 2 opcje: zasób jest buforowany albo nie. Dzięki buforowaniu za pomocą skryptu service worker możesz łatwiej radzić sobie z drobnymi „czkawkami” (za pomocą strategii „nieaktualne, ale w trakcie ponownej weryfikacji”), oferować pełne działanie w trybie offline (za pomocą strategii „tylko pamięć podręczna”) lub nawet coś pomiędzy, np. dostosowane interfejsy z częściami strony pochodzącymi z pamięci podręcznej skryptu service worker i niektórymi częściami wykluczonymi (za pomocą strategii „ustaw moduł obsługi przechwytywania”) w odpowiednich przypadkach.
Buforowanie HTTP
Gdy przeglądarka po raz pierwszy wczytuje stronę internetową i powiązane z nią zasoby, przechowuje je w swojej pamięci podręcznej HTTP. Pamięć podręczna HTTP jest zwykle włączana automatycznie przez przeglądarki, chyba że użytkownik ją wyłączy.
Korzystanie z buforowania HTTP oznacza poleganie na serwerze w kwestii określania, kiedy i jak długo buforować zasób.
Kontrolowanie wygasania 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 powinna buforować zasób. Więcej informacji znajdziesz w artykule o konfigurowaniu serwera WWW.
Strategie buforowania HTTP i przypadki użycia
Buforowanie HTTP jest znacznie prostsze niż buforowanie za pomocą skryptu service worker, ponieważ buforowanie HTTP dotyczy tylko logiki wygasania zasobów opartej na czasie (TTL). Więcej informacji o strategiach buforowania HTTP znajdziesz w artykułach Jakich wartości nagłówków odpowiedzi należy używać? i Zapobieganie niepotrzebnym żądaniom sieciowym dzięki pamięci podręcznej HTTP (podsumowanie).
Projektowanie logiki wygasania pamięci podręcznej
W tej sekcji wyjaśniamy zalety i wady stosowania spójnej logiki wygasania w warstwach pamięci podręcznej skryptu service worker i pamięci podręcznej HTTP, a także zalety i wady stosowania oddzielnej logiki wygasania w tych warstwach.
Spójna logika wygasania we wszystkich warstwach pamięci podręcznej
Aby pokazać zalety i wady, przyjrzymy się 3 scenariuszom: długoterminowemu, średnioterminowemu i krótkoterminowemu.
| Scenarios | Buforowanie długoterminowe | Buforowanie średnioterminowe | Buforowanie krótkoterminowe |
|---|---|---|---|
| Strategia buforowania za pomocą skryptu service worker | Pamięć podręczna z powrotem do sieci | Nieaktualne, ale w trakcie ponownej weryfikacji | Sieć z powrotem do pamięci podręcznej |
| TTL pamięci podręcznej skryptu service worker | 30 dni | 1 dzień | 10 minut |
| Maksymalny wiek pamięci podręcznej HTTP | 30 dni | 1 dzień | 10 minut |
Scenariusz: buforowanie długoterminowe (pamięć podręczna z powrotem do sieci)
- Gdy zasób z pamięci podręcznej jest ważny (<= 30 dni): skrypt service worker natychmiast zwraca zasób z pamięci podręcznej bez przechodzenia do sieci.
- Gdy zasób z pamięci podręcznej wygasł (> 30 dni): skrypt service worker przechodzi do sieci, aby pobrać zasób. Przeglądarka nie ma kopii zasobu w swojej pamięci podręcznej HTTP, więc przechodzi po stronie serwera, aby pobrać zasób.
Wada: w tym scenariuszu buforowanie HTTP ma mniejszą wartość, ponieważ gdy pamięć podręczna wygaśnie w skrypcie service worker, przeglądarka zawsze będzie przekazywać żądanie do serwera.
Scenariusz: buforowanie średnioterminowe (nieaktualne, ale w trakcie ponownej weryfikacji)
- Gdy zasób z pamięci podręcznej jest ważny (<= 1 dzień): skrypt 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 swojej pamięci podręcznej HTTP, więc zwraca ją do skryptu service worker.
- Gdy zasób z pamięci podręcznej wygasł (> 1 dzień): skrypt service worker natychmiast zwraca zasób z pamięci podręcznej i przechodzi do sieci, aby pobrać zasób. Przeglądarka nie ma kopii zasobu w swojej pamięci podręcznej HTTP, więc przechodzi po stronie serwera, aby pobrać zasób.
Wada: skrypt service worker wymaga dodatkowego czyszczenia pamięci podręcznej, aby zastąpić pamięć podręczną HTTP i w pełni wykorzystać krok „ponownej weryfikacji”.
Scenariusz: buforowanie krótkoterminowe (sieć z powrotem do pamięci podręcznej)
- Gdy zasób z pamięci podręcznej jest ważny (<= 10 minut): skrypt service worker przechodzi do sieci, aby pobrać zasób. Przeglądarka ma kopię zasobu w swojej pamięci podręcznej HTTP, więc zwraca ją do skryptu service worker bez przechodzenia po stronie serwera.
- Gdy zasób z pamięci podręcznej wygasł (> 10 minut): skrypt service worker natychmiast zwraca zasób z pamięci podręcznej i przechodzi do sieci, aby pobrać zasób. Przeglądarka nie ma kopii zasobu w swojej pamięci podręcznej HTTP, więc przechodzi po stronie serwera, aby pobrać zasób.
Wada: podobnie jak w przypadku buforowania średnioterminowego, skrypt service worker wymaga dodatkowej logiki pomijania pamięci podręcznej, aby zastąpić pamięć podręczną HTTP i pobrać najnowszy zasób po stronie serwera.
Skrypt service worker we wszystkich scenariuszach
We wszystkich scenariuszach pamięć podręczna skryptu service worker może nadal zwracać zasoby z pamięci podręcznej, gdy sieć jest niestabilna. Z drugiej strony, gdy sieć jest niestabilna lub niedostępna, pamięć podręczna HTTP nie jest niezawodna.
Różna logika wygasania pamięci podręcznej w warstwach pamięci podręcznej skryptu service worker i HTTP
Aby pokazać zalety i wady, ponownie przyjrzymy się scenariuszom długoterminowemu, średnioterminowemu i krótkoterminowemu.
| Scenarios | Buforowanie długoterminowe | Buforowanie średnioterminowe | Buforowanie krótkoterminowe |
|---|---|---|---|
| Strategia buforowania za pomocą skryptu service worker | Pamięć podręczna z powrotem do sieci | Nieaktualne, ale w trakcie ponownej weryfikacji | Sieć z powrotem do pamięci podręcznej |
| TTL pamięci podręcznej skryptu service worker | 90 dni | 30 dni | 1 dzień |
| Maksymalny wiek pamięci podręcznej HTTP | 30 dni | 1 dzień | 10 minut |
Scenariusz: buforowanie długoterminowe (pamięć podręczna z powrotem do sieci)
- Gdy zasób z pamięci podręcznej jest ważny w pamięci podręcznej skryptu service worker (<= 90 dni): skrypt service worker natychmiast zwraca zasób z pamięci podręcznej.
- Gdy zasób z pamięci podręcznej wygasł w pamięci podręcznej skryptu service worker (> 90 dni): skrypt service worker przechodzi do sieci, aby pobrać zasób. Przeglądarka nie ma kopii zasobu w swojej pamięci podręcznej HTTP, więc przechodzi po stronie serwera.
Zalety i wady:
- Zaleta: użytkownicy natychmiast otrzymują odpowiedź, ponieważ skrypt service worker natychmiast zwraca zasoby z pamięci podręcznej.
- Zaleta: skrypt service worker ma większą kontrolę nad tym, kiedy używać pamięci podręcznej, a kiedy prosić o nowe wersje zasobów.
- Wada: wymagana jest dobrze zdefiniowana strategia buforowania za pomocą skryptu service worker.
Scenariusz: buforowanie średnioterminowe (nieaktualne, ale w trakcie ponownej weryfikacji)
- Gdy zasób z pamięci podręcznej jest ważny w pamięci podręcznej skryptu service worker (<= 30 dni): skrypt service worker natychmiast zwraca zasób z pamięci podręcznej.
- Gdy zasób z pamięci podręcznej wygasł w pamięci podręcznej skryptu service worker (> 30 dni): skrypt service worker przechodzi do sieci, aby pobrać zasób. Przeglądarka nie ma kopii zasobu w swojej pamięci podręcznej HTTP, więc przechodzi po stronie serwera.
Zalety i wady:
- Zaleta: użytkownicy natychmiast otrzymują odpowiedź, ponieważ skrypt service worker natychmiast zwraca zasoby z pamięci podręcznej.
- Zaleta: skrypt service worker może zapewnić, że następne żądanie 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 za pomocą skryptu service worker.
Scenariusz: buforowanie krótkoterminowe (sieć z powrotem do pamięci podręcznej)
- Gdy zasób z pamięci podręcznej jest ważny w pamięci podręcznej skryptu service worker (<= 1 dzień): skrypt service worker przechodzi do sieci, aby pobrać zasób. Przeglądarka zwraca zasób z pamięci podręcznej HTTP, jeśli się tam znajduje. Jeśli sieć jest niedostępna, skrypt service worker zwraca zasób z pamięci podręcznej skryptu service worker.
- Gdy zasób z pamięci podręcznej wygasł w pamięci podręcznej skryptu service worker (> 1 dzień): skrypt service worker przechodzi do sieci, aby pobrać zasób. Przeglądarka pobiera zasoby z sieci, ponieważ wersja z pamięci podręcznej w jej pamięci podręcznej HTTP wygasła.
Zalety i wady:
- Zaleta: gdy sieć jest niestabilna lub niedostępna, skrypt service worker natychmiast zwraca zasoby z pamięci podręcznej.
- Wada: skrypt service worker wymaga dodatkowego czyszczenia 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 ustaleń z poprzednich sekcji mamy jednak kilka sugestii, które warto wziąć pod uwagę podczas projektowania strategii buforowania:
- Logika buforowania za pomocą skryptu service worker nie musi być zgodna z logiką wygasania buforowania HTTP. Jeśli to możliwe, używaj dłuższej logiki wygasania w skrypcie service worker, 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 za pomocą skryptu service worker zapewnia wartość bez konfliktu z pamięcią podręczną HTTP.
Więcej informacji
- Niezawodność sieci
- Zapobieganie niepotrzebnym żądaniom sieciowym dzięki pamięci podręcznej HTTP
- Warsztaty z pamięci podręcznej HTTP
- Mierzenie rzeczywistego wpływu skryptów service worker na wydajność
- Cache-Control a Expires
- Buforowanie bez tajemnic: sprawdzanie, czyszczenie i wyłączanie pamięci podręcznych