Используйте API статической маршрутизации Service Worker, чтобы обойти Service Worker для определенных путей

Rachel Andrew

Начиная с Chrome 123, доступен API статической маршрутизации Service Worker. Этот API позволяет декларативно указывать, как должны извлекаться определенные пути к ресурсам, то есть браузеру не нужно запускать Service Worker только для получения ответов из кэша или напрямую из сети. Этот API находился в стадии тестирования с Chrome 116, и в этой статье подробно описывается запуск API в Chrome 123.

Примечание: Подробную информацию о данной функции см. в оригинальной публикации « Тестирование API статической маршрутизации Service Worker» .

Используйте API

Для использования API вызовите event.addRoutes в событии install сервис-воркера. Передайте этому методу список маршрутов со следующими свойствами:

condition

Указывает, когда применяется правило. Принимает следующие свойства:

• urlPattern : Экземпляр URLPattern или строка, представляющая допустимый URLPattern, которую можно передать в конструктор URLPattern .
• requestMethod : Строка, содержащая метод запроса.
• requestMode : Строка, содержащая режим запроса.
• requestDestination : Строка, содержащая адрес назначения запроса.
• runningStatus : строка, либо "running" , либо "not-running" . Это указывает на статус работы сервис-воркера.

source

Указывает способ загрузки ресурсов, соответствующих condition . Одна из следующих строк:

• "network"
• "cache"
• "fetch-event"
• "race-network-and-fetch-handler"

Примечание: в source можно дополнительно указать имя кэша, пример см. далее в этом сообщении.

В следующем примере URL-адреса, начинающиеся с "/articles", направляются в сервис-воркер, если он в данный момент запущен. Если задано несколько условий, например, urlPattern и runningStatus , то для использования маршрута необходимо выполнение всех условий.

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

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

В следующем примере данные, отправленные через форму, передаются непосредственно в сеть, минуя сервис-воркер.

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

В следующем примере кэш-память с именем "pictures" используется для загрузки файлов с расширением .png или .jpg .

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

Изменения по сравнению с исходным испытанием.

В первоначальной тестовой версии использовался InstallEvent.registerRouter() вместо InstallEvent.addRoutes() , при этом метод registerRouter() можно было вызвать только один раз. Это изменение было основано на отзывах сообщества, полученных в ходе первоначальной тестовой версии .

Примечание: Если в вашем коде используется устаревший метод registerRouter() , вам следует перейти на addRoutes() . Мы планируем удалить registerRouter() в Chrome версии 125.

Новый API также использует изменения в URLPattern , представленные в Chrome 121 , добавляет возможность указывать метод запроса, режим и место назначения, а также добавляет дополнительные параметры источника.

Поддержка в инструментах разработчика Chrome

Зарегистрированные правила маршрутизатора отображаются на вкладке «Service Worker» панели приложения .

В панели «Сеть» , если запрос соответствует зарегистрированному правилу, это указывается в столбце «Размер». При наведении указателя мыши на столбец «Размер» отображается идентификатор зарегистрированного маршрутизатора. Соответствующие правила отображаются на вкладке «Приложение».