O que é cache no WordPress?

O cache armazena uma cópia do conteúdo gerado para que ele possa ser entregue mais rapidamente em requisições subsequentes, sem precisar regenerá-lo do zero. Para o WordPress, isso significa pular a execução do PHP e as consultas ao banco de dados em visualizações repetidas de página. Uma página WordPress que leva 800ms para ser gerada do zero pode ser entregue em menos de 50ms quando está em cache. O cache é uma das otimizações de maior impacto que você pode fazer em qualquer site WordPress.

Os cinco tipos de cache no WordPress

O cache no WordPress não é uma coisa só. Existem cinco camadas distintas, cada uma atuando em um ponto diferente do ciclo de requisição. Entender o que cada uma faz ajuda você a escolher a estratégia de cache certa para o seu site.

Cache do navegador

O cache do navegador é a primeira camada e funciona inteiramente no dispositivo do visitante. Quando um navegador baixa um arquivo CSS, uma imagem ou um arquivo JavaScript, ele guarda uma cópia local. No próximo carregamento de página, o navegador verifica se a cópia em cache ainda é válida (com base nos cabeçalhos Cache-Control, Expires e ETag) e dispensa o download por completo se for. Isso elimina requisições de rede e faz com que as próximas visualizações de página pareçam quase instantâneas para visitantes recorrentes.

Você controla o cache do navegador por meio de cabeçalhos de resposta HTTP. Os mais importantes são:

• Cache-Control: max-age=31536000: diz ao navegador para guardar o arquivo em cache por um ano (31.536.000 segundos). Usado para recursos estáticos versionados que recebem um novo nome de arquivo quando mudam.
• Cache-Control: no-cache: o navegador deve verificar com o servidor antes de usar a cópia em cache. O servidor pode responder com "304 Not Modified" se o arquivo não tiver mudado, economizando largura de banda.
• Cache-Control: no-store: o navegador nunca deve armazenar essa resposta em cache. Usado para conteúdo sensível ou altamente dinâmico.

Cache de página

O cache de página é o maior ganho de desempenho para a maioria dos sites WordPress. Eis o problema que ele resolve: a cada requisição de página, o WordPress carrega seu núcleo, inicializa a conexão com o banco de dados, executa dezenas de consultas, processa hooks de plugins e renderiza os templates do tema. Esse ciclo PHP/MySQL leva de 200ms a vários segundos, dependendo do servidor e da complexidade do site. E produz a mesma saída HTML para todo visitante anônimo.

Um cache de página armazena essa saída HTML após a primeira requisição. Quando o próximo visitante solicita a mesma página, o arquivo HTML em cache é entregue diretamente pelo servidor web (ou até por um proxy reverso à frente dele), pulando completamente o WordPress, o PHP e o banco de dados. A diferença é dramática. Em vez de executar de 50 a 200 consultas ao banco e milhares de linhas de PHP, o servidor simplesmente lê um arquivo e o envia.

Cache de objetos

O cache de objetos fica entre o WordPress e o banco de dados. O WordPress consulta repetidamente os mesmos dados em um único carregamento de página e entre carregamentos: opções, metadados de usuário, dados de posts, transients. O cache de objetos guarda esses resultados de consulta em memória (usando Redis ou Memcached) para que eles não acessem o banco toda vez.

O WordPress tem um cache de objetos embutido, mas, por padrão, ele só funciona dentro de uma única requisição (não persiste entre requisições). Para obter cache de objetos persistente, é preciso um plugin drop-in que conecte o WordPress ao Redis ou Memcached. Opções populares incluem Redis Object Cache e Object Cache Pro.

O cache de objetos é particularmente valioso para sites que não podem usar cache de página completa, como lojas WooCommerce com conteúdo personalizado, sites de membros ou fóruns onde o conteúdo muda com frequência.

Cache de opcode (OPcache)

Toda vez que o PHP processa um script, ele primeiro compila o código PHP legível para humanos em bytecode (instruções legíveis para a máquina). Essa etapa de compilação se repete a cada requisição, a menos que o cache de opcode esteja habilitado. A extensão OPcache embutida no PHP guarda o bytecode compilado em memória compartilhada, eliminando a etapa de compilação para requisições subsequentes.

O OPcache é uma configuração no nível do servidor, não algo que você ajusta pelo WordPress. A maioria dos ambientes de hospedagem modernos tem o OPcache habilitado por padrão. Você pode verificar isso consultando a configuração do PHP (phpinfo) ou perguntando ao seu provedor de hospedagem. Só o OPcache pode melhorar a velocidade de execução do PHP em 30-50%.

Cache de CDN

