Teste de origem da API Service Worker Static Routing

Brendan Kenny

Os service workers são uma ferramenta poderosa que permite que os sites funcionem off-line e criem regras de armazenamento em cache especializadas por conta própria. Um gerenciador fetch de service worker vê cada solicitação de uma página que ele controla e pode decidir se quer exibir uma resposta a 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 do usuário local.

No entanto, pode haver um custo de desempenho para service workers quando uma página é carregada pela primeira vez em algum momento 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 aguardar a inicialização e a execução do service worker para saber qual conteúdo carregar. Esse custo de inicialização pode ser pequeno, mas significativo, para desenvolvedores que usam service workers para melhorar o desempenho por meio de estratégias de armazenamento em cache.

O 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 é limitada às solicitações de navegação iniciais 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 de algumas solicitações não serem bloqueadas na inicialização do service worker.

A API Service Worker Static Routing

A partir do Chrome 116, a API Service Worker Static Roteamento experimental 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 forma declarativa como determinados caminhos de recursos precisam ser buscados.

Na versão inicial da API, os caminhos podem ser declarados para serem sempre 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 de iniciar. 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',
    }]);
  }
});

Cada regra geralmente tem duas propriedades:

• condition: especifica quando a regra se aplica usando a API URL Pattern para corresponder aos caminhos de recursos. A propriedade pode usar uma instância de URLPattern ou o objeto simples equivalente compatível com a transmissão para o construtor URLPattern (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 como 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 a condition serã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

Conforme 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 seu site.

Por exemplo, se o site usar uma estratégia que prioriza o cache (voltar à rede), mas houver conteúdo que é acessado tão raramente que tem pouco ou nenhum valor que chega ao cache (como conteúdo arquivado ou feeds RSS). A restrição desses caminhos a serem buscados na rede só pode ser configurada no service worker, mas o service worker ainda precisa ser iniciado e executado para decidir como processar essas solicitações.

A API de roteamento estático, por outro lado, ignora o service worker por completo 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 seja compatível com mais cenários, como corrida declarativamente em uma busca de rede e inicialização do service worker. Consulte como analisar uma possível "forma final" da API para saber mais.

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 site com usuários reais para medir o efeito. Consulte Introdução aos testes de origem para conferir informações 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 pelo comando, como com --enable-features=ServiceWorkerStaticRouter.

Feedback e instruções futuras

A API Service Worker Static Routing está sendo desenvolvida e ainda está sendo moldada. Se ele puder ser útil para você, faça um teste no teste de origem e envie feedback sobre a API, a implementação e a funcionalidade disponível.