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 criar regras de armazenamento em cache especializadas para si. Um service worker fetch de acesso da Web do Cloud Identity veja cada solicitação a partir de uma página que ele controla e possa decidir se quer exibir uma resposta a ele a partir do cache do service worker ou até mesmo reescrever o URL para buscar uma resposta totalmente diferente, por exemplo, com base no preferências.

No entanto, pode haver um custo de desempenho para service workers quando uma página é carregado pela primeira vez há algum tempo e o service worker de controle não em execução no momento. Como todas as buscas precisam acontecer por meio do service worker, o navegador precisa esperar a inicialização e a execução do service worker para saber o que conteúdo seja carregado. Esse custo de inicialização pode ser pequeno, mas significativo, para os desenvolvedores o uso de service workers para melhorar o desempenho com estratégias de armazenamento em cache.

O pré-carregamento de navegação é uma abordagem para resolvendo o problema, permitindo que solicitações de navegação sejam feitas pela rede em paralela à inicialização do service worker, mas é limitada à navegação inicial e ainda inclui o service worker no caminho crítico. Como pré-carregamento de navegação iniciado, houve vários esforços para desenvolver uma abordagem solução geral para o espaço do problema, incluindo formas de algumas solicitações não ser bloqueado na inicialização do service worker.

A API Service Worker Static Routing

A partir do Chrome 116, a API Service Worker Static Routing é experimental disponíveis para testar a primeira etapa dessa solução. Quando um service worker estiver instalado, ele poderá usar a API Service Worker Static Routing para soluções declarar como certos caminhos de recursos devem ser buscados.

Na versão inicial da API, os caminhos podem ser declarados para serem sempre veiculados. da rede, não do service worker. Quando um URL controlado é carregado posteriormente, o navegador pode começar a buscar recursos desses caminhos antes que o serviço foi iniciado. Isso remove o service worker dos caminhos que não precisa de um service worker.

Para usar a API, o service worker chama event.registerRouter no 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 é aplicada usando o API URL Pattern para corresponder a caminhos de recursos. A propriedade pode usar uma instância de URLPattern ou a 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 como simples como qualquer recurso em um caminho, até muito específico e detalhado pelas condições Os padrões geralmente são conhecidos pelos usuários de modelos bibliotecas de roteamento.

• 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 de emergência controle de service worker para alguns caminhos. O que faz sentido usar é vai depender de como você usa o service worker e como os usuários percorrem seu site.

Por exemplo, seu site pode usar uma estratégia que prioriza o cache. (voltando para a rede), mas há alguns conteúdos que são raramente visitados que há pouco ou nenhum valor em atingir o cache (como arquivos ou feeds RSS). Como restringir a busca desses caminhos na rede podem ser configurados no service worker, mas ele ainda precisa iniciar e executar 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 esta configuração para ficar mais flexível e compatível com mais cenários, como executar de maneira declarativa a busca de rede e a inicialização do service worker. Confira a explicação da especificação de uma possível "forma final" da API para mais detalhes.

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 atrás de um teste de origem; que permite que os desenvolvedores testem a API em seus sites com usuários reais para medir o efeito. Consulte Introdução aos testes de origem para informações básicas sobre testes de origem.

Para testes locais, a API Service Worker Static Routing pode ser ativada com uma em chrome://flags/#service-worker-static-router ou executando o Chrome pelo comando, como --enable-features=ServiceWorkerStaticRouter.

Feedback e instruções futuras

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