Um site WordPress bem construído não fica lento por causa do WordPress — fica lento por causa de ausência de cache. A diferença entre um site que processa cada requisição do zero (300–800ms no banco de dados) e um site com stack completa de cache (5–15ms servindo HTML estático) é a diferença entre ranquear na primeira página ou perder usuários no bounce.

Este guia cobre as quatro camadas de cache em ordem de impacto, com configurações reais.

Camada 1: OPcache — a base obrigatória

OPcache é a camada mais fundamental e a que mais pessoas esquecem de ajustar. Por padrão, o PHP lê, interpreta e compila cada arquivo .php em bytecode a cada requisição. Com OPcache, o bytecode compilado é armazenado na memória do servidor e reutilizado — eliminando o custo de compilação em 100% das requisições.

Configuração otimizada no php.ini (ou php.ini do usuário no Hostinger):

; OPcache — configuração para WordPress de médio/alto tráfego
opcache.enable=1
opcache.enable_cli=1
opcache.memory_consumption=256       ; MB — aumente se tiver muitos plugins
opcache.interned_strings_buffer=16  ; MB — strings internalizadas
opcache.max_accelerated_files=10000  ; número de arquivos em cache
opcache.validate_timestamps=0        ; prod: desabilite revalidação para velocidade máxima
opcache.revalidate_freq=0
opcache.fast_shutdown=1

Atenção: com validate_timestamps=0, o OPcache não detecta alterações nos arquivos PHP automaticamente. Após deploys, você precisa limpar o cache manualmente com opcache_reset() via WP-CLI ou reiniciando o PHP-FPM.

Camada 2: Object Cache com Redis

O WordPress tem uma API de object cache nativa (wp_cache_get/set), mas por padrão ela é por-requisição — não persiste entre hits. Cada nova visita refaz as mesmas queries: buscar opções do banco (wp_options), carregar menus, contar posts por categoria.

Com Redis e o plugin Redis Object Cache (ou o nativo do WP 6.1+, Object Cache Pro), esse cache passa a ser compartilhado entre todas as requisições e persiste até você invalidar.

Instalação no servidor:

# Ubuntu/Debian
apt install redis-server
systemctl enable redis
systemctl start redis

# Verificar se está rodando
redis-cli ping  # deve retornar: PONG

No wp-config.php, antes do comentário stop editing:

define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);
define('WP_REDIS_DATABASE', 0);
define('WP_REDIS_TIMEOUT', 1);
define('WP_REDIS_READ_TIMEOUT', 1);

Depois de instalar o plugin e ativar a conexão, uma barra de diagnóstico aparece no admin mostrando hit rate, memória usada e número de conexões por requisição. Uma instalação saudável tem hit rate acima de 80%.

Camada 3: Page Cache — o maior impacto

Para páginas sem login (home, posts, categorias), a maior otimização é gerar e servir HTML estático pré-compilado. O servidor entrega um arquivo HTML da memória ou disco sem sequer executar PHP.

LiteSpeed Cache é a melhor opção se seu servidor usa LiteSpeed Web Server (Hostinger, LiquidWeb). Integra com o servidor via protocolo nativo — o cache é servido pelo próprio LiteSpeed antes do PHP ser chamado. Configuração mínima:

Para servidores Apache/Nginx, o WP Rocket tem a melhor relação custo-benefício (~US$59/ano). Alternativa gratuita: W3 Total Cache com o modo de page cache em disco (modo disk enhanced).

Camada 4: CDN e assets estáticos

Mesmo com page cache no servidor, imagens, JS e CSS viajam do Brasil até o servidor. Um CDN com PoP no Brasil elimina essa latência.

Cloudflare (gratuito) serve como proxy reverso e CDN. Com o plugin oficial do WordPress, páginas cacheadas no Cloudflare são servidas do PoP mais próximo do usuário. Configuração crítica:

# Cloudflare Cache Rules — bypass para admin e WooCommerce
# No painel Cloudflare → Rules → Cache Rules:
# Condition: URI path contains /wp-admin OR cookie contains "wordpress_logged_in"
# Action: Bypass cache

BunnyCDN (plano mínimo ~US$1/mês baseado em uso) tem PoPs em São Paulo e Rio de Janeiro — menor latência para o Brasil do que Cloudflare no plano gratuito.

Diagnóstico: identificando gargalos reais

Antes de instalar qualquer plugin, meça. O Query Monitor (gratuito) exibe no admin bar o tempo total de cada requisição, número de queries SQL, queries lentas, hooks lentos e consumo de memória por requisição. Uma página saudável deve ter:

Se alguma query está acima de 5ms individualmente, inspecione o EXPLAIN no MySQL. Falta de índice em wp_postmeta é a causa mais comum de queries lentas em sites com muitos custom fields.

Estratégia de invalidação de cache

O cache perfeito é aquele que nunca expira desnecessariamente. Configure purge automático apenas para os casos que realmente mudam o conteúdo: publicar post novo (home + categoria + sitemap), editar post (página do post + home se featured), aprovar comentário (página do post).

A maioria dos plugins de page cache configura isso por padrão, mas verificar o log de purges no início evita surpresas — como um post que fica com conteúdo desatualizado porque o cache não foi invalidado após edição.