--- title: "Page cache vs object cache vs edge cache: qual você precisa" id: "652" type: "post" slug: "page-cache-object-cache-edge-cache-qual-voce-precisa" published_at: "2026-10-06T20:22:46+00:00" modified_at: "2026-10-06T20:22:46+00:00" url: "https://danielpazwp.com/pt/page-cache-object-cache-edge-cache-qual-voce-precisa/" markdown_url: "https://danielpazwp.com/pt/page-cache-object-cache-edge-cache-qual-voce-precisa.md" excerpt: "Page cache, object cache e edge cache resolvem problemas diferentes. O que cada um guarda, quem ganha com ele, os riscos e a ordem certa para adicionar." taxonomy_category: - "Performance" --- [Performance](https://danielpazwp.com/pt/category/performance-pt/) 7 min de leitura # Page cache vs object cache vs edge cache: qual você precisa Page cache, object cache e edge cache resolvem problemas diferentes. O que cada um guarda, quem ganha com ele, os riscos e a ordem certa para adicionar. Publicado **06/10/2026**7 min de leitura [Escrito porDaniel Paz](https://danielpazwp.com/pt/author/daniel-paz/) 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](https://danielpazwp.com/pt/ttfb-no-wordpress/) 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](https://danielpazwp.com/pt/melhor-plugin-de-cache-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](https://danielpazwp.com/pt/redis-object-cache-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](https://danielpazwp.com/pt/como-acelerar-wordpress/) , não o processo inteiro. Se quiser ajuda para definir as camadas certas para o seu caso, veja como trabalho com [performance WordPress](https://danielpazwp.com/pt/performance-wordpress/) . [Trabalhe com o Daniel](https://danielpazwp.com/pt/#book) [Mais em Performance](https://danielpazwp.com/pt/category/performance-pt/) [Sobre o autorPágina do autor](https://danielpazwp.com/pt/author/daniel-paz/) ## Artigos relacionados [Todos os artigos](https://danielpazwp.com/pt/artigos/) [Performance out 2026Core Web Vitals: dados de campo vs laboratório](https://danielpazwp.com/pt/core-web-vitals-dados-de-campo-vs-laboratorio/) [Performance out 2026WordPress lento: os motivos estruturais e a ordem para corrigir](https://danielpazwp.com/pt/por-que-seu-wordpress-e-lento-motivos-estruturais/) [Performance out 2026Autoload do wp_options e otimização do banco de dados do WordPress](https://danielpazwp.com/pt/otimizacao-banco-de-dados-wordpress/)