Usługi to potężne narzędzie umożliwiające stronom działanie w trybie offline i tworzenie własnych reguł buforowania. Obsługujący pracownik usługi fetch widzi każde żądanie ze strony, którą kontroluje, i może zdecydować, czy chce wyświetlić odpowiedź z poziomu pamięci podręcznej pracownika usługi, czy też zmienić adres URL, aby pobrać zupełnie inną odpowiedź – na przykład na podstawie lokalnych preferencji użytkownika.
Jednak gdy strona jest wczytywana po raz pierwszy od dłuższego czasu, a skrypt service worker kontrolujący nie jest obecnie uruchomiony, może to spowodować spadek wydajności skryptów service worker. Ponieważ wszystkie pobierania muszą odbywać się za pomocą workera usługi, przeglądarka musi poczekać, aż worker usługi się uruchomi i zacznie działać, aby wiedzieć, jakie treści wczytać. Ten koszt uruchomienia może być niewielki, ale dla deweloperów, którzy korzystają z usług workera, aby zwiększyć wydajność dzięki strategiom buforowania, może być znaczący.
Przedwczytywanie danych nawigacji to jedno z rozwiązań tego problemu. Umożliwia ono wysyłanie żądań nawigacyjnych przez sieć równolegle do uruchamiania pracownika usługi, ale jest ograniczone do początkowych żądań nawigacji i nadal obejmuje pracownika usługi na ścieżce krytycznej. Od czasu wprowadzenia funkcji wstępnego wczytywania nawigacji podjęliśmy wiele prób opracowania bardziej ogólnego rozwiązania tego problemu, w tym sposobów na to, aby niektóre żądania nie były w ogóle blokowane podczas uruchamiania usługi.
Interfejs API routingu statycznego Service Worker
Od wersji 116 Chrome eksperymentalny interfejs API do statycznego routingu w ramach skryptu service worker jest dostępny do testowania pierwszego kroku w kierunku takiego rozwiązania. Po zainstalowaniu może on używać interfejsu Service Worker Static Routing API do deklaratywnego określania sposobu pobierania określonych ścieżek zasobów.
W pierwszej wersji interfejsu API ścieżki można zadeklarować tak, aby zawsze były dostarczane z sieci, a nie z usługi skryptu service worker. Gdy kontrolowany adres URL zostanie później załadowany, przeglądarka może zacząć pobierać zasoby z tych ścieżek, zanim usługa skończy uruchamianie. Spowoduje to usunięcie skryptu usługi z ścieżek, które nie potrzebują skryptu usługi.
Aby korzystać z interfejsu API, usługa robocza wywołuje funkcję event.registerRouter w zdarzeniu install 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 zazwyczaj 2 właściwości:
condition: określa, kiedy reguła ma zastosowanie, za pomocą interfejsu PATTERN_URL API do dopasowywania ścieżek zasobów. Właściwość może przyjmować instancjęURLPatternlub równoważny prosty obiekt, który można przekazać do konstruktoraURLPattern(na przykładnew URLPattern({pathname: '*.jpg'})lub tylko{pathname: '*.jpg'}).Dzięki elastyczności wzorów adresów URL reguła może pasować do czegoś tak prostego jak dowolny zasób na ścieżce do bardzo szczegółowych warunków. Wzory powinny być ogólnie znane użytkownikom popularnych bibliotek routingu.
source: określa sposób wczytywania zasobów pasujących do wartościcondition. Obecnie obsługiwana jest tylko wartość'network'(obchodzenie usługi w tle, aby wczytać zasób bezpośrednio przez sieć), ale w przyszłości planujemy rozszerzenie tego o inne wartości.
Przypadki użycia
Jak już wyjaśniliśmy, początkowa wersja interfejsu API jest w istocie furtką dla usług workerów w przypadku niektórych ścieżek. To, kiedy warto go używać, zależy od tego, jak używasz usług workera i jak użytkownicy poruszają się po Twojej witrynie.
Przykładem może być sytuacja, w której Twoja witryna korzysta z strategii „najpierw pamięć podręczna” (z wykorzystaniem sieci), ale niektóre treści są tak rzadko odwiedzane, że rzadko trafiają do pamięci podręcznej (np. treści zarchiwizowane lub kanały RSS). Ograniczenie pobierania tych ścieżek tylko do sieci może zostać skonfigurowane w usługach workera, ale usługa workera musi się uruchomić i działać, aby zdecydować, jak obsługiwać te żądania.
Interfejs API statycznego routingu całkowicie pomija usługę w tle, korzystając z kilku deklaratywnych linii kodu:
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 ta konfiguracja ma stać się bardziej elastyczna i obsługiwać więcej scenariuszy, takich jak deklaratywna obsługa pobierania z sieci i uruchamiania serwisu workera. Więcej informacji znajdziesz w opracowaniu specyfikacji dotyczącej potencjalnej „ostatecznej wersji” interfejsu API.
Testowanie interfejsu API routingu statycznego Service Worker
Interfejs API do kierowania statycznego w usługach workera jest dostępny w Chrome od wersji 116. Aby go przetestować, deweloperzy mogą skorzystać z testu pochodzenia, który pozwala im przetestować interfejs API na stronie z udziałem prawdziwych użytkowników i zmierzyć jego wpływ. Informacje o testach pochodzenia znajdziesz w artykule „Pierwsze kroki z testami pochodzenia”.
Do testowania lokalnego interfejs API routingu statycznego Service Worker można włączyć za pomocą flagi chrome://flags/#service-worker-static-router lub uruchomić Chrome z poziomu wiersza poleceń, używając opcji --enable-features=ServiceWorkerStaticRouter.
Opinie i dalsze działania
Interfejs API routingu statycznego Service Worker jest aktywnie rozwijany i nadal jest w fazie ulepszania. Jeśli uważasz, że może Ci się przydać, wypróbuj go za pomocą testu wersji źródłowej i prześlij opinię na temat interfejsu API, implementacji i dostępnych funkcji.