Skrypty service worker pozwalają witrynom działać w trybie offline i tworzą dla nich specjalne reguły buforowania. Moduł obsługi fetch skryptu service worker widzi każde żądanie ze strony, którą kontroluje, i może zdecydować, czy chce udostępnić na nie odpowiedź z pamięci podręcznej mechanizmu Service Worker, czy nawet zmodyfikować adres URL, aby całkowicie pobrać inną odpowiedź – na przykład na podstawie lokalnych ustawień użytkownika.
Skrypty service worker mogą jednak wiązać się z kosztami, gdy strona jest wczytywana po raz pierwszy od jakiegoś czasu, a kontrolny mechanizm Service Worker nie jest obecnie uruchomiony. Wszystkie pobrania muszą odbywać się przez skrypt service worker, dlatego przeglądarka musi poczekać na uruchomienie i uruchomienie tego skryptu, aby określić, jaka zawartość ma się wczytać. Koszt uruchamiania może być niewielki, ale znaczny dla deweloperów, którzy korzystają z mechanizmów Service Worker do poprawy wydajności dzięki strategiom buforowania.
Wstępne wczytywanie nawigacji to jeden ze sposobów rozwiązania problemu, który umożliwia wysyłanie przez sieć żądań nawigacji równolegle do uruchamiania skryptu service worker, ale jest ograniczony do wstępnych żądań nawigacji i nadal uwzględnia ten skrypt na ścieżce krytycznej. Od momentu wprowadzenia wstępnego wczytywania nawigacji podjęto wiele działań mających na celu opracowanie bardziej ogólnego rozwiązania do problematycznej przestrzeni, w tym sposobów na uniknięcie blokowania niektórych żądań podczas uruchamiania skryptu service worker.
Interfejs API routingu statycznego Service Worker
Od wersji Chrome 116 dostępny jest eksperymentalny interfejs Service Worker Static Routing API do testowania pierwszego kroku takiego rozwiązania. Po zainstalowaniu skryptu service worker może on używać interfejsu Service Worker Static Routing API do deklaratywnego określania sposobu pobierania określonych ścieżek zasobów.
W początkowej wersji interfejsu API można zadeklarować, że ścieżki mają być zawsze obsługiwane przez sieć, a nie skrypt service worker. W przypadku późniejszego wczytania kontrolowanego adresu URL przeglądarka może rozpocząć pobieranie zasobów z tych ścieżek, zanim mechanizm Service Worker zakończy działanie. Spowoduje to usunięcie skryptu service worker ze ścieżek, których wiesz, że go nie potrzebują.
Aby użyć tego interfejsu API, skrypt service worker wywołuje w zdarzeniu install polecenie event.registerRouter z zestawem reguł:
self.addEventListener('install', event => {
if (event.registerRouter) {
// Go straight to the network and bypass invoking "fetch" handlers for all
// same-origin URLs that start with '/form/'.
event.registerRouter([{
condition: {
urlPattern: {pathname: '/form/*'},
},
source: 'network',
}]);
}
});
Każda reguła ma zwykle 2 właściwości:
condition: określa, kiedy reguła ma być stosowana do dopasowywania ścieżek zasobów za pomocą interfejsu URL Pattern API. Właściwość może przyjmować instancjęURLPatternlub równoważny obiekt zwykły, który jest zgodny z przekazaniem do konstruktoraURLPattern(np.new URLPattern({pathname: '*.jpg'})lub tylko{pathname: '*.jpg'}).Dzięki elastyczności wzorców adresów URL reguła może dopasować coś tak prostego jak każdy zasób na ścieżce, do bardzo konkretnych i szczegółowych warunków. Wzorce powinny być zasadniczo znane użytkownikom popularnych bibliotek routingu.
source: określa sposób wczytywania zasobów pasujących do typucondition. Obecnie obsługiwana jest tylko wartość'network'(bez uwzględniania skryptu service worker w celu bezpośredniego wczytywania zasobu przez sieć), ale w przyszłości planujemy rozszerzyć tę wartość na inne wartości.
Przykłady zastosowań
Jak wyjaśniono, wstępna wersja interfejsu API jest w zasadzie funkcją wyjścia z kontroli mechanizmu Service Worker na niektórych ścieżkach. Właściwe użycie tego rozwiązania zależy od sposobu użycia skryptu service worker i tego, jak użytkownicy poruszają się po witrynie.
Może to być na przykład taka, że Twoja witryna korzysta ze strategii opartej na pamięci podręcznej (powraca do sieci) z kilkoma treściami, które są tak rzadko odwiedzane, że ich zawartość w pamięci podręcznej nie ma już żadnej wartości (np. treści archiwalne lub kanały RSS). Ograniczenie tych ścieżek do pobierania z sieci można skonfigurować w skrypcie service worker, ale i tak musi on się uruchomić i uruchomić, aby zdecydować, jak obsłużyć te żądania.
Z kolei interfejs static Routing API całkowicie omija mechanizm Service Worker za pomocą kilku wierszy deklaratywnych:
self.addEventListener('install', event => {
if (event.registerRouter) {
event.registerRouter([{
condition: {
urlPattern: {pathname: '/feeds/*.xml'},
},
source: 'network',
}, {
condition: {
urlPattern: {pathname: '/archives/*'},
},
source: 'network',
}]);
}
});
Wraz z rozwojem interfejsu Service Worker Static Routing API planujemy tę konfigurację, aby zapewnić większą elastyczność i obsługę większej liczby scenariuszy, takich jak deklaratywnie ścisła się konfiguracja pobierania sieciowego i uruchomienie mechanizmu Service Worker. Więcej informacji znajdziesz w opisie eksploracji potencjalnej „ostatecznej postaci” interfejsu API w objaśnieniu specyfikacji.
Testowanie statycznego routingu API Service Worker
Interfejs Service Worker Static Routing API jest dostępny w Chrome w wersji 116 i nowszych niż wersja próbna origin, która pozwala programistom przetestować interfejs API w witrynie wśród rzeczywistych użytkowników, aby zmierzyć efekty. Podstawowe informacje o testach origin znajdziesz w artykule Pierwsze kroki z testami origin.
Do testów lokalnych można włączyć interfejs Service Worker Static Routing API za pomocą flagi chrome://flags/#service-worker-static-router lub uruchomić Chrome przy użyciu polecenia takiego jak --enable-features=ServiceWorkerStaticRouter.
Opinie i kolejne wskazówki
Interfejs Service Worker Static Routing API jest w trakcie opracowywania i wciąż nad nim pracujemy. Jeśli uważasz, że rozwiązanie może być przydatne, wypróbuj je w ramach testu origin i prześlij opinię na temat interfejsu API, implementacji i dostępnych funkcji.