Registro do service worker

Práticas recomendadas para sincronizar o registro do service worker.

Jeff Posnick

Serviço trabalhadores pode acelerar visitas repetidas ao seu aplicativo da web, mas recomendamos para garantir que a instalação inicial de um service worker não prejudique um a primeira visita do usuário.

Em geral, adiar o service worker inscrição até que a página inicial tenha sido carregada oferecerá a melhor experiência principalmente aqueles em dispositivos móveis com conexões de rede mais lentas.

Código boilerplate de registro comum

Se você já leu sobre os service workers, provavelmente já se deparou boilerplate semelhante ao seguinte:

if ('serviceWorker' in navigator) {
    navigator.serviceWorker.register('/service-worker.js');
}

Às vezes, pode ser acompanhada por algumas instruções console.log() ou código que detecta uma atualização para um registro anterior de service worker, como forma de solicitando que os usuários atualizem a página. Mas essas são apenas pequenas variações algumas linhas de código padrão.

Então, há alguma nuances para navigator.serviceWorker.register? Há algum práticas recomendadas a serem seguidas? Sem surpresas (como este artigo não termina a resposta para as duas perguntas é "sim!".

Primeira visita de um usuário

Vamos considerar a primeira visita de um usuário a um app da Web. Ainda não há service worker, e o navegador não tem como saber antecipadamente se haverá um serviço worker que será instalado.

Como desenvolvedor, sua prioridade deve ser garantir que o navegador rapidamente recebe o conjunto mínimo de recursos críticos necessários para exibir uma página. Tudo que retarda o recebimento dessas respostas é inimigo uma experiência de interação muito rápida.

Agora imagine que no processo de download do JavaScript ou das imagens que sua página precisa ser renderizada, o navegador decide iniciar uma linha de execução em segundo plano ou (para fins de brevidade, vamos presumir que é um thread). Suponha que não se usa um computador superrápido, mas uma máquina de baixa potência celular que a maior parte do mundo considera o dispositivo principal. Ativando esse thread extra adiciona contenção de tempo de CPU e memória que seu navegador poderia gastar na renderização de uma página da Web interativa.

É pouco provável que uma linha de execução inativa em segundo plano faça uma diferença significativa. Mas o que se a linha de execução não estiver ociosa, mas decidir que também vai iniciar fazendo o download de recursos da rede? Qualquer preocupação com CPU ou memória a contenção deve ficar por trás das preocupações com a largura de banda limitada disponível em muitos dispositivos móveis. Largura de banda é algo valioso, portanto não prejudique essenciais fazendo o download de recursos secundários ao mesmo tempo.

Ou seja, executar uma nova linha de execução de service worker para fazer o download e armazenar em cache em segundo plano seu objetivo de oferecer a experiência de interação mais rápida na primeira vez que um usuário visita seu site.

Como melhorar o código boilerplate

A solução é controlar o início do service worker escolhendo quando chamar navigator.serviceWorker.register(): Uma regra prática simples seria adiar registro até depois do load event disparar em window, assim:

if ('serviceWorker' in navigator) {
    window.addEventListener('load', function() {
    navigator.serviceWorker.register('/service-worker.js');
    });
}

Mas o momento certo para iniciar o registro do service worker também pode depender sobre o que seu app da Web faz logo depois de carregar. Por exemplo, o Google I/O App da Web 2016 com uma animação curta antes da transição para a tela principal. Nossa equipe descobriu que chutar o registro do service worker durante a animação pode levar a instabilidade em dispositivos móveis de última geração. Em vez de oferecer aos usuários uma experiência ruim, atrasou o registro do service worker até depois da animação, quando o navegador estava terá alguns segundos de inatividade.

Da mesma forma, se o seu app da Web usa um framework que realiza configuração adicional depois a página for carregada, procure um evento específico do framework que indique quando trabalho é feito.

Visitas subsequentes

Até agora, nos concentramos na experiência da primeira visita, mas qual é o impacto o registro atrasado do service worker tem visitas repetidas ao seu site? Embora isso possa surpreender algumas pessoas, não haverá nenhum impacto.

Quando um service worker é registrado, ele passa pelo install e Ciclo de vida de activate . Depois de ativado, o service worker pode processar eventos fetch para qualquer visitas subsequentes ao seu app da Web. O service worker é iniciado antes do para qualquer página dentro do escopo seja feita, o que faz sentido quando você pensa sobre isso. Se o service worker atual não estava em execução antes da acessar uma página, ele não vai ter a chance de realizar eventos fetch para solicitações de navegação.

Então, quando há um service worker ativo, não importa quando você chama navigator.serviceWorker.register(), ou, na verdade, se você o chamar de qualquer maneira. A menos que você altere o URL do script do service worker, navigator.serviceWorker.register() é, na prática, um no-op nas visitas subsequentes. Quando for é irrelevante.

Motivos para registrar com antecedência

Há situações em que registrar o service worker já possível faz sentido? Quando o service worker usa clients.claim() para assumir o controle da página durante a primeira visita, e o service worker executa muito intensamente o tempo de execução armazenamento em cache dentro do gerenciador fetch. Nessa situação, há para ativar o service worker o mais rápido possível, para tentar preencher os caches do ambiente de execução com recursos que poderão ser úteis no futuro. Se seu aplicativo da web se enquadra nessa categoria, vale a pena dar um passo atrás para tornar verifique se o gerenciador install do service worker não solicita recursos que lutam por largura de banda com as solicitações da página principal.

Testar coisas novas

Uma ótima maneira de simular uma primeira visita é abrir seu aplicativo da Web em um navegador Chrome Navegação anônima janela, e analisar o tráfego de rede na plataforma DevTools (em inglês). Como uma Web desenvolvedor, você provavelmente recarrega uma instância local de dezenas de aplicativos da Web e dezenas de vezes por dia. No entanto, ao revisitar seu site quando já houver service worker e caches totalmente preenchidos, você não terá a mesma experiência que um novo usuário receberia, e é fácil ignorar um possível problema.

Um exemplo que ilustra a diferença que o momento do registro pode fazer. Ambas as capturas de tela foram feitas durante a visita a um exemplo app no Modo de navegação anônima usando a limitação de rede para simular uma conexão lenta.

A captura de tela acima reflete o tráfego de rede quando a amostra foi modificada para realizar o registro do service worker o mais rápido possível. Você pode ver solicitações de pré-armazenamento em cache (as entradas com o ícone de engrenagem ícone ao lado deles, originários do gerenciador install do service worker) intercalado com solicitações dos outros recursos necessários para exibir a página.

Na captura de tela acima, o registro do service worker foi adiado até após o página tinha carregado. Observe que as solicitações de pré-armazenamento em cache não são iniciadas até que todos os recursos foram buscados na rede, eliminando qualquer contenção por largura de banda larga. Além disso, como alguns dos itens que estamos armazenando em cache já estão cache HTTP do navegador, os itens com (from disk cache) na coluna - podemos preencher o cache do service worker sem ter que acessar a a rede novamente.

Você vai ganhar ponto se fizer esse tipo de teste em um dispositivo simples e real em um rede móvel real. É possível aproveitar a depuração remota do Google Chrome recursos para conectar um telefone Android ao computador por USB e verifique se o testes que você está executando realmente refletem a experiência do mundo real de muitos de seus usuários.

Conclusão

Para resumir, garantir que seus usuários tenham a melhor experiência de primeira visita deve ser uma prioridade máxima. Adiar o registro do service worker para após o carregou durante a visita inicial pode ajudar a garantir isso. Você ainda terá todos os benefícios de ter um service worker para visitas repetidas.

Uma maneira simples de garantir o atraso do ciclo inicial registro até que a primeira página tenha sido carregada é usar o seguinte:

if ('serviceWorker' in navigator) {
    window.addEventListener('load', function() {
    navigator.serviceWorker.register('/service-worker.js');
    });
}