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 usługę fetchobsługuje każdą prośbę ze strony, którą kontroluje, i może zdecydować, czy ma zwrócić odpowiedź z poziomu pamięci podręcznej 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 używają usług roboczych do poprawy wydajności za pomocą strategii buforowania, może być znaczący.
Przedwczytywanie danych nawigacji to jedno z rozwiązań tego problemu. Umożliwia ono wysyłanie żądań nawigacji 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 routingu statycznego 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 workera. 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, używając 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. Te wzorce 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 ramach usługi w celu bezpośredniego wczytania zasobu przez sieć), ale w przyszłości planujemy rozszerzenie tej funkcji na 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ługi i jak użytkownicy poruszają się po Twojej witrynie.
Przykładem może być sytuacja, w której Twoja witryna korzysta z strategii „pamięć podręczna w pierwszej kolejności” (z użyciem sieci jako zapasu), 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.
Routing statyczny API, w przeciwieństwie do tego, całkowicie omija usługę workera za pomocą 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 API routingu statycznego Service Worker ta konfiguracja ma stać się bardziej elastyczna i obsługiwać więcej scenariuszy, takich jak deklaratywna obsługa pobierania z sieci i uruchamiania Service Workera. Więcej informacji znajdziesz w opracowaniu specyfikacji dotyczącej potencjalnej „ostatecznej wersji” interfejsu API.
Wypróbuj interfejs 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ń, np. --enable-features=ServiceWorkerStaticRouter.
Opinie i dalsze działania
Interfejs API routingu statycznego Service Worker jest aktywnie rozwijany i nadal jest w trakcie 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.