Você já sentiu aquele arrepio no servidor? Aquele momento em que o Redis, seu aliado mais veloz, se torna o algoz silencioso da sua aplicação headless? Pois é. Em seis anos debugando arquiteturas WordPress, vi o mesmo padrão se repetir: desenvolvedores celebrando o TTFB de 200ms, enquanto o banco de dados, nos bastidores, sangra lentamente. A culpa? Um fantasma chamado cache de transient.
O Paradoxo do Cache Headless
No WordPress tradicional, o cache é simples: página visitada, página salva em HTML. No headless, você serve JSON, e cada requisição é uma negociação entre Nginx, PHP e Redis. A mágica do WordPress moderno é que ele tenta ser inteligente: em vez de consultar o banco a cada chamada de API, ele armazena objetos serializados no Redis. Parece lindo. Até que não é.
O problema mora nos transients. Essas entradas, que deveriam ser temporárias, muitas vezes viram zumbis. Um plugin mal escrito, um tema que define cache com expiração de 0 segundos, e pronto: você tem um cache poisoning lento. Dados obsoletos são servidos como frescos, e o pior: ninguém percebe até o CLS disparar.
Estudo de Caso: O Site que Engasgou por 3 Dias
Ano passado, um cliente com 2 milhões de páginas headless viu seu Core Web Vitals despencarem. O LCP passou de 1,2s para 8s em 48 horas. A equipe de infra estava pronta para escalar horizontalmente. Mas eu suspeitei do cache.
Olhando o Redis, notei algo estranho: chaves como wp_transient_xyz com TTL de -1. Transients eternos. O banco estava sendo consultado 300 vezes por segundo por conta de um plugin que usava transient para guardar uma lista de posts populares. A cada requisição, o WP verificava se o transient existia no Redis, não encontrava (porque o TTL havia expirado, mas a chave não era removida), então caía no banco. O cache virava um anti-cache.
A solução foi brutal: limpar todas as chaves com TTL expirado e forçar um garbage collection no Redis via SCAN. Resultado: tráfego no banco caiu 90%, LCP voltou para 1,1s.
Licenças GPL e o Silêncio dos Fornecedores
Outro ponto cego: plugins que usam transients com chaves não-padronizadas. A GPL permite que você modifique o código, mas quantos provedores de cache (como Redis Object Cache) documentam que chaves com prefixo wp_transient_ são críticas para a limpeza seletiva? Nenhum. Eles empurram a culpa para o desenvolvedor.
A verdadeira armadilha é que o WordPress, por padrão, não limpa transients expirados automaticamente. O wp_cron até tenta, mas em uma arquitetura headless sem cron ativo (o que é comum em containers), as chaves se acumulam. Você precisa de um job externo que varra o Redis a cada hora.
Receita para Domar o Fantasma
- Auditoria de chaves: Use
redis-cli --scan --pattern 'wp_transient_*'e analise o TTL. Transientes com TTL infinito (-1) são dores de cabeça. - Expurgo seletivo na REST API: Em hooks como
rest_pre_echo_response, invalide transients específicos após cada requisição POST que modifique conteúdo. - Monitoria de hit/miss ratio: No Redis, meça quantas vezes o cache é consultado vs. quantas vezes retorna
nil. Se o hit ratio cair abaixo de 85%, algo está podre. - Cache de banco via SQLite: Sim, você leu certo. Para dados transitórios de sessão, usar SQLite em vez de Redis pode evitar o overhead de serialização do WordPress.
O Manifesto Técnico: Transientes São o Novo Lixo Eletrônico
Headless WordPress não é apenas decoupling do frontend; é repensar cada linha de cache. A indústria vende Redis como bala de prata, mas esquece que todo sistema de cache tem latência de invalidação. Se você não planeja como expurgar, está apenas adiando o desastre.
Core Web Vitals não mentem. Eles são o farol que revela seu banco de dados gritando por socorro. Da próxima vez que seu TTFB subir, não olhe para o servidor web. Olhe para o Redis. E veja quantos transientes zumbis estão drenando sua vida.
P.S.: A micro-anedota que prometi? Em um projeto, um desenvolvedor setou TTL de 0 em um transient porque leu que ‘0 é infinito’. Descobrimos depois de 4 dias de pico de CPU. Não seja esse desenvolvedor.