Cache de página, cache de objeto e CDN: qual problema cada camada resolve?

Diagnostique as causas de saltos visuais durante o carregamento de tipografias e implemente estratégias de pré-carregamento com a propriedade font-display.

OTIMIZAÇÃO DE CÓDIGO

10/10/20266 min read

As três camadas atuam em pontos diferentes do caminho de uma requisição. O cache de página tenta reutilizar uma resposta já renderizada, o cache de objeto reaproveita dados ou resultados de operações dentro da aplicação e a CDN mantém cópias em pontos de presença mais próximos dos usuários. Combiná-las pode ser útil, mas não corrige automaticamente a causa de uma lentidão. Também aumenta o número de lugares em que uma resposta pode ficar desatualizada ou ser entregue ao usuário errado.

Onde cada camada entra

O fluxo abaixo é conceitual. Há arquiteturas em que a CDN também faz cache de HTML, o cache de página fica no servidor de origem ou o provedor combina CDN e reverse proxy no mesmo serviço.

mermaid

Código fonte

A ordem real pode variar. Em alguns ambientes, a CDN é o próprio ponto de cache de página; em outros, ela entrega principalmente imagens, folhas de estilo, JavaScript e fontes. O diagrama serve para localizar o tipo de resposta, não para prescrever uma topologia.

Cache de página: reutilizar uma resposta pronta

O cache de página armazena uma resposta HTTP completa — frequentemente o HTML de uma página — para que uma requisição posterior possa recebê-la sem executar novamente todo o WordPress. A documentação do WordPress descreve plugins que guardam posts e páginas como arquivos estáticos e observa que um cache no nível do sistema, como um reverse proxy, pode atuar junto dessa estratégia 1.

Ele ajuda quando muitas pessoas solicitam a mesma resposta e essa resposta pode ser compartilhada com segurança. O benefício potencial é reduzir o trabalho de roteamento, PHP, consultas e renderização no servidor. Não significa que o banco, o tema ou os plugins ficaram mais rápidos: em um cache hit, eles podem simplesmente não ser chamados.

Conteúdo personalizado exige cuidado. Sessões, login, carrinho, cookies relevantes, cabeçalho Authorization e requisições que alteram estado normalmente precisam de bypass ou de uma política específica. A documentação de uma plataforma WordPress, por exemplo, lista usuários logados, sessões PHP e métodos como POST, PUT e DELETE entre situações que não devem passar pelo page cache por padrão 2. Essa é uma regra daquele ambiente, não uma regra universal para todos os hosts.

A invalidação pode ocorrer por expiração, revalidação ou purge explícito. Publicar uma alteração não garante, por si só, que todos os caches existentes conheçam a mudança; o mecanismo precisa saber quais URLs, variantes ou tags devem ser invalidados. Um cache de página mal configurado pode servir HTML antigo, misturar versões de idioma ou dispositivo e, no pior caso, expor conteúdo personalizado a outra pessoa.

Cache de objeto: reaproveitar dados dentro da aplicação

A API WP_Object_Cache do WordPress guarda dados associados a chaves e grupos para evitar viagens repetidas ao banco de dados 3. Em implementações persistentes, o conteúdo pode sobreviver ao fim de uma requisição e ser reutilizado por requisições posteriores. Redis, Memcached, APC e sistema de arquivos são exemplos de mecanismos possíveis; a escolha depende da aplicação e do ambiente 1.

O objeto armazenado pode ser o resultado de uma consulta, uma configuração, um cálculo ou uma resposta externa. O objetivo é reduzir o custo de obter ou produzir esse dado, não entregar necessariamente uma página pronta. Por isso, uma requisição que passa pelo cache de página e chega ao WordPress ainda pode se beneficiar do cache de objeto.

O limite é que o cache só ajuda se o código realmente usar essa camada e se a leitura do cache for mais barata que repetir a operação. Uma implementação de fornecedor alerta que muitas operações de cache pela rede local também podem adicionar latência, e que objetos podem ser expulsos quando o armazenamento fica cheio 4. O cache de objeto não corrige uma consulta mal planejada, um loop ineficiente, uma chamada externa lenta ou um problema de capacidade do banco. Ele pode apenas esconder o custo enquanto há hits.

A invalidação precisa acompanhar a mudança do dado. Apagar ou atualizar uma chave relacionada é diferente de limpar todo o armazenamento; a segunda opção pode elevar temporariamente os misses e a carga no banco. Como o cache deve ser regenerável, sua perda não deveria significar perda dos dados de negócio — a fonte de verdade continua sendo o banco ou outro sistema de origem.

CDN: entregar a partir da rede

Uma CDN é uma rede distribuída de servidores que pode armazenar e entregar recursos a partir de locais próximos dos usuários. Segundo o web.dev, o cache da CDN evita que uma requisição percorra todo o caminho até a origem, enquanto a própria rede pode melhorar a conexão mesmo quando o conteúdo não é armazenável 5.

