Cache no WordPress: As Camadas que Aceleram (e Como Não Servir Página Velha)

Se existe um único ajuste que transforma um WordPress lento num WordPress rápido, é cache. Nenhuma outra otimização chega perto do ganho de simplesmente parar de refazer o mesmo trabalho a cada visita. O problema é que "cache" não é uma coisa só — é uma pilha de camadas diferentes, cada uma resolvendo um gargalo específico, e a maioria dos tutoriais joga tudo no mesmo balde chamado "instale um plugin de cache". Instalar o plugin ajuda, mas se você não entende o que ele faz e o que ele não faz, acaba com dois problemas clássicos: ou o site continua lento porque a camada errada não foi ativada, ou o site passa a mostrar conteúdo velho para os visitantes.

Para entender por que cache importa tanto, vale lembrar como o WordPress monta uma página. A cada visita, ele roda código PHP, consulta o banco de dados várias vezes, junta tudo num HTML e entrega. Isso acontece de novo para cada visitante, mesmo que a página seja exatamente igual para todos. Cache é a arte de guardar o resultado desse trabalho e reentregá-lo pronto, pulando o esforço. Este guia percorre as camadas de cache de um WordPress — da mais externa à mais interna —, explica o que cada uma acelera e, principalmente, mostra o outro lado da moeda: a invalidação, ou seja, como garantir que ninguém veja a versão desatualizada.

Por que cache é o maior ganho de performance

Montar uma página no WordPress é caro em termos de processamento. O PHP precisa carregar, o tema e os plugins entram em ação, o banco de dados responde a dezenas de consultas, e só então o HTML fica pronto. Numa página que não muda entre uma visita e outra, refazer tudo isso é desperdício puro. Cache elimina esse desperdício guardando o resultado e servindo a cópia.

A diferença é brutal. Uma página gerada "do zero" pode levar centenas de milissegundos de processamento no servidor; a mesma página servida do cache sai em poucos milissegundos, porque é só entregar um arquivo pronto. Isso não melhora só a velocidade percebida pelo visitante — reduz drasticamente a carga no servidor, o que significa aguentar muito mais tráfego com o mesmo plano. É por isso que cache é sempre o primeiro item de qualquer conversa séria sobre performance de WordPress.

• Menos trabalho por visita. Em vez de reconstruir a página, o servidor devolve uma cópia salva.
• Mais tráfego no mesmo hardware. Servir cache consome uma fração dos recursos de gerar a página, então o mesmo plano aguenta picos muito maiores.
• Resposta mais rápida. Menos processamento significa menos tempo até o primeiro byte e páginas que aparecem antes.

Cache de página (full-page): o de maior impacto

A camada com o maior retorno é o cache de página, também chamado de full-page cache. A ideia é simples e poderosa: na primeira visita, o WordPress monta a página normalmente; o mecanismo de cache então salva o HTML completo já pronto e, nas próximas visitas, entrega esse HTML direto, sem tocar em PHP nem no banco. É como fotografar a página montada e mostrar a foto para os próximos visitantes.

No mundo WordPress, isso costuma vir de plugins como WP Super Cache, W3 Total Cache ou LiteSpeed Cache, ou de um cache no próprio servidor. O ganho é enorme porque pula a parte mais cara do processo inteiro. Mas é também a camada que mais exige cuidado com invalidação, porque ela congela a página — e nem toda página pode ser congelada.

• Guarda o HTML inteiro. A entrega vira quase estática, rápida como servir um arquivo.
• Pula PHP e banco. O maior custo de montar a página some para os visitantes seguintes.
• Precisa de exceções. Páginas que mudam por usuário (carrinho, checkout, área logada) não podem ser servidas do cache cheio — mais sobre isso adiante.

Cache de objeto: aliviando o banco de dados

Nem tudo pode virar página estática. Um site com muita interação — busca, filtros, área de membros — refaz consultas ao banco o tempo todo. É aqui que entra o cache de objeto persistente, usando Redis ou Memcached. Em vez de guardar a página inteira, ele guarda os resultados das consultas ao banco na memória. Quando o WordPress precisa da mesma informação de novo, pega da memória em vez de perguntar ao banco outra vez.

O WordPress já tem um cache de objeto interno, mas por padrão ele dura só o tempo de uma requisição — some quando a página termina de carregar. Ligar um cache de objeto persistente (Redis/Memcached) faz esses resultados sobreviverem entre requisições e entre visitantes. Para sites dinâmicos, com muita lógica que o cache de página não cobre, essa camada é o que mantém o banco de dados respirando sob carga.

• Guarda resultados de query, não HTML. Complementa o cache de página onde ele não alcança.
• Vive na memória (RAM). Redis e Memcached respondem em microssegundos, muito mais rápido que uma ida ao disco do banco.
• Ganho maior em sites dinâmicos. Lojas, comunidades e sites com busca pesada sentem mais essa camada do que um blog simples.

OPcache: o PHP que não recompila à toa

Uma camada silenciosa, quase sempre esquecida, é o OPcache. Toda vez que o PHP roda, ele precisa transformar o código-fonte em algo que o processador executa (bytecode). Sem OPcache, essa compilação acontece a cada requisição. O OPcache guarda o bytecode já compilado na memória, então o PHP pula direto para a execução. É um ganho de base que se aplica a todo o site, não só às páginas cacheadas.

