Como configurar cache WordPress em sites de clientes: guia técnico para agências

A cache é a otimização de performance com melhor relação custo-benefício no WordPress. Mas configurá-la incorretamente é uma das causas mais comuns de bugs silenciosos em produção — formulários que não enviam, conteúdo desatualizado, checkout WooCommerce com dados de outro utilizador. Este guia cobre as camadas de cache que toda a agência deve dominar.

Os 4 tipos de cache WordPress

Muitos confundem "instalar um plugin de cache" com "ativar cache". Na realidade, existem quatro camadas distintas que se complementam:

1. Page cache

Guarda o HTML gerado pelo PHP e serve-o diretamente sem executar código ou consultar a base de dados. É a camada com maior impacto imediato no TTFB (Time to First Byte). Gerida por plugins como WP Rocket, W3 Total Cache ou LiteSpeed Cache.

2. Object cache

Guarda em memória os resultados de queries à base de dados mais frequentes (via Redis ou Memcached). Reduz a carga na BD e acelera páginas com conteúdo dinâmico que não podem ser totalmente cacheadas (como páginas de utilizador autenticado).

3. Browser cache

Instrui o browser a guardar localmente assets estáticos (CSS, JS, imagens) por um período definido. Configurado via headers HTTP no .htaccess ou no plugin de cache. Elimina pedidos desnecessários em visitas repetidas.

4. CDN cache

Serve assets estáticos a partir de servidores geograficamente próximos do visitante. Reduz latência especialmente para sites com público internacional. Cloudflare é a opção mais comum e tem plano gratuito.

Plugins de page cache: WP Rocket vs W3 Total Cache vs LiteSpeed Cache

WP Rocket

O plugin de cache premium mais popular. Configuração simples, ativa a maioria das otimizações por defeito com boas práticas. Inclui lazy load de imagens, minificação de CSS/JS, preloading e integração com CDN. Custo: ~59€/ano por site. Ideal para: agências que valorizam simplicidade e suporte, e não querem gerir configuração técnica complexa.

W3 Total Cache

O plugin de cache mais configurável — e por isso o mais complexo. Suporte a todos os tipos de cache (page, object, browser, CDN) e integração com múltiplos backends. Versão gratuita funcional. Ideal para: técnicos que querem controlo granular e têm tempo para configurar corretamente.

LiteSpeed Cache

Plugin gratuito que requer servidor LiteSpeed (muito comum em hostings portugueses económicos). Quando disponível, é das melhores opções gratuitas — cache a nível de servidor com funcionalidades que outros plugins premium cobram. Ideal para: sites em hosting com servidor LiteSpeed.

Object cache com Redis ou Memcached

O object cache é a camada que mais agências ignoram — e onde frequentemente está o maior ganho de performance em sites com tráfego médio a alto.

Para ativar, o hosting precisa de suportar Redis ou Memcached. Em VPS próprio, instala-se Redis com:

apt install redis-server
pecl install redis

Em WordPress, adiciona-se ao wp-config.php:

define('WP_CACHE', true);
define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);

E instala-se o plugin Redis Object Cache para ligar o WordPress ao servidor Redis. O ganho típico em sites com muito conteúdo dinâmico é de 30-60% de redução no tempo de geração de página.

Erros comuns ao configurar cache em WordPress

Cache em páginas de checkout WooCommerce

As páginas /cart/, /checkout/ e /my-account/ nunca devem ser cacheadas. A maioria dos plugins de cache tem regras automáticas para isto — mas é essencial verificar. Um checkout cacheado pode mostrar dados de outro utilizador, com implicações graves de privacidade e RGPD.

Cache de páginas com conteúdo dinâmico por utilizador

Sites com utilizadores registados (membership, e-learning, portais) necessitam de cache diferenciada por utilizador ou exclusão total de cache para utilizadores autenticados.

Cache não limpa após updates

Após atualizar conteúdo, tema ou plugins, a cache deve ser limpa manualmente se não houver invalidação automática configurada. Definir um processo claro de limpeza de cache no workflow de updates é essencial.

Como medir o impacto da cache

Antes de ativar cache, regista o TTFB baseline. Após ativação, compara:

• GTmetrix: secção "Waterfall" — tempo do primeiro pedido HTML deve baixar para <200ms com cache ativa
• WebPageTest: métrica "Time to First Byte" — com cache de servidor, valores abaixo de 100ms são alcançáveis
• curl no terminal: curl -I https://exemplo.pt/ — verificar header X-Cache: HIT

Um site WordPress sem cache serve tipicamente entre 500ms e 2s de TTFB. Com page cache bem configurada, esse valor desce para 50-200ms — uma melhoria que se traduz diretamente em melhores Core Web Vitals e melhor ranking. Para uma análise das causas de lentidão antes de configurar cache, ver WordPress lento: as 10 causas mais comuns.