Сервис-воркеры — это мощный инструмент, позволяющий веб-сайтам работать в автономном режиме и создавать для себя специализированные правила кэширования. Обработчик fetch сервис-воркера видит каждый запрос со страницы, которую он контролирует, и может решить, хочет ли он обработать ответ на него из кэша сервис-воркера или даже переписать URL-адрес, чтобы получить совершенно другой ответ — например, на основе локальных данных. предпочтения пользователя.
Однако это может привести к снижению производительности сервисных работников, если страница загружается впервые за некоторое время, а контролирующий сервисный работник в данный момент не работает. Поскольку все выборки должны происходить через сервис-воркера, браузеру приходится ждать, пока сервис-воркер запустится и запустится, чтобы узнать, какой контент загружать. Эти затраты на запуск могут быть небольшими, но значительными для разработчиков, использующих сервис-воркеров для повышения производительности с помощью стратегий кэширования.
Предварительная загрузка навигации — это один из подходов к решению проблемы, позволяющий выполнять запросы навигации по сети параллельно с запуском сервис-воркера, но он ограничивается первоначальными запросами навигации и по-прежнему включает сервис-воркера в критический путь. С момента запуска предварительной загрузки навигации было предпринято множество попыток разработать более общее решение данной проблемы, включая способы вообще не блокировать некоторые запросы при запуске сервис-воркера.
API статической маршрутизации Service Worker
Начиная с Chrome 116, доступен экспериментальный API статической маршрутизации Service Worker для тестирования первого шага к такому решению. Когда Service Worker установлен, он может использовать API статической маршрутизации Service Worker, чтобы декларативно указать, как следует получать определенные пути к ресурсам.
В исходной версии API пути могут быть объявлены так, чтобы они всегда обслуживались из сети, а не от сервис-воркера. При последующей загрузке контролируемого URL-адреса браузер может начать извлечение ресурсов по этим путям до того, как сервис-воркер завершит запуск. Это удаляет сервис-воркера из путей, которые, как вы знаете, не нуждаются в сервис-воркере.
Чтобы использовать API, сервис-воркер вызывает event.registerRouter в событии install с набором правил:
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',
}]);
}
});
Каждое правило обычно имеет два свойства:
condition: указывает, когда правило применяется с использованием API шаблонов URL-адресов для сопоставления путей к ресурсам. Свойство может принимать экземплярURLPatternили эквивалентный простой объект, который совместим с передачей в конструкторURLPattern(например, либоnew URLPattern({pathname: '*.jpg'}), либо просто{pathname: '*.jpg'}).Гибкость шаблонов URL-адресов означает, что правило может сопоставить что-то простое, например, любой ресурс по пути, с очень конкретными и подробными условиями. Шаблоны, как правило, должны быть знакомы пользователям популярных библиотек маршрутизации.
source: указывает, как будет загруженоconditionсоответствия ресурсов. Сегодня поддерживается только значение'network'(минуя сервис-воркера для загрузки ресурса напрямую по сети), но в будущем планируется расширить это значение до других значений .
Варианты использования
Как объяснялось, первоначальная версия API по сути представляет собой запасной выход из-под контроля сервис-воркеров для некоторых путей. То, где это будет иметь смысл использовать, будет зависеть от того, как вы используете своего сервис-воркера и как пользователи перемещаются по вашему сайту.
Одним из примеров может быть случай, когда ваш сайт использует стратегию кэширования (возврат к сети), но есть некоторый контент, который настолько редко посещается, что его практически нет никакой ценности, когда-либо попадающей в кеш (например, архивный контент или RSS-каналы). Ограничение получения этих путей только из сети можно настроить в сервисном работнике, но сервисный работник все равно должен запуститься и работать, чтобы решить, как обрабатывать эти запросы.
API статической маршрутизации, напротив, полностью обходит сервис-воркера с помощью нескольких декларативных строк:
self.addEventListener('install', event => {
if (event.registerRouter) {
event.registerRouter([{
condition: {
urlPattern: {pathname: '/feeds/*.xml'},
},
source: 'network',
}, {
condition: {
urlPattern: {pathname: '/archives/*'},
},
source: 'network',
}]);
}
});
По мере развития API статической маршрутизации Service Worker планируется сделать эту конфигурацию более гибкой и поддерживать больше сценариев, таких как декларативное ускорение выборки сети и запуск Service Worker. Дополнительные сведения см . в описании спецификации потенциальной «окончательной формы» API .
Опробование API статической маршрутизации Service Worker
API статической маршрутизации Service Worker доступен в Chrome, начиная с версии 116, после пробной версии Origin , которая позволяет разработчикам тестировать API на своем сайте с реальными пользователями, чтобы измерить эффект. Дополнительную информацию об испытаниях происхождения см. в разделе «Начало работы с испытаниями происхождения» .
Для локального тестирования API статической маршрутизации Service Worker можно включить с помощью флага в chrome://flags/#service-worker-static-router или запустив Chrome с помощью команды, например --enable-features=ServiceWorkerStaticRouter .
Обратная связь и будущие направления
API статической маршрутизации Service Worker активно разрабатывается и все еще находится в стадии формирования. Если вам кажется, что это может быть полезно для вас, опробуйте его в пробной версии Origin и оставьте отзыв об API, реализации и доступных функциях .