Os service workers são uma ferramenta poderosa para permitir que os sites funcionem off-line e
criem regras especializadas de armazenamento em cache para eles mesmos. Um gerenciador fetch
do service worker vê todas as solicitações de uma página que controla e pode decidir se quer
fornecer uma resposta para ela do cache do service worker ou até mesmo reescrever o URL
para buscar uma resposta totalmente diferente, por exemplo, com base nas preferências locais
do usuário.
No entanto, pode haver um custo de desempenho para os service workers quando uma página é carregada pela primeira vez após um período e o service worker de controle não está em execução no momento. Como todas as buscas precisam acontecer por meio do service worker, o navegador precisa esperar que ele seja iniciado e executado para saber qual conteúdo carregar. Esse custo de inicialização pode ser pequeno, mas significativo, para os desenvolvedores que usam service workers para melhorar o desempenho por meio de estratégias de armazenamento em cache.
Pré-carregamento de navegação é uma abordagem para resolver o problema, permitindo que solicitações de navegação sejam feitas pela rede em paralelo à inicialização do service worker, mas é limitado a solicitações de navegação inicial e ainda inclui o service worker no caminho crítico. Desde o lançamento do pré-carregamento de navegação, houve vários esforços para desenvolver uma solução mais geral para o espaço do problema, incluindo maneiras para que algumas solicitações não sejam bloqueadas na inicialização do service worker.
API Service Worker Static Routing
A partir do Chrome 116, a API experimental Service Worker Static Routing está disponível para testar a primeira etapa dessa solução. Quando um service worker é instalado, ele pode usar a API Service Worker Static Routing para declarar de maneira declarativa como determinados caminhos de recursos precisam ser buscados.
Na versão inicial da API, os caminhos podem ser declarados para sempre serem disponibilizados pela rede, não pelo service worker. Quando um URL controlado é carregado posteriormente, o navegador pode começar a buscar recursos desses caminhos antes que o service worker termine. Isso remove o service worker dos caminhos que você sabe que não precisam de um.
Para usar a API, o service worker chama event.registerRouter no evento install com um conjunto de regras:
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',
}]);
}
});
Geralmente, cada regra tem duas propriedades:
condition: especifica quando a regra é aplicada usando a API URL Pattern para corresponder aos caminhos dos recursos. A propriedade pode usar uma instânciaURLPatternou o objeto simples equivalente compatível com a transmissão para o construtorURLPattern(por exemplo,new URLPattern({pathname: '*.jpg'})ou apenas{pathname: '*.jpg'}).A flexibilidade dos padrões de URL significa que a regra pode corresponder a algo tão simples quanto qualquer recurso em um caminho a condições muito específicas e detalhadas. Os padrões geralmente são conhecidos pelos usuários de bibliotecas de roteamento conhecidas.
source: especifica como os recursos correspondentes aconditionserão carregados. Atualmente, apenas o valor'network'é aceito (ignorando o service worker para carregar o recurso diretamente pela rede), mas o plano é expandir isso para outros valores no futuro.
Casos de uso
Como explicado, a versão inicial da API é essencialmente uma saída do controle do service worker para alguns caminhos. O local em que isso fará sentido depende de como você usa o service worker e como os usuários percorrem o site.
Um exemplo pode ser quando o site usa uma estratégia que prioriza o cache (voltando à rede), mas há conteúdo tão raramente visitado que tem pouco ou nenhum valor acessando o cache (como conteúdo arquivado ou feeds RSS). A restrição desses caminhos para buscas na rede só pode ser configurada no service worker, mas ele ainda precisa ser iniciado e executado para decidir como lidar com essas solicitações.
A API de roteamento estático, por outro lado, ignora o service worker completamente com algumas linhas declarativas:
self.addEventListener('install', event => {
if (event.registerRouter) {
event.registerRouter([{
condition: {
urlPattern: {pathname: '/feeds/*.xml'},
},
source: 'network',
}, {
condition: {
urlPattern: {pathname: '/archives/*'},
},
source: 'network',
}]);
}
});
À medida que a API Service Worker Static Routing evolui, o plano é que essa configuração fique mais flexível e ofereça suporte a mais cenários, como acelerar declarativamente uma busca de rede e a inicialização do service worker. Para mais detalhes, consulte a explicação da especificação sobre uma possível "forma final" da API.
Como testar a API Service Worker Static Routing
A API Service Worker Static Routing está disponível no Chrome a partir da versão 116 por trás de um teste de origem, que permite que os desenvolvedores testem a API no próprio site com usuários reais para medir o efeito. Consulte Primeiros passos com testes de origem para informações básicas sobre esses testes.
Para testes locais, a API Service Worker Static Routing pode ser ativada com uma
sinalização em chrome://flags/#service-worker-static-router ou executando o Chrome
no comando, como --enable-features=ServiceWorkerStaticRouter.
Feedback e futuras instruções
A API Service Worker Static Routing está em desenvolvimento e ainda está sendo moldada. Se você acha que ele pode ser útil, faça um teste no teste de origem e envie feedback sobre a API, a implementação e a funcionalidade disponível.