Teste de origem da API Service Worker Static Routing

Brendan Kenny

Os service workers são uma ferramenta poderosa para permitir que os sites funcionem off-line e criem regras de armazenamento em cache especializadas. Um manipulador fetch de service worker verifica todas as solicitações de uma página que ele controla e pode decidir se quer enviar uma resposta do cache do service worker ou até mesmo reescrever o URL para buscar uma resposta 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 em um tempo e o service worker de controle não está em execução. Como todas as transferências precisam acontecer pelo 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 desenvolvedores que usam service workers para melhorar o desempenho com estratégias de armazenamento em cache.

O pré-carregamento de navegação é uma abordagem para resolver o problema, permitindo que as solicitações de navegação sejam feitas pela rede em paralelo à inicialização do service worker, mas é limitado a 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 impedir que algumas solicitações sejam bloqueadas na inicialização do worker do serviço.

A API Service Worker de roteamento estático

A partir do Chrome 116, a API de roteamento estático do Service Worker experimental está disponível para testar a primeira etapa dessa solução. Quando um service worker é instalado, ele pode usar a API de roteamento estático do Service Worker para declarar como determinados caminhos de recursos precisam ser buscados.

Na versão inicial da API, os caminhos podem ser declarados para sempre serem fornecidos pela rede, e não pelo service worker. Quando um URL controlado é carregado mais tarde, o navegador pode começar a buscar recursos desses caminhos antes que o service worker termine a inicialização. Isso remove o service worker dos caminhos que você sabe que não precisam de um service worker.

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 receber uma instância URLPattern ou o objeto simples equivalente que é 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 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 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

Como explicado, a versão inicial da API é basicamente uma saída de emergência do controle do service worker para alguns caminhos. O uso desse recurso vai depender de como você usa o service worker e de como os usuários navegam pelo site.

Um exemplo disso é quando o site usa uma estratégia de priorização do cache (retornando à rede), mas há algum conteúdo que é tão raramente acessado que não há muito valor em armazená-lo no cache (como conteúdo arquivado ou feeds RSS). A restrição de que esses caminhos sejam buscados da rede só pode ser configurada no service worker, mas ele ainda precisa ser inicializado e executado para decidir como processar essas solicitações.

A API de roteamento estático, por outro lado, ignora completamente o service worker 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 de roteamento estático do Service Worker evolui, o plano é que essa configuração fique mais flexível e ofereça suporte a mais cenários, como uma corrida declarativa de uma busca de rede e a inicialização de um Service Worker. Consulte a explicação da especificação sobre uma possível "forma final" da API para mais detalhes.

Como testar a API de roteamento estático do Service Worker

A API de roteamento estático do Service Worker está disponível no Chrome a partir da versão 116, atrá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 "Começar a usar os testes de origem" para informações básicas sobre os testes de origem.

Para testes locais, a API de roteamento estático do Service Worker pode ser ativada com uma flag em chrome://flags/#service-worker-static-router ou executando o Chrome no comando, como com --enable-features=ServiceWorkerStaticRouter.

Feedback e futuras direções

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