Armazenamento em cache de service worker e armazenamento em cache HTTP

Os prós e contras de usar uma lógica de validade consistente ou diferente nas camadas de cache do service worker e HTTP.

Jonathan Chen

Embora os service workers e os PWAs estejam se tornando padrões de aplicativos da Web modernos, o armazenamento de recursos em cache se tornou mais complexo do que nunca. Este artigo aborda o processo de 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 de diferentes estratégias de validade de armazenamento em cache do service worker em comparação com as estratégias normais de armazenamento em cache HTTP.

Visão geral do fluxo de armazenamento em cache

Em um nível alto, um navegador segue a ordem de armazenamento em cache abaixo quando solicita um recurso:

1. 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: isso não acontece automaticamente. É necessário criar um manipulador de eventos de busca no service worker e interceptar solicitações de rede para que elas sejam veiculadas no cache do service worker em vez da rede.
2. 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 vai usar automaticamente o recurso do cache HTTP.
3. Do lado do servidor:se nada for encontrado no cache do service worker ou no cache HTTP, o navegador vai para a rede para solicitar o recurso. Se o recurso não estiver armazenado em cache em uma CDN, a solicitação precisará voltar ao servidor de origem.

Camadas de armazenamento 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 precisam ser retornados ao navegador. O cache do service worker e o cache HTTP têm o mesmo propósito geral, mas o cache do service worker oferece mais recursos de armazenamento em cache, como controle refinado sobre o que é armazenado em cache e como o armazenamento em cache é 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 "Cache-First".

É altamente recomendável usar o Workbox para evitar reinventar a roda. Por exemplo, é possível registrar caminhos de URL de recursos com uma única linha de código de expressão regular.

import {registerRoute} from 'workbox-routing';

registerRoute(new RegExp('styles/.*\\.css'), callbackHandler);

Estratégias e casos de uso de armazenamento em cache do service worker

A próxima tabela descreve as estratégias comuns de armazenamento em cache do service worker e quando cada estratégia é útil.

