O armazenamento em cache em tempo de execução refere-se à adição gradual de respostas a um cache conforme o uso. Embora o armazenamento em cache no tempo de execução não ajude com a confiabilidade da solicitação atual, ele pode ajudar a tornar solicitações futuras do mesmo URL mais confiáveis.
O cache HTTP do navegador é um exemplo de armazenamento em cache em tempo de execução. Ele só é preenchido após uma solicitação de um determinado URL. Mas os service workers permitem implementar o armazenamento em cache no ambiente de execução que vai além do que o cache HTTP sozinho pode oferecer.
Ser estratégico
Ao contrário do armazenamento em cache (que sempre tenta exibir um conjunto de arquivos predefinidos de um cache), o armazenamento em cache do ambiente de execução pode combinar acesso à rede e ao cache de várias maneiras. Geralmente, cada combinação é chamada de estratégia de armazenamento em cache. As principais estratégias de armazenamento em cache incluem:
- Priorização da rede
- Priorização do cache
- Desatualizado ao revalidar
Priorização da rede
Nessa abordagem, o service worker primeiro tenta recuperar uma resposta da rede. Se a solicitação de rede for bem-sucedida, ótimo. A resposta é retornada ao app da Web, e uma cópia da resposta é armazenada usando a API Cache Storage, criando uma nova entrada ou atualizando uma entrada anterior para o mesmo URL.
Se a solicitação de rede falhar totalmente ou demorar muito para retornar uma resposta, a resposta mais recente do cache será retornada.
Priorização do cache
Uma estratégia que prioriza o cache é efetivamente o oposto da priorização da rede. Nessa abordagem, quando o service worker intercepta uma solicitação, ele primeiro usa a API Cache Storage para ver se há uma resposta em cache disponível. Se houver, essa resposta será retornada ao app da Web.
No entanto, se houver uma ausência no cache, o service worker acessará a rede e tentará recuperar uma resposta. Se a solicitação de rede for bem-sucedida, ela será retornada ao seu app da Web e uma cópia será salva em um cache. Essa cópia em cache será usada para ignorar a rede na próxima vez que uma solicitação dos mesmos URLs for feita.
Desatualizado ao revalidar
O estado "desatualizado ao revalidar" é algo híbrido. Ao usá-lo, o service worker verifica imediatamente se há uma resposta armazenada em cache e, se alguma for encontrada, ela é transmitida de volta para seu app da Web.
Enquanto isso, independentemente de haver uma correspondência de cache, o service worker também dispara uma solicitação de rede para receber uma resposta "atualizada". Essa resposta é usada para atualizar qualquer resposta que tenha sido armazenada em cache. Se a verificação inicial de cache foi um erro, uma cópia da resposta da rede também será retornada ao seu app da Web.
Por que usar o Workbox?
Essas estratégias de armazenamento em cache equivalem a roteiros que você normalmente precisaria reescrever no seu próprio service worker várias vezes. Em vez de recorrer a isso, o Workbox as oferece empacotados como parte da biblioteca de estratégias, prontas para você usar no service worker.
O Workbox também oferece suporte ao controle de versões, permitindo que as entradas expirem automaticamente ou notifique seu app da Web quando ocorrerem atualizações em uma entrada armazenada em cache.
Quais recursos precisam ser armazenados em cache e com quais estratégias?
O armazenamento em cache no tempo de execução pode ser visto como um complemento do armazenamento prévio. Se todos os seus recursos já estiverem sendo pré-armazenados em cache, o processo estará concluído. Não há nada que precise ser armazenado em cache no momento da execução. No entanto, é provável que, para qualquer app da Web relativamente complexo, você não use tudo em cache antecipadamente.
Arquivos de mídia maiores, recursos disponibilizados por um host de terceiros, como CDN, ou respostas de API, são apenas alguns exemplos dos tipos de recursos que não podem ser efetivamente armazenados em cache. Use o painel "Network" no DevTools para identificar as solicitações que se enquadram nessa categoria e, para cada uma delas, pense em qual compensação entre atualização e confiabilidade é apropriada.
Use "desatualização durante a revalidação" para priorizar a confiabilidade em vez da atualização
Como uma estratégia de inatividade durante a revalidação retorna uma resposta armazenada em cache quase imediatamente, depois que o cache é preenchido por meio da primeira solicitação, você terá um desempenho rápido e confiável ao usar essa estratégia. Isso acontece com a desvantagem de receber dados de resposta que podem estar desatualizados em comparação com os que teriam sido recuperados da rede. O uso dessa estratégia funciona melhor para recursos como imagens de perfil do usuário ou as respostas iniciais da API usadas para preencher uma visualização, quando você sabe que mostrar algo imediatamente é fundamental, mesmo que seja um valor mais antigo.
Use priorização da rede para priorizar a atualização em vez da confiabilidade
De certo modo, usar uma estratégia que prioriza a rede significa admitir a derrota em sua batalha contra a rede. Ela tem prioridade, mas isso traz incerteza sobre a confiabilidade. Para determinados tipos de recursos, é preferível ter uma resposta nova em vez de informações desatualizadas. Você pode preferir a atualização ao fazer uma solicitação de API para o texto de um artigo que é atualizado com frequência, por exemplo.
Ao usar uma estratégia que prioriza a rede dentro de um service worker, em vez de entrar na rede diretamente, você tem a vantagem de poder recorrer a algo, mesmo que seja uma resposta potencialmente desatualizada. Você não será confiável rápido, mas pelo menos será confiável enquanto estiver off-line.
Usar priorização do cache para URLs com controle de versão
Em uma estratégia que prioriza o cache, depois que uma entrada é armazenada em cache, ela nunca é atualizada. Por isso, use-o apenas com recursos que você sabe que provavelmente não serão alterados. Ele funciona melhor principalmente para URLs que contêm informações de
controle de versões, o mesmo tipo de URLs que também precisam ser veiculados com um
cabeçalho de resposta Cache-Control: max-age=31536000.