Você já experimentou o pânico de ver seu site headless WordPress exibindo dados de 2014 para um usuário VIP enquanto o banco de dados implode? Aconteceu comigo em uma madrugada de sexta-feira. O chefe do cliente gritava no Slack: ‘Por que meu post novo não aparece?’ O Next.js servia uma versão em cache de uma época em que o Facebook ainda era legal. O banco de dados? Uma bomba de relógio prestes a explodir.
Vamos mergulhar no problema silencioso que assombra arquiteturas headless WordPress com Next.js: o conflito entre o cache agressivo do framework frontend e a natureza dinâmica do banco de dados WordPress.
O Caso da Empresa de E-commerce que Perdeu R$ 50 mil em um Dia
Uma loja online de médio porte migrou para headless WordPress + Next.js para melhorar o Core Web Vitals. Resultado? Lighthouse subiu de 45 para 95. Clientes felizes. Até que no Black Friday, o cache do Next.js decidiu que não precisava revalidar por 24 horas. O estoque mostrava produtos disponíveis que já tinham sido vendidos. 50 mil reais em pedidos cancelados. O suporte entrou em colapso.
O erro? O time configurou revalidação com base no tempo (ISR) sem considerar a natureza imprevisível do banco de dados WordPress. Eles tratavam o WordPress como um CMS normal, não como uma fonte de dados caótica.
A Anatomia do Problema: Por que WordPress + Next.js é um Casamento Tóxico?
1. O WordPress não foi feito para ser ‘headless amigável’
O banco de dados WordPress é um monstro de transientes, opções, metadados e post_status. Cada consulta à REST API pode disparar 20 queries internas. Quando o Next.js tenta revalidar uma página, ele não sabe que o plugin de SEO atualizou 50 linhas na tabela wp_options. Resultado: cache stale que nunca é invalidado corretamente.
2. O Cache do Next.js é um Canibal de Recursos
O Next.js adora armazenar tudo em cache. Mas o cache do Next.js não entende de dependências WordPress. Se um post é atualizado, o cache de páginas relacionadas (categorias, tags, autor) não é limpo automaticamente. Você precisa implementar webhooks manuais. E webhooks, no WordPress, são tratados como cidadãos de segunda classe.
3. O Efeito Butterfly: Uma Simples Atualização de Plugin quebra tudo
Você atualiza um plugin no WordPress. O plugin modifica um meta dado. O Next.js não sabe disso. De repente, todas as páginas que dependem desse meta são servidas com dados antigos. O usuário vê preços errados, descrições incorretas. E o banco de dados WordPress começa a acumular posts revisados, autosaves e lixo transiente que nunca são limpos.
O Manifesto Técnico: Estratégias de Mitigação que Funcionam (e Por que a Maioria Ignora)
1. Cache Invalidation Granular baseada em Ações do WordPress
Esqueça revalidação por tempo. Use webhooks que disparam revalidação seletiva quando:
- Um post é publicado ou atualizado (escute o hook save_post).
- Um termo de taxonomia é modificado (escute edit_term).
- Uma opção crítica é alterada (escute update_option).
Exemplo de implementação: Um plugin WordPress simples que envia um POST para sua API Next.js com o tipo de recurso e ID. No Next.js, você usa revalidateTag em vez de revalidatePath para invalidar grupos de páginas relacionados.
2. Use o WPGraphQL no Lugar da REST API (Sim, é mais Rápido e Controlável)
A REST API do WordPress é um canivete suíço que ninguém pediu. Ela retorna dados demais. O WPGraphQL é mais enxuto, e você pode controlar exatamente o que é cacheado. Dica de insider: Combine WPGraphQL com persisted queries (usando Apollo Client ou urql) para reduzir a carga no banco de dados em 70%.
3. O Anti-Padrão: Banco de Dados Dedicado para Headless
Sim, você leu certo. Crie um banco de dados WordPress separado apenas para servir dados headless. Sincronize via webhooks. O banco headless terá tabelas otimizadas, sem transientes, sem revisões. É radical, mas funciona. Um cliente meu fez isso e reduziu o tempo de resposta da API de 2 segundos para 200 ms.
4. Ferramentas que Salvam (e Matam) o Desempenho
Use o Query Monitor do WordPress para identificar consultas lentas. Instale o Redis Object Cache no servidor WordPress (não confie no cache de página obsoleto). No Next.js, configure o incremental cache com um Redis externo (usando @neshca/cache-handler) para evitar o cache padrão baseado em arquivo que não escala.
O Alerta Final: Nunca Subestime o WordPress
WordPress foi construído para ser um blog. Headless é uma gambiarra elegante. Mas se você trata o WordPress como uma API genérica, ele vai te morder. Cada post salvo, cada comentário, cada atualização de plugin é um evento que pode quebrar seu cache. A única saída é tratar o ecossistema como um sistema reativo: eventos do WordPress disparam ações no Next.js, e não o contrário.
Meu erro naquela sexta-feira? Eu confiei que a ferramenta (Next.js) resolveria tudo. A ferramenta nunca resolve o problema de arquitetura. Hoje, antes de qualquer implementação headless, eu pergunto: ‘Você está pronto para monitorar cada evento do WordPress como se fosse uma ameaça?’. Se a resposta for não, volte para o WordPress tradicional. Sua sanidade agradece.
Quer se aprofundar no código? Leia o Guia de Cache do Next.js e o REST API Handbook do WordPress. Mas lembre-se: a teoria é linda, a prática é um campo minado.