Używanie interfejsu API routingu statycznego Service Worker do pomijania skryptu service worker na określonych ścieżkach

Od Chrome w wersji 123 dostępny jest interfejs API routingu statycznego Service Worker. Ten interfejs API umożliwia deklaratywne określenie, jak należy pobierać określone ścieżki zasobów, co oznacza, że przeglądarka nie musi uruchamiać skryptu service worker tylko po to, aby pobierać odpowiedzi z pamięci podręcznej lub bezpośrednio z sieci. Ten interfejs API jest testowany w ramach testowania origin od Chrome 116, a w tym poście opisujemy jego wprowadzenie w Chrome 123.

Korzystanie z interfejsu API

Aby użyć interfejsu API, wywołaj event.addRoutes w zdarzeniu install w procesie service worker. Przekaż do tej metody listę tras z tymi właściwościami:

condition
Określa, kiedy reguła ma być stosowana. Akceptuje te właściwości:
  • urlPattern: instancja URLPattern lub ciąg znaków reprezentujący prawidłowy URLPattern, który można przekazać do konstruktora URLPattern.
  • requestMethod: ciąg znaków zawierający metodę żądania.
  • requestMode: ciąg znaków zawierający tryb żądania.
  • requestDestination: ciąg znaków zawierający miejsce docelowe żądania.
  • runningStatus: ciąg znaków, który może mieć wartość "running" lub "not-running". Wskazuje stan działania skryptu service worker.
source
Określa sposób ładowania zasobów pasujących do condition. Jeden z tych ciągów znaków:
  • "network"
  • "cache"
  • "fetch-event"
  • "race-network-and-fetch-handler"

W tym przykładzie adresy URL zaczynające się od „/articles” są kierowane do procesu service worker, jeśli jest on aktualnie uruchomiony. Jeśli występuje kilka warunków, np. urlPatternrunningStatus, aby można było użyć trasy, wszystkie muszą być spełnione.

addEventListener('install', (event) => {
  event.addRoutes({
    condition: {

          urlPattern: "/articles/*",
          runningStatus: "running"
    },
    source: "fetch-event"
  });
});

W tym przykładzie posty w formularzu są wysyłane bezpośrednio do sieci i pomijają proces roboczy usługi.

addEventListener('install', (event) => {
  event.addRoutes({
    condition: {
          urlPattern: "/form/*",
          requestMethod: "post"
    },
    source: "network"
  });
});

W tym przykładzie pamięć podręczna o nazwie "pictures" służy do pobierania plików z rozszerzeniem .png lub .jpg.

addEventListener('install', (event) => {
  event.addRoutes({
    condition: {
      or: [
        {urlPattern: "*.png"},
        {urlPattern: "*.jpg"}
      ]
    },
    source: {
      cacheName: "pictures"
    }
  });
});

Zmiany w testowaniu origin

W pierwotnej wersji próbnej zamiast InstallEvent.addRoutes() używano InstallEvent.registerRouter(), a metodę registerRouter() można było wywołać tylko raz. Ta zmiana została wprowadzona na podstawie opinii społeczności na temat testu origin.

Nowy interfejs API korzysta też ze zmian w URLPattern wprowadzonych w Chrome 121, umożliwia określanie metody, trybu i miejsca docelowego żądania oraz dodaje dodatkowe opcje źródła.

Obsługa w Narzędziach deweloperskich w Chrome

Zarejestrowane reguły routera są wyświetlane na karcie Service Worker w panelu Aplikacja.

Reguły routera wyróżnione w panelu Aplikacja.

Jeśli żądanie pasuje do zarejestrowanej reguły, w panelu Sieć w kolumnie rozmiaru pojawi się odpowiednia informacja. Gdy wskaźnik znajduje się nad kolumną rozmiaru, wyświetlany jest zarejestrowany identyfikator routera. Odpowiednie reguły są wyświetlane na karcie aplikacji.

Identyfikator routera wyświetlany w panelu Sieć.