Esta documentação abordou o armazenamento em cache anteriormente, mas não o suficiente sobre como fazer isso corretamente. Isso é importante porque, independentemente de você usar o Workbox, é fácil armazenar muitos dados em cache, o que pode desperdiçar dados e largura de banda. Você deve tomar cuidado com a forma 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 maneira diferente do sugerido 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 ativos estáticos críticos, mas o que conta como um recurso? Da perspectiva do desenvolvedor, pode ser tentador pensar em um aplicativo inteiro como "crítico", mas a perspectiva do usuário é o que mais importa. Pense nos recursos essenciais como totalmente necessários para oferecer uma experiência do usuário:
- Folhas de estilo globais.
- Arquivos JavaScript que fornecem funcionalidade global.
- HTML do shell do aplicativo, se isso se aplicar à sua arquitetura.
Lembrete: estas são recomendações gerais, não recomendações rígidas. Ao pré-armazenar recursos em cache, é melhor errar fornecendo menos, e não mais.
O que fazer: pré-armazenar em cache um substituto off-line para sites com várias páginas
Em sites comuns com várias páginas, é possível 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 seu service worker armazene previamente em cache e responda com uma página substituta off-line quando o usuário fizer 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, aproveitando também o 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 navegar para uma página que não esteja no cache, ele receberá pelo menos parte do conteúdo off-line.
Sugestão: considere o pré-armazenamento em cache especulativo
Esse é um grande "talvez" mas há um potencial benefício no armazenamento em cache de recursos usados somente em determinadas situações. Pense desta forma: os usuários terão alguns downloads iniciais de dados extras, com o benefício especulativo de acelerar solicitações futuras para esses recursos.
Agora uma grande ressalva: tenha muito cuidado se decidir fazer isso. É fácil desperdiçar dados ao fazer isso, e essa decisão deve ser baseada em dados. Além disso, evite armazenar em cache, especulativamente, recursos que mudam com frequência, já que o usuário terá um uso de dados adicional sempre que o código de pré-armazenamento em cache detectar uma nova revisão. Observe os fluxos de usuários nas análises para saber aonde os usuários tendem a ir. Se você tiver dúvidas sobre o pré-armazenamento em cache especulativo de recursos, esse provavelmente é um bom sinal que não precisa fazer.
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 arquivos HTML discretos são gerados por um gerador de sites estáticos ou criados manualmente, em vez de serem gerados dinamicamente ou fornecidos por um back-end de aplicativo. Se isso descreve sua arquitetura, provavelmente é melhor não pré-armazenar em cache todos os arquivos HTML do site.
Um problema com o pré-armazenamento em cache de arquivos HTML de um site inteiro é que a marcação que é pré-armazenada em cache agora é sempre disponibilizada pelo cache mais tarde, até que o service worker seja atualizado. Isso é ótimo para o desempenho, mas pode causar uma variação significativa no cache se o HTML do site mudar 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, é uma boa ideia pré-armazenar todas essas páginas em cache para que fiquem disponíveis off-line. Se você tiver um site muito grande, considere armazenar em cache de forma especulativa algumas páginas de alto valor e um substituto off-line. Além disso, use o armazenamento em cache no ambiente de execução para armazenar outras páginas em cache.
Não é permitido armazenar em cache imagens ou favicons responsivos
Essa não é uma diretriz geral, mas uma regra. 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 compatibilidade com formatos alternativos. Se você pré-armazenar em cache um conjunto inteiro de imagens responsivas, provavelmente estará armazenando em cache várias imagens quando o usuário acaba fazendo o download de apenas uma delas.
Os favcons apresentam 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 pré-armazenamento em cache de um favicon definido inteiro seja igualmente desnecessário.
Faça um favor aos seus usuários e não armazene em cache conjuntos de favicons e imagens responsivas. Em vez disso, use o armazenamento em cache no ambiente de execução. Se você precisa armazenar imagens em cache, armazene em cache imagens amplamente usadas que não fazem parte de um conjunto de imagens responsivas ou favicons. SVGs são menos arriscados em termos de uso de dados, um único SVG é renderizado de forma ideal, independentemente da densidade de pixels de uma determinada tela.
Não é permitido: pré-armazenar em cache os polyfills
Variar o suporte do navegador para APIs é um desafio constante para desenvolvedores 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 carregar os polyfills apenas nos 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 em cache dos polyfills é arriscado. Alguns usuários se beneficiarão disso, enquanto outros acabarão desperdiçando largura de banda para polyfills desnecessários.
Não armazene polyfills previamente em cache. Confie no armazenamento em cache no ambiente de execução para garantir que eles sejam armazenados em cache somente nos navegadores que exijam isso e evite o desperdício de dados.
Conclusão
O pré-armazenamento em cache requer planejamento prévio sobre quais recursos os usuários realmente precisam. No entanto, é possível fazer tudo certo de uma maneira que prioriza o desempenho e a confiabilidade futuros.
Se você não tiver certeza se determinados recursos precisam ser armazenados previamente em cache, a melhor opção é pedir para o Workbox excluir esses recursos e criar uma rota de armazenamento em cache durante a execução para lidar com eles. De qualquer forma, o armazenamento em cache será abordado em detalhes mais adiante nesta documentação, para que você possa aplicar esses princípios à sua lógica de pré-armazenamento em cache no futuro.