Outros benefícios 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 recursos de cache HTTP por origem. Em outras palavras, se você tiver vários subdomínios, eles vão compartilhar o mesmo cache HTTP. Não há garantia de que o conteúdo da sua origem/domínio permaneça no cache HTTP por muito tempo. Por exemplo, um usuário pode limpar o cache limpando manualmente a interface das configurações de um navegador ou acionando uma recarga forçada em uma página. Com um cache do service worker, é muito mais provável que o conteúdo armazenado em cache permaneça armazenado 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 opção binária: o recurso é armazenado em cache ou não. Com o armazenamento em cache do service worker, é possível atenuar pequenos "soluços" com muito mais facilidade (com a estratégia "obsoleto durante a revalidação"), oferecer uma experiência off-line completa (com a estratégia "somente cache") ou até mesmo algo intermediário, como interfaces personalizadas com partes da página do cache do service worker e algumas partes excluídas (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 no cache HTTP. O cache HTTP geralmente é ativado automaticamente pelos navegadores, a menos que tenha sido desativado explicitamente pelo usuário final.

Usar o armazenamento em cache HTTP significa confiar no servidor para determinar quando armazenar um recurso em cache e por quanto tempo.

Controlar a validade do cache HTTP com cabeçalhos de resposta HTTP

Quando um servidor responde a uma solicitação de recurso do navegador, ele usa cabeçalhos de resposta HTTP para informar ao navegador por quanto tempo ele precisa armazenar o recurso em cache. Consulte Cabeçalhos de resposta: configure seu servidor da Web para saber mais.

Estratégias e casos de uso de armazenamento em cache HTTP

O armazenamento em cache HTTP é muito mais simples do que o armazenamento em cache do service worker, porque ele só lida com a lógica de validade de recursos baseada em tempo (TTL). Consulte Quais valores de cabeçalho de resposta você precisa usar? e Evitar solicitações de rede desnecessárias com o cache HTTP (resumo) para saber mais sobre as estratégias de armazenamento em cache HTTP.

Como criar a lógica de validade do cache

Esta seção explica os prós e contras de usar uma lógica de validade consistente nas camadas de cache do service worker e HTTP, bem como os prós e contras de uma lógica de validade separada nessas camadas.

Lógica de validade consistente para todas as camadas de cache

Para demonstrar os prós e contras, vamos analisar três cenários: longo, médio e curto prazo.

Cenário: armazenamento em cache de longo prazo (cache, com fallback para rede)

• Quando um recurso armazenado em cache é válido (<= 30 dias): o service worker retorna o recurso armazenado em cache imediatamente sem acessar a rede.
• Quando um recurso armazenado em cache expira (> 30 dias): o service worker acessa a rede para buscar o recurso. O navegador não tem uma cópia do recurso no cache HTTP, então ele acessa o lado do servidor para o recurso.

Contras: nesse cenário, o armazenamento em cache HTTP oferece menos valor porque o navegador sempre vai 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 (obsoleto durante a revalidação)

• Quando um recurso armazenado em cache é válido (<= 1 dia): o service worker retorna o recurso armazenado em cache imediatamente e acessa a rede para buscar o recurso. O navegador tem uma cópia do recurso no cache HTTP, então ele retorna essa cópia para o service worker.
• Quando um recurso armazenado em cache expira (> 1 dia): o service worker retorna o recurso armazenado em cache imediatamente e acessa a rede para buscar o recurso. O navegador não tem uma cópia do recurso no cache HTTP, então ele acessa o lado do servidor para buscar o recurso.

Contras: o service worker requer mais invalidação de cache 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 armazenado em cache é válido (<= 10 min): o service worker acessa a rede para buscar o recurso. O navegador tem uma cópia do recurso no cache HTTP, então ele a retorna para o service worker sem acessar o lado do servidor.
• Quando um recurso armazenado em cache expira (> 10 min): o service worker retorna o recurso armazenado em cache imediatamente e acessa a rede para buscar o recurso. O navegador não tem uma cópia do recurso no cache HTTP, então ele acessa o lado do servidor para buscar o recurso.

Contras: semelhante ao cenário de armazenamento em cache de médio prazo, o service worker requer mais lógica de cache busting 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.

Lógica de validade de cache diferente no cache do service worker e nas camadas HTTP

Para demonstrar os prós e contras, vamos analisar novamente cenários de longo, médio e curto prazo.

Cenário: armazenamento em cache de longo prazo (cache, com fallback para rede)

• Quando um recurso armazenado em cache é válido no cache do service worker (<= 90 dias): o service worker retorna o recurso armazenado em cache imediatamente.
• Quando um recurso armazenado 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, então ele acessa o lado do servidor.

Prós e contras:

• Prós: os usuários têm uma resposta instantânea, já que o service worker retorna recursos armazenados em cache imediatamente.
• Prós: o service worker tem um controle mais refinado de quando usar o cache e quando solicitar novas versões de recursos.
• Contras: é necessária uma estratégia de armazenamento em cache do service worker bem definida.

Cenário: armazenamento em cache de médio prazo (obsoleto durante a revalidação)

• Quando um recurso armazenado em cache é válido no cache do service worker (<= 30 dias): o service worker retorna o recurso armazenado em cache imediatamente.
• Quando um recurso armazenado 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 no cache HTTP, então ele acessa o lado do servidor.

Prós e contras:

• Prós: os usuários têm uma resposta instantânea, já que o service worker retorna recursos armazenados em cache imediatamente.
• Prós: o service worker pode garantir que a próxima solicitação de um determinado URL use uma resposta atualizada da rede, graças à revalidação que acontece "em segundo plano".
• Contras: é necessária uma estratégia de armazenamento em cache do service worker bem definida.

Cenário: armazenamento em cache de curto prazo (rede com fallback para cache)

• Quando um recurso armazenado em cache é válido no cache do service worker (<= 1 dia): o service worker acessa a rede para o recurso. O navegador retorna o recurso do cache HTTP se ele estiver lá. Se a rede estiver inativa, o service worker vai retornar o recurso do cache do service worker.
• Quando um recurso armazenado 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 na rede, já que a versão armazenada em cache no cache HTTP expirou.

Prós e contras:

• Prós: quando a rede está instável ou inativa, o service worker retorna recursos armazenados em cache imediatamente.
• Contras: o service worker requer mais invalidação de cache para substituir o cache HTTP e fazer solicitações "Network first".

Conclusão

Devido à complexidade da combinação de cenários de armazenamento em cache, não é possível criar uma regra que abranja todos os casos. No entanto, com base nas descobertas das seções anteriores, há algumas sugestões a serem consideradas ao criar suas estratégias de armazenamento em cache:

• A lógica de armazenamento em cache do service worker não precisa ser consistente com a lógica de validade do armazenamento em cache HTTP. Se possível, use uma lógica de validade mais longa no service worker para conceder mais controle ao service worker.
• O armazenamento em cache HTTP ainda desempenha um papel importante, mas não é confiável quando a rede está instável ou inativa.
• Revise suas estratégias de armazenamento em cache para cada recurso para garantir que a estratégia de armazenamento em cache do service worker forneça valor sem entrar em conflito com o cache HTTP.

Saiba mais

• Confiabilidade da rede
• Evitar solicitações de rede desnecessárias com o cache HTTP
• Codlab de cache HTTP
• Como medir o impacto real de performance dos service workers
• Cache-Control x Expires
• Armazenamento em cache sem mistério: inspecionar, limpar e desativar caches