Uma CDN (Content Delivery Network) armazena em cache seus recursos estáticos em servidores de borda distribuídos pelo mundo. Quando um visitante em Tóquio solicita uma imagem do seu site WordPress hospedado em Amsterdã, a CDN a entrega a partir de um servidor de borda próximo, em vez de rotear a requisição até Amsterdã. Isso reduz significativamente a latência para recursos estáticos. Alguns provedores de CDN, como o Cloudflare, também oferecem cache de página completa para WordPress por meio do recurso APO. Para mais detalhes, veja nosso artigo sobre Content Delivery Networks.

Como o cache de página funciona passo a passo

Como o cache de página tem o maior impacto, eis um olhar mais detalhado sobre como ele funciona na prática:

1. Um visitante solicita seudominio.com/sobre/ pela primeira vez.
2. O WordPress processa a requisição normalmente: o PHP roda, o banco de dados é consultado, o template do tema é renderizado e o HTML é gerado.
3. O plugin de cache salva uma cópia do HTML finalizado no sistema de arquivos (geralmente em wp-content/cache/) ou em memória.
4. Um segundo visitante solicita seudominio.com/sobre/.
5. O plugin de cache intercepta a requisição antes do WordPress carregar. Ele encontra o arquivo HTML em cache e o entrega diretamente. O PHP mal é executado, e o banco de dados não é tocado.
6. Quando o conteúdo da página muda (um post é atualizado, um comentário é aprovado), o cache daquela página específica é invalidado, e a próxima requisição gera uma cópia nova.

Comparação de plugins populares de cache para WordPress

Existem muitos plugins de cache disponíveis para o WordPress. Eis os mais usados e como se comparam:

• WP Rocket: um plugin premium (a partir de US$59/ano) amplamente considerado a solução de cache mais amigável. Ele habilita cache de página, cache do navegador, compressão GZIP e lazy loading de fábrica, com configuração mínima. O WP Rocket também cuida da minificação de CSS/JS, da otimização do banco de dados e integra com o Cloudflare para purga de cache da CDN. É a melhor escolha para donos de site que querem ótimo desempenho sem passar horas em configuração.
• W3 Total Cache: um plugin gratuito com uma enorme variedade de recursos. Ele suporta cache de página, cache de objetos (Redis, Memcached, APCu), cache do navegador, integração com CDN e minificação. A desvantagem é a complexidade. O W3 Total Cache tem dezenas de páginas de configurações, e uma má configuração pode quebrar o site. É poderoso, mas mais adequado para desenvolvedores ou usuários avançados.
• WP Super Cache: um plugin gratuito desenvolvido pela Automattic (a empresa por trás do WordPress.com). Ele foca em cache de página e mantém as coisas simples. O WP Super Cache gera arquivos HTML estáticos e pode entregá-los usando regras de mod_rewrite, o que é muito rápido. Faltam-lhe os recursos avançados do WP Rocket e do W3 Total Cache, mas é confiável e fácil de configurar.
• LiteSpeed Cache: um plugin gratuito que oferece desempenho excepcional quando usado com servidores LiteSpeed. Ele suporta cache de página, cache de objetos, otimização de imagens, minificação de CSS/JS e integração com CDN. Se sua hospedagem usa LiteSpeed (muitas hospedagens compartilhadas usam), este plugin aproveita o cache no nível do servidor, que é mais rápido que o cache baseado em PHP. Também funciona em Apache e nginx, mas com funcionalidade reduzida.

Soluções de cache no nível do servidor

Além dos plugins de WordPress, o cache também pode ocorrer no nível do servidor, o que costuma ser mais rápido porque intercepta as requisições antes mesmo de o PHP entrar em ação:

• Varnish: um cache de proxy reverso que fica à frente do seu servidor web. O Varnish guarda respostas de página inteiras em memória e as entrega diretamente para requisições em cache. É extremamente rápido (tempos de resposta abaixo de um milissegundo) e usado por sites WordPress de alto tráfego. A configuração requer VCL (Varnish Configuration Language), que tem uma curva de aprendizado.
• Cache FastCGI do nginx: se seu servidor usa nginx (o que muitas hospedagens WordPress modernas fazem), o cache FastCGI armazena a saída completa do PHP e a entrega diretamente pelo nginx em requisições subsequentes. Isso é mais rápido do que qualquer plugin de cache baseado em PHP, porque o nginx atende a requisição inteiramente sem invocar o PHP. Muitas hospedagens WordPress gerenciadas (Kinsta, GridPane, SpinupWP) usam essa abordagem.
• Cache de página completa com Redis: algumas configurações usam o Redis não apenas para cache de objetos, mas também para cache de página completa. O HTML em cache é armazenado na memória do Redis, e um pequeno script PHP ou módulo do nginx o entrega diretamente. Isso combina a velocidade do armazenamento em memória com a flexibilidade da invalidação de cache baseada em chaves.

Cache de objetos com Redis e Memcached