A CDN é especialmente útil para recursos estáticos, como imagens, CSS, JavaScript, fontes, vídeo e arquivos versionados. Ela também pode armazenar HTML ou JSON, mas isso requer uma política compatível com o conteúdo. A Cloudflare informa, por exemplo, que HTML e JSON não são armazenados por padrão em seu comportamento padrão 6. O Google Cloud CDN também adverte que HTML e JSON costumam ser dinâmicos e que é preciso definir cabeçalhos explicitamente sem colocar dados de um usuário em cache compartilhado 7.

O protocolo HTTP fornece parte dessa política. Cache-Control: max-age define por quanto tempo uma resposta pode ser considerada fresca; s-maxage é voltado a caches compartilhados; private restringe o armazenamento a um cache privado; e no-store instrui que a resposta não seja armazenada 8. A presença de cookies, sozinha, não determina que uma resposta seja privada: é necessário entender o conteúdo e as regras do cache 9.

Quando o objeto expira, a CDN pode revalidá-lo com a origem usando mecanismos como ETag e Last-Modified, ou executar uma invalidação antecipada. A Cloudflare documenta que stale-while-revalidate pode permitir a entrega temporária de conteúdo antigo enquanto uma cópia nova é buscada 10. Isso pode reduzir espera, mas também amplia o intervalo em que uma atualização ainda não aparece.

Comparação prática

Camada

Problema que pode ajudar a reduzir

O que não resolve por si só

Risco de configuração

Verificação e invalidação

Cache de página

Renderização repetida de respostas públicas e carga no servidor

PHP lento, consulta ruim, JavaScript pesado, imagens grandes ou rede do usuário

HTML antigo, variante errada, conteúdo privado compartilhado

Conferir cabeçalhos, hit/miss, URL e variante; expirar, revalidar ou purgar conforme o mecanismo

Cache de objeto

Consultas, cálculos ou chamadas repetidas dentro do WordPress

Código que não usa a API, banco subdimensionado, serviço externo indisponível

Dado desatualizado, chave inadequada, explosão de misses após limpeza

Medir hits, misses, tamanho e tempo; apagar ou atualizar chaves relacionadas

CDN

Latência de entrega, tráfego até a origem e picos de recursos cacheáveis

HTML personalizado, lógica de negócio, erro de origem ou script bloqueante

Cachear resposta privada, TTL inadequado, purge incompleto ou variações excessivas

Inspecionar Cache-Control, Age, ETag, status da CDN e purge; testar de regiões e usuários distintos

Como escolher sem ativar tudo

Considere um site hipotético de notícias com páginas públicas, imagens pesadas e uma área autenticada. A primeira hipótese poderia ser usar cache de página para artigos públicos e CDN para imagens, fontes e arquivos versionados. O cache de objeto pode ser investigado se o HTML ainda exigir consultas repetidas ou chamadas caras. A área autenticada ficaria fora do cache compartilhado, salvo uma arquitetura explicitamente desenhada para dados personalizados.

Esse exemplo não afirma ganho de desempenho. Para verificar a hipótese, compare requisições equivalentes com cache frio e quente, observe o servidor e teste páginas públicas e autenticadas separadamente. Dados de laboratório, como uma execução controlada do Lighthouse, ajudam a reproduzir uma condição; dados de campo representam usuários reais em dispositivos, redes e regiões diferentes. Uma pontuação isolada não identifica qual camada causou o resultado nem mede toda a experiência.

Se o HTML continua rápido, mas o maior elemento visual demora, investigue imagens, CSS, fontes, rede e CDN. Se o tempo até o primeiro byte é alto apenas em cache frio, observe aplicação, banco, PHP e chamadas externas. Se a página chega rápido, mas a interação atrasa, scripts e terceiros podem ser a causa. Cache não deve substituir a análise de tema, plugins, mídia, servidor, banco e rede.

Antes de mudar uma configuração em produção, teste em staging, faça backup verificável e defina como voltar atrás. Altere uma variável por vez quando possível. Documente TTL, regras de bypass, chaves e passos de purge. Depois, valide conteúdo público, login, sessão, carrinho, idioma, dispositivo e permissões. O objetivo não é acumular camadas, mas reduzir uma causa identificada sem servir uma resposta incorreta.

Perguntas de decisão

•A resposta é igual para todos os usuários ou contém sessão, login, cookies ou dados personalizados?

•O custo está em renderizar HTML, buscar dados, transferir arquivos ou estabelecer a conexão?

•O que é a fonte de verdade e como cada cache será invalidado quando ela mudar?

•Como serão medidos hit, miss, conteúdo desatualizado, erro e impacto sobre usuários reais?

•Existe staging, backup testado e reversão documentada antes da alteração?

A documentação do WordPress, do host e da CDN deve prevalecer sobre uma recomendação genérica. A camada correta é a que corresponde ao problema observado e cuja invalidação pode ser compreendida e testada.