Na dúvida entre page cache vs object cache, a resposta para a maior parte dos sites WordPress é page cache primeiro, object cache persistente em segundo lugar, e edge cache só quando o público está espalhado por várias regiões ou os picos de tráfego são reais. O page cache guarda o HTML pronto, então PHP e MySQL não rodam para visitantes anônimos. O object cache (Redis ou Memcached) mantém resultados de consultas ao banco na memória entre requisições, o que pesa para usuários logados, carrinho do WooCommerce e telas do admin, que o page cache não atende. O edge cache guarda o HTML numa CDN perto do visitante e corta a latência de rede. Cada um resolve um problema diferente, então a resposta costuma ser uma combinação, adicionada nessa ordem.
Page cache vs object cache vs edge cache: o que cada camada guarda?
As pessoas confundem os três porque todos se chamam “cache” e todos deixam o site mais rápido. Mas eles ficam em pontos diferentes da requisição, e cada um só ajuda as requisições que chegam até ele.
- O page cache guarda a resposta HTML completa de uma URL. O próximo visitante anônimo recebe um arquivo ou uma entrada em memória, e o WordPress nem chega a carregar.
- O object cache guarda pedaços de dados que o WordPress já pediu: resultados de consultas, options, objetos de post, transients. O WordPress continua rodando, mas conversa bem menos com o banco.
- O edge cache guarda o HTML (e os arquivos estáticos) em servidores de CDN pelo mundo, e a resposta nem volta até a sua origem.
O WordPress já vem com um object cache, mas por padrão ele não é persistente: vive durante uma requisição e depois é descartado. Quando alguém fala em “colocar object cache”, está falando de instalar um drop-in (object-cache.php) que liga esse cache ao Redis ou ao Memcached, para os dados sobreviverem entre uma requisição e outra.
| Camada | Onde fica | O que ela pula | Quem ganha | Principal risco |
|---|---|---|---|---|
| Page cache | Disco ou memória do servidor (plugin, Nginx, Varnish) | PHP e MySQL inteiros | Visitantes anônimos | Entregar conteúdo velho ou personalizado |
| Object cache | Redis ou Memcached no servidor | Consultas repetidas ao banco | Usuários logados, WooCommerce, admin, páginas sem cache | Esconder código lento em vez de corrigir |
| Edge cache | Pontos de presença da CDN | A ida até a sua origem | Visitantes longe do servidor, picos de tráfego | Lógica de purge e regras de bypass |
Por que o page cache vem primeiro?
Vejo a mesma cena em auditoria o tempo todo: tempo até o primeiro byte alto, uma lista comprida de plugins de otimização e nenhum page cache funcionando. Ou existe page cache, mas ele é ignorado porque um plugin grava um cookie em toda visita, ou porque uma variação de query string torna cada URL única.
Num site de conteúdo, um page cache funcionando é o maior ganho que dá para ter do lado do servidor. Uma resposta em cache sai em dezenas de milissegundos, contra as centenas que o WordPress leva para inicializar, carregar plugins e rodar consultas. Isso melhora o TTFB diretamente, e o TTFB é o piso do seu Largest Contentful Paint. Se o HTML chega tarde, nada mais na página consegue chegar cedo.
Confirme que está funcionando antes de seguir. Abra uma página numa janela anônima e olhe os cabeçalhos da resposta. A maioria das camadas de cache expõe um cabeçalho que indica hit ou miss. Se só aparece miss, descubra o motivo antes de comprar qualquer outra coisa. Se ainda está escolhendo a ferramenta, comparo as opções em melhor plugin de cache para WordPress.
Quando um object cache persistente compensa?
O page cache tem um limite claro: só funciona para respostas iguais para todo mundo. Usuários logados, áreas de membros, carrinho e checkout do WooCommerce, páginas de conta, o admin e a REST API passam por fora dele, e é assim que deve ser. Essas requisições batem no PHP e no MySQL toda vez.
Aí entra o Redis ou o Memcached. O WordPress carrega options, user meta, relações de termos e dados de posts em toda requisição, e com um object cache persistente a maior parte dessas buscas vem da memória em vez do banco (o passo a passo está em Redis object cache no WordPress). A diferença aparece mais em:
- Lojas WooCommerce, onde carrinho, checkout e minha conta não podem ir para o cache por definição.
- Sites de membros, LMS e comunidades em que a maioria dos usuários está logada.
- Catálogos grandes ou sites com uso pesado do admin, onde os editores sentem a lentidão primeiro.
- Sites com transients caros ou chamadas de API guardadas pela API de transients.
Num site institucional pequeno, em que quase todo visitante é anônimo e o page cache acerta, um object cache persistente acrescenta pouco. Não faz mal, mas é mais um serviço para manter e monitorar.
O object cache barateia consultas repetidas. Ele não transforma uma consulta ruim em boa. Se uma consulta leva dois segundos quando o cache erra, o usuário vai dar de cara com esse erro.
É a armadilha sobre a qual mais alerto clientes. Uma consulta lenta sem cache, uma tabela wp_options inchada com megabytes de dados em autoload ou um plugin que grava no banco a cada visualização de página continuam doendo. Resolva isso antes e deixe o object cache absorver a carga normal.
Você precisa de edge cache ou de CDN para o HTML?
A maioria dos sites já coloca imagens, CSS e JavaScript numa CDN. Guardar o próprio HTML na borda é outro passo. O servidor deixa de participar das visualizações anônimas, e a CDN responde do ponto mais próximo do visitante.
Compensa quando o público está longe do servidor de origem. Se o servidor está em São Paulo e metade dos visitantes está na Europa, toda requisição sem cache paga uma ida e volta pelo Atlântico antes do primeiro byte. O page cache não muda essa distância. O edge cache muda. Ele também protege a origem nos picos de tráfego, porque a CDN absorve as requisições repetidas para a mesma URL.
O preço é complexidade. Você precisa de cabeçalhos Cache-Control corretos, purge ao publicar e atualizar, e regras de bypass para cookies de login, sessões de carrinho e links de pré-visualização. Errar isso significa mostrar o carrinho de um usuário para outro, ou exibir um preço antigo por horas. Edge cache vale a pena quando o page cache e as regras de bypass já estão certos, porque a borda copia o que a origem mandar.
Como decidir no seu site?
Comece por quem são seus visitantes e quais requisições estão lentas, não por uma lista de ferramentas. Este é o caminho de decisão que eu uso:
- Visitantes quase todos anônimos, numa região só: page cache bem configurado e arquivos estáticos na CDN. Pare aí até os dados dizerem outra coisa.
- Visitantes quase todos anônimos, com público global ou tráfego em picos: page cache mais edge cache do HTML, com purge ao publicar.
- WooCommerce, área de membros ou muitos usuários logados: page cache nas páginas públicas mais object cache persistente para tudo que passa por fora dele.
- Loja grande com público internacional: os três, configurados para que cada camada respeite as mesmas regras de bypass.
Qualquer que seja a combinação, meça depois de cada mudança. Acompanhe o TTFB de páginas com e sem cache separadamente, confira a taxa de hit e veja nos dados de campo se o LCP no percentil 75 está indo para 2,5 segundos ou menos. Trate cache como infraestrutura, não como uma caixinha para marcar, e escolha a camada que tira o trabalho que as suas requisições reais mais lentas fazem hoje.
Cache é uma parte da aceleração do WordPress, não o processo inteiro. Se quiser ajuda para definir as camadas certas para o seu caso, veja como trabalho com performance WordPress.