Para sites WordPress que lidam com cargas pesadas de banco de dados, o cache de objetos persistente pode ser transformador. Eis como as duas principais opções se comparam:

• Redis: a escolha mais popular para o WordPress. O Redis armazena dados em memória e suporta tipos de dados complexos (strings, hashes, listas, sets). Ele pode persistir dados em disco, suporta replicação e pode ser usado tanto para cache de objetos quanto para armazenamento de sessão. O plugin Redis Object Cache é a forma mais comum de conectar o WordPress ao Redis.
• Memcached: um sistema de cache em memória mais antigo e simples. O Memcached é rápido e leve, mas não tem a persistência de dados nem os recursos avançados do Redis. Ainda é usado em alguns ambientes de hospedagem, particularmente os mais antigos.

O cache de objetos persistente faz a maior diferença em sites com consultas complexas: lojas WooCommerce com milhares de produtos, comunidades BuddyPress, redes multisite ou qualquer site onde o painel administrativo do WordPress pareça lento.

Quando o cache causa problemas

O cache nem sempre é direto. Há situações em que um cache agressivo cria problemas:

• Usuários logados: o cache de página não deve entregar páginas em cache para usuários logados, porque cada usuário vê conteúdo diferente (seu nome no cabeçalho, barra de admin, painel pessoal). Todos os principais plugins de cache lidam com isso corretamente por padrão, mas implementações personalizadas às vezes erram.
• WooCommerce e e-commerce: carrinhos de compras, páginas de checkout e páginas "minha conta" são dinâmicas e específicas por usuário. Elas devem ser excluídas do cache de página. WP Rocket e LiteSpeed Cache excluem automaticamente as páginas do WooCommerce. Com outros plugins, talvez seja preciso configurar exclusões manualmente.
• Conteúdo dinâmico e AJAX: se seu site depende fortemente de conteúdo carregado via AJAX, dados em tempo real ou elementos personalizados (produtos visualizados recentemente, recomendações específicas por usuário), o cache de página completa pode entregar conteúdo desatualizado. As soluções incluem cache de fragmentos (cachear tudo, exceto as partes dinâmicas) ou carregar conteúdo dinâmico via JavaScript depois que a página em cache é carregada.
• Sites de membros: sites com vários níveis de associação mostram conteúdo diferente para grupos de usuários distintos. O cache de página precisa levar em conta essas variações, seja pulando o cache para usuários logados, seja mantendo versões em cache separadas por papel de usuário (o que a maioria dos plugins não suporta).
• Formulários e nonces: o WordPress usa nonces (tokens de uso único) para segurança em formulários. Se uma página com um formulário estiver em cache, todos os visitantes recebem o mesmo nonce, que pode expirar e causar erros no envio do formulário. Os plugins de cache geralmente lidam com isso, mas é uma fonte comum de problemas com formulários personalizados.

Invalidação de cache: a parte difícil

Há um ditado famoso na ciência da computação: "Existem apenas duas coisas difíceis na ciência da computação: invalidação de cache e nomear coisas." A invalidação de cache é o processo de limpar ou atualizar o conteúdo em cache quando os dados subjacentes mudam. No WordPress, isso significa:

• Quando você publica ou atualiza um post, o cache desse post, dos arquivos de categoria, dos arquivos de tag, da página inicial e de qualquer página que exibe posts recentes deve ser limpo.
• Quando você muda configurações do tema, todo o cache de página deve ser limpo, porque cada página pode ficar diferente.
• Quando um novo comentário é aprovado, a versão em cache daquele post deve ser atualizada para mostrar o novo comentário.

Bons plugins de cache lidam com a maioria desses cenários automaticamente por meio de hooks do WordPress. Eles escutam eventos como save_post, switch_theme e wp_update_comment_count e limpam as entradas de cache relevantes. No entanto, se você tem código personalizado que altera conteúdo sem passar pelas funções padrão do WordPress, o cache pode não ser invalidado corretamente.

Em caso de dúvida, a maioria dos plugins de cache oferece um botão "Purgar todo o cache" na barra de admin do WordPress. Use-o após mudanças significativas se as páginas em cache não estiverem refletindo suas atualizações.

O que o InspectWP verifica

O InspectWP detecta se um plugin de cache do WordPress está ativo procurando comentários HTML relacionados a cache (muitos plugins inserem um comentário como <!-- Cached by WP Rocket --> no rodapé da página), cabeçalhos de resposta (como X-Cache, X-Cache-Enabled ou X-LiteSpeed-Cache) e assinaturas conhecidas de plugins no código-fonte da página. O relatório identifica qual plugin de cache está em uso, para que você possa verificar se a sua configuração de cache está funcionando corretamente. Se nenhum cache for detectado, o InspectWP sinaliza isso como uma oportunidade de melhoria de desempenho, já que o cache é uma das maneiras mais eficazes de acelerar qualquer site WordPress.