Esta documentação abordou o pré-armazenamento em cache anteriormente, mas não o suficiente sobre como fazer isso corretamente. Isso é importante porque, independente de você usar o Workbox, é fácil pré-armazenar em cache demais e desperdiçar dados e largura de banda. Tenha cuidado sobre como o payload de pré-armazenamento em cache afeta a experiência do usuário.
Ao ler este documento, entenda que estas são diretrizes gerais. A arquitetura e os requisitos do seu aplicativo podem exigir que você faça as coisas de forma diferente das sugeridas aqui, mas essas diretrizes servem como bons padrões.
O que fazer: pré-armazenar em cache recursos estáticos críticos
Os melhores candidatos para o pré-armazenamento em cache são os recursos estáticos essenciais, mas o que conta como um recurso "crítico"? Do ponto de vista do desenvolvedor, pode ser tentador pensar que um aplicativo inteiro é "crítico", mas o ponto de vista do usuário é o mais importante. Pense em recursos essenciais como aqueles totalmente necessários para oferecer uma experiência do usuário:
- Folhas de estilo globais.
- Arquivos JavaScript que oferecem funcionalidade global.
- HTML do shell do aplicativo, se for o caso da sua arquitetura.
Lembrete: estas são diretrizes gerais, não recomendações rígidas. Ao fazer o pré-armazenamento de recursos em cache, é melhor errar pelo excesso de pré-armazenamento em cache.
O que fazer: pré-armazenar em cache um substituto off-line para sites com várias páginas
Para sites com várias páginas, você pode usar uma estratégia de armazenamento em cache que prioriza a rede ou somente rede para lidar com as solicitações de navegação.
Nesses casos, convém garantir que o service worker pré-cache e responda com uma página substituta off-line quando o usuário faz uma solicitação de navegação enquanto estiver off-line. Uma maneira de fazer isso no Workbox é usar uma estratégia somente de rede com um substituto off-line e aproveitar a pré-carregamento de navegação:
import {PrecacheFallbackPlugin, precacheAndRoute} from 'workbox-precaching';
import {registerRoute, Route} from 'workbox-routing';
import {NetworkOnly} from 'workbox-strategies';
import * as navigationPreload from 'workbox-navigation-preload';
navigationPreload.enable();
// Ensure that /offline.html is part of your precache manifest!
precacheAndRoute(self.__WB_MANIFEST);
// The network-only callback should match navigation requests, and
// the handler for the route should use the network-only strategy, but
// fall back to a precached offline page in case the user is offline.
const networkOnlyNavigationRoute = new Route(({request}) => {
return request.mode === 'navigate';
}, new NetworkOnly({
plugins: [
new PrecacheFallbackPlugin({
fallbackURL: '/offline.html'
})
]
}));
registerRoute(networkOnlyNavigationRoute);
Isso garante que, se um usuário ficar off-line e acessar uma página que não está no cache, ele receberá pelo menos parte do conteúdo off-line.
Talvez sim: considere o pré-armazenamento em cache especulativo
Essa pode ser uma "talvez", mas há um potencial benefício no armazenamento prévio de recursos em cache que são usados apenas em determinadas situações. Pense assim: os usuários terão alguns downloads iniciais extras de dados, com o benefício especulativo de acelerar solicitações futuras para esses ativos.
Agora, a grande ressalva: tenha muito cuidado se decidir fazer isso. É fácil desperdiçar dados ao fazer isso, e a decisão deve ser baseada em dados. Além disso, evite pré-armazenar em cache especulativa recursos que mudam com frequência, já que o usuário vai consumir mais dados sempre que o código de pré-armazenamento detectar uma nova revisão. Observe os fluxos de usuários na sua análise para ver aonde eles tendem a ir. Se você tiver alguma dúvida sobre o pré-armazenamento em cache especulativo de recursos, provavelmente é um bom sinal não fazer isso.
Talvez não faça isso: pré-armazenar em cache o HTML estático
Essa diretriz se aplica mais a sites estáticos em que os arquivos HTML discretos são gerados por um gerador de site estático ou criados manualmente, em vez de serem gerados dinamicamente ou fornecidos por um back-end de aplicativo. Se isso descreve sua arquitetura, provavelmente é melhor você não pré-armazenar em cache todos os arquivos HTML do site.
Um problema com o armazenamento prévio de arquivos HTML em um site inteiro é que a marcação que é pré-armazenada em cache agora sempre será disponibilizada a partir do cache mais tarde, até que o service worker seja atualizado. Isso é excelente para o desempenho, mas pode levar a uma desistência significativa do cache se o HTML do site muda com frequência.
No entanto, há algumas exceções a essa regra. Se você estiver implantando um site pequeno com alguns arquivos HTML estáticos, provavelmente é bom pré-armazenar em cache todas essas páginas para que elas fiquem disponíveis off-line. Se você tem um site especialmente grande, considere armazenar previamente em cache algumas páginas de alto valor e um substituto off-line. Além disso, use o armazenamento em cache do ambiente de execução para armazenar outras páginas em cache para você.
O que não fazer: pré-armazenar em cache imagens responsivas ou favicons
Essa não é uma diretriz geral e sim uma regra. As imagens responsivas são uma solução complexa para um problema complexo: você tem muitos usuários em muitos dispositivos, cada um variando em tamanho de tela, densidade de pixels e suporte para formatos alternativos. Se você pré-armazenar em cache um conjunto inteiro de imagens responsivas, é provável que esteja armazenando previamente várias imagens, quando o usuário talvez acabe fazendo o download de apenas uma delas.
Favicons apresenta uma situação semelhante, em que os sites geralmente implantam um conjunto inteiro de favicons para diferentes cenários. Na maioria das vezes, apenas um favicon é solicitado, fazendo com que o armazenamento prévio em cache de um conjunto de favicons inteiro seja um desperdício.
Contribua com seus usuários e não pré-cache de conjuntos de imagens responsivas e favicons. Confie no armazenamento em cache do ambiente de execução. Se você precisar fazer o pré-cache de imagens, armazene em cache imagens usadas com frequência que não fazem parte de um conjunto de favicons ou imagens responsivas. Os SVGs são menos arriscados em termos de uso de dados. Um único SVG é renderizado de maneira ideal, independentemente da densidade de pixels de uma determinada tela.
O que não fazer: pré-armazenar polyfills em cache
A compatibilidade com diferentes navegadores para APIs é um desafio permanente para os desenvolvedores da Web, e o polyfilling é uma das maneiras de superar esse desafio. Uma maneira de minimizar o custo de desempenho dos polyfills é fazer a verificação de recursos e carregá-los somente para os navegadores que precisam deles.
Como o carregamento condicional de polyfills acontece durante o tempo de execução em relação ao ambiente atual, o armazenamento prévio de polyfills é uma aposta. Alguns usuários se beneficiam disso, enquanto outros acabam desperdiçando largura de banda para polyfills desnecessários.
Não armazene os polyfills previamente em cache. Confie no armazenamento em cache em tempo de execução para garantir que eles sejam armazenados em cache somente em navegadores que precisam deles para evitar o desperdício de dados.
Conclusão
O pré-armazenamento em cache exige uma previsão dos recursos que os usuários realmente precisam com antecedência, mas é possível acertar de maneira que priorize o desempenho e a confiabilidade futuros.
Caso não tenha certeza se determinados recursos precisam ser pré-armazenados em cache, a melhor opção é pedir para o Workbox excluir esses recursos e criar uma rota de armazenamento em cache no tempo de execução para processá-los. De qualquer forma, o pré-armazenamento em cache é abordado em detalhes mais adiante nesta documentação. Portanto, você poderá aplicar esses princípios à sua lógica de pré-armazenamento em cache no futuro.