Os prós e contras de usar uma lógica de expiração consistente ou diferente nas camadas de cache do service worker e do HTTP.
Enquanto os service workers e PWAs estão se tornando os padrões dos aplicativos da Web modernos, o armazenamento em cache de recursos ficou mais complexa do que nunca. Este artigo aborda o panorama geral do armazenamento em cache do navegador, incluindo:
- Os casos de uso e as diferenças entre o armazenamento em cache do service worker e o armazenamento em cache HTTP.
- Os prós e contras das diferentes estratégias de expiração de armazenamento em cache dos service workers em comparação com as Estratégias de armazenamento em cache HTTP.
Visão geral do fluxo de armazenamento em cache
De modo geral, um navegador segue a ordem de armazenamento em cache abaixo quando solicita um recurso:
- Cache do service worker: o service worker verifica se o recurso está no cache e decide se vai retornar o recurso com base nas estratégias de armazenamento em cache programadas. Observação para que isso não aconteça automaticamente. É necessário criar um manipulador de eventos de busca no seu service worker e interceptar as solicitações de rede para que elas sejam atendidas pelo cache do service worker em vez da rede.
- Cache HTTP (também conhecido como cache do navegador): se o recurso for encontrado no cache HTTP e ainda não tiver expirado, o navegador usará automaticamente o recurso do cache HTTP.
- Lado do servidor: se nada for encontrado no cache do service worker ou no cache HTTP, o navegador vai até a rede para solicitar o recurso. Se o recurso não estiver armazenado em cache em um CDN, a solicitação precisará voltar ao servidor de origem.
Armazenamento em cache de camadas
Armazenamento em cache do service worker
Um service worker intercepta solicitações HTTP do tipo rede e usa uma estratégia de armazenamento em cache para determinar quais recursos devem ser retornados ao navegador. O cache do service worker e o cache HTTP servem para o mesmo propósito geral, mas o cache do service worker oferece mais recursos de armazenamento em cache, como controle detalhado sobre exatamente o que é armazenado em cache e como o armazenamento é feito.
Como controlar o cache do service worker
Um service worker intercepta solicitações HTTP com listeners
de eventos (geralmente o evento fetch). Este
snippet de código demonstra a lógica de uma
estratégia de armazenamento em cache
primeiro o cache.
É altamente recomendável usar o Workbox para evitar reinventando a roda. Por exemplo, é possível registrar caminhos de URL de recursos com uma única linha de código regex.
import {registerRoute} from 'workbox-routing';
registerRoute(new RegExp('styles/.*\\.css'), callbackHandler);
Casos de uso e estratégias de armazenamento em cache de service workers
A tabela a seguir descreve estratégias comuns de armazenamento em cache de service workers e quando cada uma delas é útil.
| Estratégias | Motivo da atualização | Casos de uso |
|---|---|---|
| Somente de rede | O conteúdo precisa estar sempre atualizado. |
|
| Rede usando o cache | É preferível exibir o conteúdo mais recente. No entanto, se a rede falhar ou estiver instável, aceitáveis para veicular conteúdo um pouco antigo. |
|
| Descontinuado enquanto revalidar | Não há problema em veicular conteúdo em cache imediatamente, mas o conteúdo atualizado em cache deve ser usado na seção futuro. |
|
| Armazenar o cache primeiro, depois voltar para a rede | O conteúdo não é crítico e pode ser veiculado a partir do cache para ganhos de desempenho, mas a o service worker deve verificar ocasionalmente se há atualizações. |
|
| Somente cache | O conteúdo raramente muda. |
|
Benefícios adicionais do armazenamento em cache do service worker
Além do controle refinado da lógica de armazenamento em cache, o armazenamento em cache do service worker também oferece:
- Mais memória e espaço de armazenamento para sua origem:o navegador aloca cache HTTP. recursos por origem. Em outras palavras, se você tiver vários subdomínios, todos eles compartilharão o mesmo cache HTTP. Não há garantir que o conteúdo da sua origem/domínio permaneça no cache HTTP por um longo tempo. Para exemplo, um usuário pode limpar o cache fazendo a limpeza manual na IU de configurações do navegador ou acionando uma atualização forçada em uma página. Com um cache de service worker, é muito mais provável que o conteúdo armazenado em cache permaneça em cache. Consulte Armazenamento persistente para saber mais.
- Maior flexibilidade com redes instáveis ou experiências off-line: com o cache HTTP, você só tem uma escolha binária: o recurso é armazenado em cache ou não. Com o armazenamento em cache de worker de serviço, é possível mitigar pequenos "problemas" com mais facilidade (com a estratégia "stale-while-revalidate"), oferecer uma experiência off-line completa (com a estratégia "Cache only") ou até mesmo algo intermediário, como interfaces personalizadas com partes da página provenientes do cache do worker de serviço e algumas partes excluídas (com a estratégia "Set catch handler") quando apropriado.
Armazenamento em cache HTTP
Na primeira vez que um navegador carrega uma página da web e recursos relacionados, ele armazena esses recursos em sua cache HTTP. O cache HTTP é geralmente ativado automaticamente por navegadores, a menos que tenha sido explicitamente desativada pelo usuário final.
Usar o armazenamento em cache HTTP significa depender do servidor para determinar quando armazenar um recurso em cache e por quanto tempo.
Controlar a expiração do cache HTTP com cabeçalhos de resposta HTTP
Quando um servidor responde a uma solicitação do navegador por um recurso, o servidor usa cabeçalhos de resposta HTTP para informar ao navegador por quanto tempo ele deve armazenar o recurso em cache. Consulte Cabeçalhos de resposta: configure seu servidor da Web para saber mais.
Casos de uso e estratégias de armazenamento em cache HTTP
O armazenamento em cache HTTP é muito mais simples do que o cache do service worker, porque o cache HTTP lida apenas com lógica de expiração de recursos baseada em tempo (TTL). Consulte Quais valores de cabeçalho de resposta você deve usar? e Resumo para saber mais sobre as estratégias de armazenamento em cache HTTP.
Projetar a lógica de expiração do cache
Esta seção explica os prós e contras de usar uma lógica de expiração consistente no service worker camadas de cache e de cache HTTP, bem como os prós e contras de uma lógica de expiração separada entre camadas.
O Glitch abaixo demonstra como o armazenamento em cache de service worker e o armazenamento em cache HTTP funcionam em diferentes cenários:
Lógica de expiração consistente para todas as camadas de cache
Para demonstrar os prós e contras, vamos analisar três cenários: longo prazo, médio e em curto prazo.
| Cenários | Armazenamento em cache de longo prazo | Armazenamento em cache de médio prazo | Armazenamento em cache de curto prazo |
|---|---|---|---|
| Estratégia de armazenamento em cache do service worker | Cache, fallback para rede | obsoleto durante a revalidação | Rede com fallback para cache |
| TTL do cache do service worker | 30 dias | 1 dia | 10 min |
| Cache HTTP max-age | 30 dias | 1 dia | 10 min |
Cenário: cache a longo prazo (cache, fallback para rede)
- Quando um recurso em cache é válido (<= 30 dias): o service worker retorna o recurso em cache imediatamente sem acessar a rede.
- Quando um recurso em cache expirar (> 30 dias): o worker de serviço vai para a rede para buscar o recurso. O navegador não tem uma cópia do recurso no cache HTTP. Por isso, ele vai para o lado do servidor.
Desvantagem: neste cenário, o armazenamento em cache HTTP fornece menos valor porque o navegador sempre transmitir a solicitação para o lado do servidor quando o cache expirar no service worker;
Cenário: armazenamento em cache de médio prazo (Stale-while-revalidate)
- Quando um recurso armazenado em cache for válido (<= 1 dia): o service worker retornará o imediatamente e vai até a rede para buscá-lo. O navegador tem uma cópia o recurso em seu cache HTTP, para que ele retorne essa cópia ao service worker.
- Quando um recurso armazenado em cache expirar (> 1 dia): o service worker retornará o e vai até a rede para buscá-lo. O navegador não tem uma cópia do recurso no cache HTTP, então ele vai do lado do servidor para buscá-lo.
Contra: o service worker exige uma quebra de cache adicional para substituir o cache HTTP e aproveitar ao máximo a etapa de "revalidação".
Cenário: armazenamento em cache de curto prazo (rede com fallback para cache)
- Quando um recurso em cache é válido (<= 10 minutos): o service worker acessa a rede para buscar o recurso. O navegador tem uma cópia do recurso no cache HTTP, que é retornada ao service worker sem ir para o lado do servidor.
- Quando um recurso armazenado em cache expirar (> 10 minutos): o service worker retornará o imediatamente e vai até a rede para buscá-lo. O navegador não tem uma cópia do recurso no cache HTTP. Por isso, ele vai para o lado do servidor para buscar o recurso.
Desvantagem: semelhante ao cenário de armazenamento em cache de médio prazo, o service worker exige uma lógica adicional de quebra de cache para substituir o cache HTTP e buscar o recurso mais recente do lado do servidor.
Service worker em todos os cenários
Em todos os cenários, o cache do service worker ainda pode retornar recursos armazenados em cache quando a rede está instável. Por outro lado, o cache HTTP não é confiável quando a rede está instável ou inativa.
Diferentes lógicas de expiração do cache nas camadas do worker de serviço e HTTP
Para demonstrar os prós e os contras, veremos novamente as estratégias de longo, médio e curto prazo diferentes.
| Cenários | Armazenamento em cache de longo prazo | Armazenamento em cache de médio prazo | Armazenamento em cache de curto prazo |
|---|---|---|---|
| Estratégia de armazenamento em cache do service worker | Cache, fallback para rede | obsoleto durante a revalidação | Rede com fallback para cache |
| TTL de cache do service worker | 90 dias | 30 dias | 1 dia |
| Idade máxima do cache HTTP | 30 dias | 1 dia | 10 min |
Cenário: cache a longo prazo (cache, fallback para rede)
- Quando um recurso armazenado em cache for válido no cache do service worker (<= 90 dias): o serviço worker retorna imediatamente o recurso armazenado em cache.
- Quando um recurso em cache expira no cache do service worker (> 90 dias): o service worker acessa a rede para buscar o recurso. O navegador não tem uma cópia do recurso no cache HTTP. Por isso, ele vai para o lado do servidor.
Prós e contras:
- Prós: os usuários têm uma resposta instantânea, porque o service worker retorna os recursos armazenados em cache imediatamente.
- Vantagem: o service worker tem um controle mais refinado sobre quando usar o cache e quando solicitar novas versões de recursos.
- Desvantagem: é necessário ter uma estratégia de armazenamento em cache do service worker bem definida.
Cenário: armazenamento em cache durante a vigência (Stale-while-revalidate)
- Quando um recurso em cache é válido no cache do service worker (<= 30 dias): o service worker retorna o recurso em cache imediatamente.
- Quando um recurso em cache expira no cache do service worker (> 30 dias): o service worker acessa a rede para o recurso. O navegador não tem uma cópia do recurso em cache HTTP, ou seja, ele vai para o lado do servidor.
Prós e contras:
- Pró: os usuários recebem respostas instantâneas enquanto o service worker retorna recursos armazenados em cache imediatamente.
- Vantagem: o worker de serviço pode garantir que a solicitação seguinte de um determinado URL use uma resposta nova da rede, graças à revalidação que acontece "em segundo plano".
- Desvantagem: é necessário ter uma estratégia de armazenamento em cache bem definida do service worker.
Cenário: armazenamento em cache de curto prazo (rede com retorno ao cache)
- Quando um recurso armazenado em cache for válido no cache do service worker (<= 1 dia): o serviço worker vai até a rede em busca do recurso. O navegador retorna o recurso da solicitação no cache, se houver. Se a rede estiver inativa, o service worker vai retornar o recurso do cache do service worker.
- Quando um recurso em cache expira no cache do service worker (> 1 dia): o service worker acessa a rede para buscar o recurso. O navegador busca os recursos pela rede, porque a versão em cache no cache HTTP expirou.
Prós e contras:
- Pró: quando a rede está instável ou inativa, o service worker retorna o cache os recursos imediatamente.
- Desvantagem: o service worker requer impedimento de cache adicional para substituir o cache HTTP e colocar a rede em primeiro lugar solicitações.
Conclusão
Dada a complexidade da combinação dos cenários de armazenamento em cache, não é possível criar uma regra que abrange todos os casos. No entanto, com base nas descobertas das seções anteriores, algumas sugestões que devem ser consideradas ao projetar suas estratégias de cache:
- A lógica de armazenamento em cache do service worker não precisa ser consistente com a expiração do armazenamento em cache HTTP lógica. Se possível, use uma lógica de expiração mais longa no service worker para conceder mais controle a ele.
- O cache HTTP ainda desempenha um papel importante, mas não é confiável quando a rede é instável ou desacelerado.
- Revise suas estratégias de armazenamento em cache para cada recurso para garantir que o service worker armazene em cache estratégia fornece seu valor, sem entrar em conflito com o cache HTTP.