Implantar um service worker pode alterar os comportamentos de um site de maneiras imprevistas. Como o Workbox facilita a gravação e implantação de um service worker, pode ser mais fácil não perceber alguns dos efeitos que um service worker tem em um site após a implantação.
Isso não significa que o uso do Workbox resulta em resultados ruins, apenas que a conveniência que ele oferece pode facilitar algumas armadilhas se alguém não estiver ciente do que acompanha a implantação de um service worker.
Armadilhas do pré-armazenamento em cache
O pré-armazenamento em cache foi abordado anteriormente nestes documentos sem abordar totalmente como a prática pode não dar certo. Talvez você encontre problemas se aplicar o pré-armazenamento em cache a muitos recursos ou se o service worker estiver registrado antes que a página tenha a chance de terminar de carregar recursos essenciais.
Como o comportamento padrão de workbox-webpack-plugin
é instruir o service worker a pré-armazenar em cache os recursos gerados automaticamente,
isso pode ser problemático de maneira fácil de passar, já que a barreira à adoção é baixa.
workbox-webpack-plugin.
Neste exemplo, 14 recursos são pré-armazenados em cache no projeto atual, totalizando 352 kilobytes por padrão.Quando um service worker armazena recursos em cache durante a instalação, uma ou mais solicitações de rede são iniciadas simultaneamente. Caso contrário, isso pode ser um problema para a experiência do usuário. Mesmo que o tempo seja preciso, ele ainda pode desperdiçar dados se a quantidade de ativos pré-cache não for limitada de alguma forma.
Está tudo no momento
Se um service worker armazenar qualquer item em cache, o momento em que ele é registrado será importante.
Os service workers geralmente são registrados usando elementos <script> inline.
Isso significa que os analisadores de HTML podem descobrir o código de registro do service worker antes que os recursos essenciais da página sejam carregados.
Isso é um problema. O ideal é que um service worker seja neutro em relação ao desempenho na pior das hipóteses,
e não a piorar o desempenho. Contribua para os usuários e
registre um service worker quando o evento load da página for disparado.
Isso reduz a chance de que o pré-armazenamento em cache interfira no carregamento dos recursos essenciais de uma página,
o que significa que ela pode ficar interativa mais rapidamente sem lidar com solicitações de rede de recursos que talvez não sejam necessários até mais tarde.
Considere o uso de dados
Seja qual for o período, o pré-armazenamento em cache envolve o envio de solicitações de rede. Se um manifesto de recursos para pré-cache não for cuidadosamente selecionado, o resultado pode ser uma quantidade de desperdício.
O desperdício de dados é uma possível desvantagem do armazenamento em cache. No entanto, nem todos têm acesso a Internet rápida ou mesmo a planos de dados ilimitados. Ao fazer o armazenamento em cache, considere cortar recursos especialmente grandes e contar com o armazenamento em cache no tempo de execução para capturá-los, em vez de fazer suposições caras.
A inicialização do service worker pode atrasar solicitações de rede
Os service workers são executados em um processo separado do restante do código de um site. Esse processo começa e para com frequência. Quando um service worker precisa processar um evento de busca depois de estar inativo, o navegador precisa passar um tempo inicializando o service worker. Essa sobrecarga extra antes que uma solicitação possa ser tratada é pequena em comparação com o benefício de fornecer uma resposta a partir do cache em vez da rede.
Ao usar estratégias que não podem ser exibidas a partir do cache e precisam acessar a rede, principalmente ao processar solicitações de navegação, o tempo de inicialização sempre adiciona algum atraso. Dependendo dos recursos do dispositivo e/ou da pressão da CPU, uma solicitação de navegação pode apresentar um atraso perceptível devido a inicializações lentas do service worker. Implantar um service worker sem perceber esse atraso significa que os usuários podem ter um impacto de desempenho não intencional.
Esse problema foi resolvido com o pré-carregamento de navegação, mas ainda não é compatível com todos os navegadores. No entanto, vale a pena considerar seu uso e será abordado mais adiante nesta documentação.
Estratégias que priorizam o cache podem dar errado
As estratégias que consultam o cache primeiro ou apenas consultam o cache são ótimas para acesso off-line e desempenho. No entanto, elas tendem a causar problemas em alguns casos específicos.
Armazenamento em cache de recursos estáticos sem versão no momento da execução
Os bundlers geralmente criam versões de recursos estáticos com um hash baseado em conteúdo no nome do arquivo (por exemplo, styles.a4edf38c.css).
Em service workers que usam estratégias de armazenamento em cache que consultam o cache primeiro para recursos estáticos e usam uma estratégia que prioriza a rede para marcação de página,
não deve haver problemas de armazenamento em cache, já que os recursos atualizados são referenciados na marcação que é sempre recuperada da rede.
Os problemas surgem em situações em que recursos estáticos sem versão são armazenados em cache durante a execução usando essas estratégias.
Se a funcionalidade de um site for fornecida por app.js e uma estratégia de execução que prioriza o cache for usada,
o app.js será atualizado mais tarde sem mudança no nome do arquivo.
A versão inicialmente armazenada em cache continuará sendo disponibilizada pelo cache em vez de ser atualizada.
A solução é usar uma estratégia que consulte a rede em busca de atualizações, como priorização da rede ou inatividade durante a revalidação. Como alternativa, as ferramentas de build podem gerar um manifesto de pré-cache para esses recursos, já que a lógica de pré-armazenamento em cache do Workbox os mantém atualizados.
Independentemente disso, considere fazer o controle de versões dos recursos estáticos, seja por um hash no nome do recurso ou na string de consulta. Isso evitará problemas com recursos obsoletos em service workers que usam estratégias de ambiente de execução que priorizam o cache para recursos estáticos.
Lembre-se das cotas de armazenamento
É comum lançar atualizações do service worker de vez em quando e, quando as atualizações são lançadas, os caches antigos com nomes expirados geralmente são removidos durante a ativação do novo service worker.
No entanto, algumas iterações do service worker são de longa duração ou os nomes de cache podem não ser atualizados em novas atualizações. Quando isso acontece, os recursos estáticos antigos podem se acumular em caches à medida que as atualizações deles são lançadas. Os navegadores definem cotas de armazenamento, e os limites podem variar. Esse é um bom motivo para prestar atenção a eles.
O Workbox consegue atenuar esses problemas, mas as cotas de armazenamento ainda podem ser excedidas. Você pode ter um controle mais preciso dos caches com o módulo workbox-expiration.
Não tenha medo
Implantar um service worker não é pouca coisa. No entanto, não deve ser um feito assustador com um pouco de planejamento e mindfulness do que envolve a implantação de um service worker com o Workbox. Esta documentação vai ajudar a lidar com essas preocupações com cuidado e confiança.