Mechanizmy Service Worker to zaawansowane narzędzie, które pozwala witrynom działać w trybie offline i samodzielnie tworzyć specjalne reguły buforowania. Moduł obsługi service worker fetch widzi każde żądanie ze strony, którą kontroluje, i może zdecydować, czy wyświetlić na nie odpowiedź z pamięci podręcznej skryptu service worker, czy nawet przepisać URL, by pobrać inną odpowiedź – na przykład na podstawie lokalnych preferencji użytkownika.
Skrypty service worker mogą jednak generować koszty, gdy strona zostanie wczytana po raz pierwszy od jakiegoś czasu, a kontrolujący skrypt service worker nie jest w danym momencie uruchomiony. Wszystkie pobrania muszą odbywać się za pomocą skryptu service worker, dlatego przeglądarka musi poczekać, aż mechanizm Service Worker uruchomi się i pojawi się, aby ustalić, jaka zawartość ma zostać załadowana. Taki koszt uruchamiania może być niewielki, ale wysoki dla deweloperów korzystających z mechanizmów Service Worker w celu poprawy wydajności przez stosowanie strategii buforowania.
Wstępne ładowanie nawigacji to jeden ze sposobów rozwiązania tego problemu, który umożliwia wysyłanie żądań nawigacji przez sieć równolegle do uruchamiania skryptu service worker. Jest ono jednak ograniczone do wstępnych żądań nawigacji i nadal uwzględnia skrypt service worker na ścieżce krytycznej. Od czasu wprowadzenia wstępnego wczytywania nawigacji podjęto wiele działań w celu opracowania bardziej ogólnego rozwiązania problemów, w tym sposobów na to, aby niektóre żądania nie były w ogóle blokowane podczas uruchamiania skryptu service worker.
Interfejs Service Worker Static Routing API
Od wersji Chrome 116 dostępny jest eksperymentalny interfejs Service Worker Static Routing API do testowania pierwszego kroku takiego rozwiązania. Skrypt service worker może za pomocą interfejsu Service Worker Static Routing API deklaratywnie określić sposób pobierania określonych ścieżek zasobów.
We wstępnej wersji interfejsu API można zadeklarować, że ścieżki są zawsze obsługiwane przez sieć, a nie przez skrypt service worker. Gdy kontrolowany adres URL zostanie później wczytany, przeglądarka może rozpocząć pobieranie zasobów z tych ścieżek, jeszcze zanim skrypt service worker zakończy pracę. Spowoduje to usunięcie skryptu service worker ze ścieżek, które nie są potrzebne.
Aby używać interfejsu API, skrypt service worker wywołuje po zdarzeniu install z zestawem reguł event.registerRouter:
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 zazwyczaj 2 właściwości:
condition: określa, kiedy reguła ma być stosowana do dopasowywania ścieżek zasobów przy użyciu interfejsu URL Pattern API. Właściwość może przyjmować wystąpieniaURLPatternlub równoważny zwykły obiekt zgodny z przekazaną do konstruktoraURLPattern(na przykładnew URLPattern({pathname: '*.jpg'})lub po prostu{pathname: '*.jpg'}).Elastyczność wzorców adresów URL oznacza, że reguła może pasować do czegoś tak prostego jak dowolny zasób w ramach ścieżki, do bardzo szczegółowych i szczegółowych warunków. Wzorce powinny być na ogół znane użytkownikom popularnych bibliotek routingu.
source: określa sposób wczytywania zasobów zgodnych zcondition. Obecnie obsługiwana jest tylko wartość'network'(omijanie skryptu service worker w celu wczytywania zasobu bezpośrednio przez sieć), ale planujemy rozszerzyć to ustawienie na inne wartości w przyszłości.
Przypadki użycia
Jak wyjaśniliśmy, początkowa wersja interfejsu API stanowi w zasadzie wyjście awaryjne od kontroli instancji roboczej w przypadku niektórych ścieżek. To, gdzie warto go zastosować, zależy od tego, jak używasz skryptu service worker i jak użytkownicy poruszają się po witrynie.
Przykładem może być sytuacja, w której Twoja witryna korzysta ze strategii, w której zapisujesz dane w pamięci podręcznej (powracającą do sieci), ale są w niej treści, które są tak rzadko odwiedzane, że nie mają wartości w pamięci podręcznej (np. treści archiwalne lub kanały RSS). Ograniczenie pobierania tych ścieżek z sieci można skonfigurować tylko w skrypcie service worker, ale musi on się jednak uruchomić i uruchomić, aby określić sposób obsługi tych żądań.
Z kolei statyczny interfejs API routingu całkowicie pomija skrypt service worker za pomocą kilku wierszy deklaratywnej:
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 chcemy zwiększyć elastyczność tej konfiguracji i obsługować więcej scenariuszy, takich jak deklaratywne wyścigi przy pobieraniu sieci i uruchamianiu skryptu service worker. Więcej informacji znajdziesz w eksploracji potencjalnej „ostatecznej postaci” interfejsu API w wyjaśnieniu specyfikacji.
Wypróbowywanie interfejsu Service Worker Static Routing API
Interfejs Service Worker Static Routing API jest dostępny w Chrome od wersji 116 po okresie próbnym origin, który umożliwia deweloperom przetestowanie interfejsu API w witrynie z udziałem prawdziwych użytkowników w celu zmierzenia jego skuteczności. Więcej informacji na temat testowania origin znajdziesz w artykule Pierwsze kroki z testami origin.
Na potrzeby testów lokalnych interfejs Service Worker Static Routing API można włączyć za pomocą flagi chrome://flags/#service-worker-static-router lub uruchomienia Chrome za pomocą polecenia, np. --enable-features=ServiceWorkerStaticRouter.
Opinie i przyszłe wskazówki dojazdu
Interfejs Service Worker Static Routing API jest obecnie rozwijany i nadal ma swój kształt. Jeśli wydaje się, że może to być dla Ciebie przydatne, wypróbuj je w ramach testu origin i prześlij opinię na temat interfejsu API, jego implementacji i dostępnych funkcji.