Os prós e contras do uso de uma lógica de expiração consistente ou diferente nas camadas de cache do service worker e do cache HTTP.
Embora os service workers e PWAs estejam se tornando padrões de 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 do 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 dele e decide se deve retornar o próprio recurso com base em suas estratégias de armazenamento em cache programadas. Observação que isso não aconteça automaticamente. Você precisa criar um manipulador de eventos de busca service worker e intercepte as solicitações de rede para que elas sejam disponibilizadas pelo serviço cache do worker em vez da rede.
- Cache HTTP (também conhecido como cache do navegador): se o recurso for encontrado no HTTP cache 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 uma CDN, a solicitação deve ir até o servidor de origem.
Como armazenar camadas em cache
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 o cache serve para a mesma finalidade geral, mas o cache do service worker oferece mais recursos de cache, como um controle refinado sobre o que é armazenado em cache e como é feito.
Como controlar o cache do service worker
Um Service Worker intercepta solicitações HTTP com event
listeners (geralmente o evento fetch). Isso
snippet de código demonstra a lógica de uma
Priorização do cache
estratégia de armazenamento em 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);
Estratégias de armazenamento em cache do service worker e casos de uso
A próxima tabela descreve as estratégias comuns de armazenamento em cache do service worker e quando cada uma delas é útil.
| Estratégias | Justificativa de atualização | Casos de uso |
|---|---|---|
| Rede somente | O conteúdo precisa estar sempre atualizado. |
|
| Rede usando o cache | É preferível veicular o conteúdo novo. No entanto, se a rede falhar ou estiver instável, adequados 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, você tem um tempo probabilidade de o conteúdo permanecer armazenado em cache. Consulte Persistent Storage para saber mais.
- Maior flexibilidade com redes instáveis ou experiências off-line:com o cache HTTP, você têm apenas uma escolha binária: se o recurso é armazenado em cache ou não. Com armazenamento em cache do service worker você pode reduzir pequenos "contratempos" muito mais fácil (com a estratégia "descontinuar enquanto revalidar"), oferecem uma experiência off-line completa (com a estratégia "Somente cache") ou até mesmo algo no como IUs personalizadas com partes da página provenientes do cache do service worker e excluir algumas partes (com a estratégia "Definir gerenciador de captura") 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. Em geral, o cache HTTP é ativado automaticamente por navegadores, a menos que tenha sido explicitamente desativada pelo usuário final.
Usar o armazenamento em cache HTTP significa confiar no servidor para determinar quando armazenar um recurso em cache e como de comprimento.
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: configurar a servidor para saber mais.
Estratégias de armazenamento em cache HTTP e casos de uso
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 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 do service worker e o armazenamento em cache HTTP funcionam em ação 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, com retorno à rede | obsoleto durante a revalidação | Rede com retorno ao cache |
| TTL do cache do service worker | 30 dias | 1 dia | 10 min |
| Idade máxima do cache HTTP | 30 dias | 1 dia | 10 min |
Cenário: armazenamento em cache de longo prazo (cache, com fallback para rede)
- Quando um recurso armazenado em cache for válido (<= 30 dias): o service worker retornará o recurso imediatamente sem acessar a rede.
- Quando um recurso armazenado em cache expirar (> 30 dias): o service worker vai para a rede para buscar o recurso. O navegador não tem uma cópia do recurso em seu cache HTTP, por isso vai para o lado do servidor para o recurso.
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 imediatamente e vai até a rede para buscá-lo. O navegador não tem cópia do recurso em seu cache HTTP, para que ele vá do lado do servidor para buscar o recurso.
Desvantagem: o service worker requer impedimento de cache adicional para substituir o cache HTTP em para aproveitar ao máximo a "revalidação" etapa.
Cenário: armazenamento em cache de curto prazo (rede com retorno ao cache)
- Quando um recurso armazenado em cache for válido (<= 10 min): o service worker vai para a rede para buscar o recurso. O navegador tem uma cópia do recurso em seu cache HTTP, para que ele retorne isso ao service worker sem ficar no 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 cópia do recurso em seu cache HTTP, para que ele vá do lado do servidor para buscar o recurso.
Desvantagem: semelhante ao cenário de armazenamento em cache de médio prazo, o service worker requer a lógica de impedimento de cache para substituir o cache HTTP a fim de buscar o recurso mais recente da 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.
Uma lógica diferente de expiração de cache nas camadas HTTP e no cache do service worker
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, com retorno à rede | obsoleto durante a revalidação | Rede com retorno ao cache |
| TTL do cache do service worker | 90 dias | 30 dias | 1 dia |
| Idade máxima do cache HTTP | 30 dias | 1 dia | 10 min |
Cenário: armazenamento em cache de longo prazo (cache, com 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 serviço o worker vai até a rede para buscar o recurso. O navegador não tem uma cópia do recurso no cache HTTP, para que ele seja enviado 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.
- Pró: o service worker tem um controle mais preciso sobre quando usar o cache para solicitar novas versões de recursos.
- Desvantagem: é necessário ter uma estratégia de armazenamento em cache bem definida do service worker.
Cenário: armazenamento em cache durante a vigência (Stale-while-revalidate)
- Quando um recurso armazenado em cache for válido no cache do service worker (<= 30 dias): o serviço worker retorna imediatamente o recurso armazenado em cache.
- Quando um recurso em cache expira no cache do service worker (> 30 dias): o serviço worker vai até a rede em busca do 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.
- Pró: o service worker pode garantir que a próxima solicitação para um determinado URL use uma uma nova resposta da rede, graças à revalidação que ocorre "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 retornará o recurso da cache do service worker
- Quando um recurso armazenado em cache expirar no cache do service worker (> 1 dia): o serviço o worker vai até 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 a ele ter mais controle.
- 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.