Um recurso dos service workers é a capacidade de salvar arquivos no cache durante a instalação do service worker. Isso é chamado de "pré-armazenamento em cache". Com o armazenamento em cache, é possível disponibilizar arquivos armazenados em cache no navegador sem acessar a rede. Use o armazenamento em cache para recursos essenciais que seu site precisa mesmo quando estiver off-line: página principal, estilos, imagem substituta e scripts essenciais.
Por que usar o Workbox?
O uso do Workbox para pré-armazenamento em cache é opcional. É possível escrever seu próprio código para pré-armazenar em cache os recursos críticos quando o service worker estiver instalando. O principal benefício de usar o Workbox é o controle de versão 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 a atualização desses arquivos por conta própria.
Pré-armazenar em cache os manifestos
O pré-armazenamento em cache é conduzido por uma lista de URLs e informações de versões 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 que precisa estar no pré-cache de uma determinada versão de um app da Web. Um manifesto de pré-cache, no formato usado pelo Workbox, tem esta aparência:
[{
url: 'app.abcd1234.js'
}, {
url: 'offline.svg',
revision: '7836745f'
}, {
url: 'index.html',
revision: '518747aa'
}]
Quando o service worker é 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 versão já incluídas no URL (app é o nome real do arquivo e
.abcd1234 contém as informações de controle de versão, logo antes da extensão de 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ão nos URLs. Portanto, as ferramentas de build
do Workbox criam um campo revision separado, contendo um hash do conteúdo
do arquivo local.
Disponibilização de recursos pré-armazenados em cache
Adicionar recursos ao cache é apenas uma parte do processo de pré-armazenamento em cache. Depois que os
recursos são armazenados em cache, eles precisam responder às solicitações de saída. Isso exige um
listener de eventos fetch no service worker que possa verificar quais URLs foram
armazenados previamente em cache e retornar essas respostas de maneira confiável, ignorando a
rede no processo. Como o service worker verifica o cache em busca de respostas
e as usa antes da rede, isso é chamado de
estratégia que prioriza o cache.
Atualizações eficientes
Um manifesto de pré-cache fornece uma representação exata do estado de cache esperado. Se uma combinação de URL/revisão no manifesto mudar, um service worker saberá que a entrada em cache anterior não é mais válida e precisa ser atualizado. É necessária apenas uma única solicitação de rede, feita automaticamente pelo navegador como parte da verificação de atualização do service worker para determinar quais URLs armazenados em pré-cache precisam ser atualizados.
Atualizações de recursos armazenados previamente em cache
À medida que você lança novas versões do seu app da Web ao longo do tempo, é necessário manter os URLs pré-armazenados em cache atualizados, pré-armazenar recursos em cache e excluir entradas desatualizadas. Contanto que você continue gerando um manifesto de pré-cache completo sempre que recriar o site, esse manifesto vai servir como a "fonte da verdade" para seu estado de pré-cache em qualquer momento.
Se já houver um URL com um novo campo de revisão ou se algum URL tiver sido
adicionado ou descartado do manifesto, isso indica que o service worker precisa de atualizações,
como parte dos manipuladores de eventos
install
e
activate. Por exemplo, se você fez algumas mudanças no site e
criou novamente, o manifesto de pré-cache mais recente pode ter passado pelas seguintes
alterações:
[{
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 entradas armazenadas em cache anteriormente ('offline.svg' e 'index.html')
e armazenar novos URLs em cache ('app.ffaa4455.js'), bem como exclusões para limpar URLs
que não são mais usados ('app.abcd1234.js').
Experiência verdadeira de instalação na "app store"
Outro benefício do armazenamento em 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 acessa qualquer página do seu app da Web pela primeira vez, é possível pré-armazenar em cache todos os URLs necessários para exibir qualquer visualização do app da Web com antecedência, sem precisar esperar até que ele acesse cada visualização.
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 anteriormente. O armazenamento prévio em cache traz a mesma experiência para apps da Web.
Quais recursos precisam ser pré-armazenados em cache?
Consulte o guia Identificar o que está sendo carregado para ter uma boa noção de quais URLs são mais adequados para pré-armazenar em cache. A regra geral é pré-armazenar em cache qualquer HTML, JavaScript ou CSS que tenha sido carregado no início e seja crucial para a exibição da estrutura básica de uma determinada página.
É preferível evitar o armazenamento prévio de mídia ou de outros recursos que são carregados posteriormente, a menos que seja crucial para a funcionalidade do seu app da Web. Em vez disso, use uma estratégia de armazenamento em cache no momento da execução para garantir que esses recursos sejam armazenados em cache conforme você usa.
Tenha sempre em mente que o pré-armazenamento em cache envolve o uso da largura de banda da rede e do armazenamento no dispositivo do usuário (assim como a instalação de um app de uma app store). Cabe a você, como desenvolvedor, usar o pré-armazenamento em cache com cautela e evitar um manifesto de excesso de pré-cache.
As ferramentas de build do Workbox ajudam porque informam o número de itens no manifesto de pré-cache, bem como o tamanho total do payload.
A longo prazo, os visitantes recorrentes do seu app da Web se beneficiam do custo inicial do armazenamento em cache, já que a capacidade de evitar que a rede se beneficie rapidamente com a largura de banda economizada ao longo do tempo.