O bom é que o OPcache é configuração de servidor, não de plugin — em muitos ambientes ele já vem ligado. Vale confirmar com a hospedagem se está ativo, porque é dos ajustes de melhor custo-benefício: nenhum trabalho de conteúdo, ganho em tudo.

• Cacheia o código compilado, não os dados. Acelera a execução do PHP em si.
• Aplica-se ao site inteiro. Beneficia até requisições que não passam pelo cache de página.
• É coisa de servidor. Geralmente já ativo em bons ambientes; se não estiver, peça para ligar.

Cache de navegador e de CDN: guardando fora do servidor

As camadas anteriores vivem no seu servidor. Duas outras empurram o cache para fora dele, mais perto do visitante. O cache de navegador instrui o navegador do usuário a guardar arquivos que não mudam — imagens, CSS, JavaScript, fontes — no próprio computador dele, via cabeçalhos HTTP como Cache-Control e Expires. Na segunda visita, esses arquivos não são baixados de novo: o navegador usa a cópia local. Isso torna a navegação subsequente quase instantânea para quem volta.

O cache de CDN/edge vai além: distribui cópias dos seus arquivos (e às vezes de páginas inteiras) por servidores espalhados pelo mundo, entregando ao visitante a partir do ponto mais próximo dele geograficamente. Um leitor em Lisboa recebe do nó europeu; um em São Paulo, do nó brasileiro. Isso ataca a latência, que nenhum cache no servidor de origem resolve sozinho.

• Cache de navegador: define, via cabeçalhos, quanto tempo o navegador pode reutilizar cada arquivo estático sem rebaixá-lo do servidor.
• Cache de CDN: aproxima geograficamente os arquivos do visitante, reduzindo a distância física que os dados percorrem.
• Combinam com as camadas internas. Navegador e CDN cuidam do que está longe; página, objeto e OPcache cuidam do que acontece no servidor.

Fragmentos e transients: cache dentro do próprio WordPress

Há ainda uma camada fina e útil dentro do próprio WordPress: os transients. São uma forma de o WordPress (e os plugins) guardarem pedaços de resultado por um tempo definido — por exemplo, o retorno de uma API externa, uma lista de posts populares, um menu que muda pouco. Em vez de recalcular ou refazer a chamada externa a cada carregamento, o transient serve o valor salvo até expirar. Bem usado com um cache de objeto persistente por baixo, é o que evita que uma integração lenta trave todas as páginas.

O outro lado: invalidação, ou como não servir página velha

Toda a graça do cache — servir a cópia salva — é também o seu maior risco. Se você guarda o HTML e o conteúdo muda, os visitantes veem a versão antiga até o cache expirar ou ser limpo. Isso é a invalidação de cache, e é reconhecidamente uma das coisas mais difíceis de acertar. O objetivo é entregar sempre a cópia rápida e sempre a cópia correta, e essas duas metas puxam em direções opostas.

• Conteúdo dinâmico não pode ser cacheado cheio. Carrinho de compras, checkout, painéis de conta e qualquer página que muda por usuário logado precisam ficar fora do cache de página — senão um visitante vê o carrinho de outro.
• Cookies são o sinal de "não cachear". Bons mecanismos de cache detectam cookies de sessão/login e servem a versão dinâmica para quem está logado, mantendo o cache cheio só para visitantes anônimos.
• Purga no evento certo. Ao publicar ou editar um post, o mecanismo de cache deve limpar (purgar) as páginas afetadas automaticamente, para que a mudança apareça na hora, não daqui a horas.
• Expiração como rede de segurança. Além da purga por evento, um tempo de expiração garante que nada fique cacheado eternamente por engano.

Como testar se o cache está mesmo funcionando

De nada adianta configurar tudo isso e não conferir. A forma mais direta é olhar os cabeçalhos de resposta da página nas ferramentas de desenvolvedor do navegador (aba de rede) ou por uma requisição de linha de comando. Mecanismos de cache costumam anunciar seu status ali.

• Procure cabeçalhos de status de cache. Muitos sistemas enviam algo como X-Cache: HIT (a página veio do cache) ou MISS (foi gerada agora). Ver HIT na segunda visita confirma que o cache de página está ativo.
• Compare o tempo de resposta. A primeira visita a uma página nova é mais lenta (gera e cacheia); a segunda deve ser visivelmente mais rápida. Se não for, algo não está cacheando.
• Teste logado e deslogado. Confirme que, logado, você recebe a versão dinâmica (sem cache cheio) e, anônimo, recebe a versão cacheada. Se um usuário logado vê dados de outro, a exceção de cache está errada.

Empilhando as camadas com juízo

Cache no WordPress não é uma escolha entre opções — é uma pilha em que cada camada resolve um problema diferente. O cache de página elimina o custo de montar o HTML; o cache de objeto alivia o banco no que sobra de dinâmico; o OPcache acelera o PHP por baixo de tudo; o cache de navegador e a CDN levam os arquivos para perto do visitante; os transients evitam refazer trabalho externo. Muitos hosts gerenciados de WordPress já entregam boa parte disso no servidor, sem plugin, o que costuma ser mais estável do que empilhar plugins concorrentes. O que nunca muda é o par de perguntas que você deve fazer a cada camada: ela está mesmo ativa? e ela está servindo a versão correta? Rapidez sem correção é uma armadilha, e o dia em que um cliente vê o carrinho de outra pessoa custa muito mais caro do que os milissegundos que você economizou.