Um recurso dos service workers é a capacidade de salvar arquivos no cache quando ele está sendo instalado. Isso é chamado de "pré-cache". A pré-cacheação permite enviar arquivos em cache para o navegador sem acessar a rede. Use o pré-cache para recursos essenciais de que o site precisa, mesmo off-line: página principal, estilos, imagem de substituição e scripts essenciais.
Por que usar o Workbox?
O uso do Workbox para pré-cache é opcional. É possível escrever seu próprio código para armazenar em cache recursos essenciais em cache quando o service worker estiver sendo instalado. O principal benefício do uso do Workbox é o controle de versões pronto para uso. Você terá muito menos problemas para atualizar recursos pré-armazenados em cache usando o Workbox do que se tivesse que gerenciar o controle de versões e atualizar esses arquivos por conta própria.
Pré-cachear manifestos
A pré-cacheação é orientada por uma lista de URLs e informações de versionamento associadas a cada URL. Juntas, essas informações são conhecidas como um manifesto de pré-cache. O manifesto é a "fonte da verdade" para o estado de tudo o que precisa estar na pré-cache de uma determinada versão de um app da Web. Um manifesto de pré-cache, no formato usado pelo Workbox, é parecido com este:
[{
url: 'app.abcd1234.js'
}, {
url: 'offline.svg',
revision: '7836745f'
}, {
url: 'index.html',
revision: '518747aa'
}]
Quando o worker do serviço é instalado, três entradas de cache são criadas no
armazenamento de cache para cada um dos três URLs listados. O primeiro recurso tem informações de
versionamento já incluídas no URL (app é o nome do arquivo real e
.abcd1234 contém as informações de versionamento, logo antes da extensão do arquivo
.js). As ferramentas de build do Workbox podem detectar isso e excluir um campo de revisão. Os
outros dois recursos não incluem informações de controle de versões nos URLs. Portanto, as ferramentas de build
do Workbox criam um campo revision separado, contendo um hash do conteúdo
do arquivo local.
Como exibir recursos pré-armazenados em cache
Adicionar recursos ao cache é apenas uma parte da história de pré-cache. Depois que os
recursos são armazenados em cache, eles precisam responder às solicitações enviadas. Isso requer um
ouvinte de eventos fetch no service worker que possa verificar quais URLs foram
armazenados em cache e retornar essas respostas em cache de maneira confiável, ignorando a
rede no processo. Como o worker de serviço verifica o cache em busca de respostas
(e as usa antes da rede), isso é chamado de
estratégia de cache-first.
Atualizações eficientes
Um manifesto de pré-cache fornece uma representação exata do estado esperado do cache. Se uma combinação de URL/revisão no manifesto mudar, um worker de serviço sabe que a entrada armazenada em cache anterior não é mais válida e precisa ser atualizada. Ele só precisa de uma única solicitação de rede, feita automaticamente pelo navegador como parte da verificação de atualização do worker de serviço, para determinar quais URLs pré-armazenados em cache precisam ser atualizados.
Atualizações de recursos pré-armazenados em cache
À medida que você lança novas versões do app da Web, é necessário manter os URLs pré-armazenados em cache atualizados, pré-armazenar novos recursos e excluir entradas desatualizadas. Enquanto você continuar gerando um manifesto de pré-cache completo sempre que refazer o site, esse manifesto vai servir como a "fonte de verdade" do seu estado de pré-cache a qualquer momento.
Se houver um URL com um novo campo de revisão ou se algum URL foi
adicionado ou removido do manifesto, isso indica que o service worker precisa
ser atualizado como parte dos manipuladores de eventos
install
e
activate. Por exemplo, se você fez algumas mudanças no site e
recriou, o manifesto de pré-cache mais recente pode ter passado pelas seguintes
mudanças:
[{
url: 'app.ffaa4455.js'
}, {
url: 'offline.svg',
revision: '7836745f'
}, {
url: 'index.html',
revision: '518747aa'
}]
Cada uma dessas mudanças informa ao service worker que novas solicitações precisam ser
feitas para atualizar as entradas em cache anteriores ('offline.svg' e 'index.html')
e armazenar novos URLs em cache ('app.ffaa4455.js'), além de exclusões para limpar URLs
que não são mais usados ('app.abcd1234.js').
Experiência de instalação verdadeira da "app store"
Outro benefício do pré-cache é que você pode oferecer aos usuários uma experiência que seria difícil de alcançar fora de uma instalação de "app store". Quando um usuário visita uma página do seu app pela primeira vez, é possível pré-cachear todos os URLs necessários para mostrar qualquer uma das visualizações do app com antecedência, sem precisar esperar que ele acesse cada visualização individualmente.
Quando um usuário instala um app, ele espera que todas as partes sejam exibidas rapidamente, não apenas as visualizações que ele acessou no passado. O pré-armazenamento em cache oferece a mesma experiência para apps da Web.
Quais dos seus recursos precisam ser pré-armazenados em cache?
Consulte o guia Como identificar o que está sendo carregado para ter uma boa visão dos URLs que mais fazem sentido para pré-cachear. A regra geral é armazenar em cache antecipadamente qualquer HTML, JavaScript ou CSS que seja carregado antecipadamente e seja crucial para exibir a estrutura básica de uma determinada página.
É preferível evitar o pré-cache de mídia ou outros recursos carregados mais tarde, a menos que sejam essenciais para a funcionalidade do app da Web. Em vez disso, use uma estratégia de armazenamento em cache de execução para garantir que esses recursos sejam armazenados em cache conforme você os usa.
Lembre-se de que o pré-cache envolve o uso de largura de banda de rede e armazenamento no dispositivo de um usuário, assim como a instalação de um app de uma app store. Como desenvolvedor, cabe a você pré-armazenar em cache criteriosamente e evitar um manifesto de pré-armazenamento excessivo.
As ferramentas de build do Workbox ajudam a informar o número de itens no manifesto de pré-cache e o tamanho total do payload de pré-cache.
Os visitantes recorrentes do seu app da Web se beneficiam a longo prazo do custo inicial do pré-cache, já que a capacidade de evitar a rede se paga rapidamente em largura de banda economizada ao longo do tempo.