Cache no Browser: HTTP Cache, Memory Cache e Service Worker

O problema

Quando um recurso vem mais rápido na segunda visita, muita gente resume tudo assim:

“veio do cache do browser”

Só que isso ainda esta genérico demais.

Porque “cache do browser” pode significar coisas bem diferentes:

• regra de HTTP cache
• recurso ainda vivo em memória
• resposta controlada por service worker

Se você mistura tudo, fica difícil entender por que o dado veio velho, por que a rede nem foi usada ou por que um asset continua aparecendo depois do deploy.

Modelo mental

Pense em tres mecanismos diferentes.

HTTP cache

Segue semântica de protocolo.

O servidor manda instrucoes com headers e o navegador decide se pode reutilizar, revalidar ou buscar de novo.

Memory cache

E reaproveitamento em memória de recursos recentes dentro do contexto da navegação atual.

Não e um contrato explícito com o servidor no mesmo nivel do HTTP cache. E um atalho do navegador quando ele ainda tem aquilo pronto.

Service worker

E uma camada programavel.

Ela pode interceptar requests e responder com estratégia própria:

• cache first
• network first
• stale while revalidate

Aqui você saiu do comportamento automático puro do navegador e entrou em lógica de aplicação.

Quebrando o problema

Como HTTP cache funciona de forma prática

HTTP cache responde mais ou menos assim:

• posso usar a resposta que já tenho?
• preciso validar com o servidor?
• preciso baixar tudo de novo?

Headers comuns entram aqui:

• Cache-Control
• ETag
• Last-Modified
• Expires

Esse e o cache mais “oficial” da conversa web.

O que e memory cache na prática

Memory cache costuma aparecer quando o navegador já tem recurso recente e consegue reaproveitar muito rápido.

Exemplos comuns:

• voltar para uma tela que usa o mesmo CSS
• navegar em app que reutiliza recursos da mesma sessao

O ponto importante e que esse comportamento pode ser mais oportunista e menos controlavel por você do que o HTTP cache.

Onde service worker muda o jogo

Service worker pode:

• responder offline
• guardar assets estrategicamente
• decidir quando servir do cache e quando ir para rede

Isso e poderoso, mas cobra responsabilidade.

Porque agora “veio do cache” pode significar uma decisão que você mesmo programou.

Exemplo simples

Imagine um app que tem:

• CSS e JS com hash no nome
• imagens de produto
• endpoint /api/profile
• PWA com service worker

Um desenho razoavel pode ser:

• assets versionados com cache agressivo
• HTML com cache mais curto ou revalidacao
• dados de perfil revalidados com mais frequência
• estratégia offline controlada por service worker para partes especificas

Se o time trata tudo igual, os problemas aparecem:

• HTML velho servindo referência errada
• dado da API stale demais
• deploy novo sem invalidação correta
• debug confuso porque ninguém sabe qual camada respondeu

Erros comuns

• Achar que service worker e só “mais um cache HTTP”.
• Colocar cache agressivo em HTML como se fosse igual a asset com hash.
• Chamar qualquer resposta reaproveitada de memory cache sem verificar.
• Configurar cache sem pensar em invalidação.
• Usar service worker sem observabilidade mínima e depois culpar o browser.

Como um senior pensa

Quem já sofreu com asset velho em produção costuma separar as perguntas cedo.

Algo como:

“Essa resposta veio por regra de HTTP, por reaproveitamento em memória ou por interceptacao do service worker?”

Essa separação melhora muito o diagnostico.

Porque cada camada tem alavancas e bugs diferentes.

O que o entrevistador quer ver

Em entrevista, o mais forte não e recitar header.

E mostrar que você entende que browser cache não e uma entidade unica.

Sinaliza maturidade quando você:

• diferencia HTTP cache, memory cache e service worker
• conecta cada camada ao tipo de recurso
• fala de invalidação e staleness
• evita prometer offline ou performance sem citar custo operacional

Uma resposta forte costuma soar assim:

“Eu separo cache automático de protocolo, reaproveitamento oportunista do navegador e cache programavel com service worker. Sem essa separação, a conversa sobre performance e invalidação fica confusa rápido demais.”

Cache bom não e o que reaproveita tudo. E o que reaproveita o que pode sem mentir demais para o usuário.