Prólogo: Onde o WordPress Encontra o Limbo
Você já sentiu aquele calafrio ao executar uma consulta SQL em produção e perceber que o cache Redis simplesmente ignorou a invalidação? Pois é. Em arquiteturas headless, isso não é um bug — é um feature mal documentado. Trabalhei em um projeto onde o cache edge (Varnish + Cloudflare) servia posts atualizados de 2019 para usuários na Austrália, enquanto o Brasil recebia a versão correta de 2024. O motivo? Uma combinação perversa de stale-while-revalidate configurado errado e um plugin GPL de cache que prometia milagres.
O Dilema do Cache Distribuído em Headless WP
Por que o cache padrão do WordPress falha em ambientes headless?
No WordPress monolítico, o cache de página inteira funciona porque o escopo é previsível: uma URL mapeia diretamente para um post. No headless, o frontend (Next.js, Nuxt, SvelteKit) faz múltiplas chamadas REST ou GraphQL para montar uma única página. Cada endpoint pode ter dependências diferentes de posts, categorias, meta-dados e opções. Agora imagine: você tem 3 regiões (EUA, Europa, Ásia), cada uma com seu próprio Redis e Varnish, e o frontend faz 12 requisições simultâneas para renderizar o homepage. Se o cache de uma região expira 5 minutos depois da outra, o usuário na Ásia vê um mix de dados velhos e novos.
- Problema clássico: Stale cache em regiões com baixa frequência de escrita.
- Solução ingênua: TTL uniforme de 1 hora. Resultado: usuários nos EUA veem notícias de 2 horas atrás.
- Workaround real: Usar cache tags no Redis e invalidar por chave semântica, mas aí entra o gargalo de consistência eventual.
Estudo de Caso Reverso: O Erro que Quase Custou US$ 50k
Não, não é teoria. Em 2023, um cliente migrou de WP tradicional para headless (Next.js + WP REST API). Na migração, o time de DevOps configurou o Redis como cache de objeto, mas esqueceu de desabilitar o cache de página do plugin W3 Total Cache. Resultado: o Varnish recebia respostas HTML do backend que já estavam cacheadas no Redis, mas o Varnish tratava como dinâmico. O frontend Next.js, por sua vez, mantinha um cache próprio (ISR) com stale-while-revalidate de 1 hora. O resultado foi uma sopa de letrinhas: dados inconsistentes entre regiões, sessões de usuário quebradas e uma conta de US$ 50k em custos de computação desnecessários.
Micro-anedota dos bastidores: Na madrugada da quinta-feira, o engenheiro sênior responsável pelo cache disse: “Relaxa, o cache está funcionando perfeitamente”. No dia seguinte, 3 clientes corporativos reportaram que o preço dos produtos aparecia como R$ 0,00. O motivo? A chave de cache de preço (que dependia de um meta-field) estava compartilhando o mesmo namespace do cache de conteúdo. A invalidação de um post atualizava o preço de todos os produtos. Um desastre.
Manifesto Técnico: Por Que a GPL é a Raiz do Problema
Você já se perguntou por que plugins de cache como WP Rocket e W3 Total Cache são tão frágeis em headless? A resposta está na licença GPL. Como o WordPress é GPL, muitos plugins adotam a mesma licença, mas isso significa que o código é público e, muitas vezes, mal documentado. A comunidade headless, que deveria ser um ecossistema de inovação, acaba reimplementando rodas quadradas. Exemplo: a função wp_cache_set() do WP nativo não suporta cache tags. Você precisa de Redis com extensões PECL ou plugins terceiros que podem conflitar. E quando um plugin GPL falha, você não pode culpar ninguém — o código está ali, mas ninguém leu.
Minha sugestão radical: desabilite todo cache de página no backend WP quando usar headless. Deixe o cache apenas no Redis como cache de objeto, e invalide via REST API usando custom headers. O frontend (seja Next.js, Gatsby, ou SPA) que gerencie o cache de borda. Mas prepare-se: você vai precisar de um sistema de filas para invalidar caches em múltiplas regiões. Acredite, já vi isso quebrar deploys.
Core Web Vitals e Headless: O Paradoxo da Performance
Uma das promessas do headless é melhorar o Core Web Vitals. Na prática, você pode piorar o LCP se o cache de borda não estiver otimizado para entregar HTML estático. O Next.js com ISR é ótimo, mas se a API do WordPress demora 400ms para responder, o TTFB vai para o espaço. Solução real? Use cache de resposta na API com Varnish ou Nginx FastCGI Cache, e configure o stal-while-revalidate para 10 minutos. Mas lembre-se: a invalidação deve ser manual via webhook sempre que um post for atualizado.
- Erro fatal: Usar Redis como cache de página em headless. Nunca. O Redis é para cache de objeto e sessão.
- Dica avançada: Use cache de consulta com transients para queries complexas, mas com TTL baixo (30s).
- Armadilha: Plugins de SEO que geram meta-tags dinâmicas via REST API — eles invalidam o cache a cada requisição.
Epílogo: O Cache é uma Ilusão, a Consistência é o Verdadeiro Desafio
Headless WordPress não é para os fracos. Exige um entendimento profundo de cache distribuído, invalidação semântica e licenciamento de software. Se você está pensando em migrar, faça um teste de estresse: simule 10 atualizações de post simultâneas em 3 regiões e veja quanto tempo leva para o cache convergir. Se passar de 5 minutos, repense a arquitetura. E, por favor, não confie em plugins GPL para resolver problemas de cache — eles foram feitos para blogs, não para CDNs globais.