Introdução: O Bug que ninguém queria investigar
Era uma terça-feira, 2h da manhã. O alerta no servidor disparou: latência média subiu de 80ms para 3,2s. O cliente, um e-commerce com 50 mil SKUs, estava perdendo vendas a cada minuto. A equipe de suporte já havia reiniciado o servidor, limpado cache e desativado todos os plugins. Nada resolvia. O problema parecia fantasma — até que olhei para o banco de dados com um olho clínico.
Essa história real ilustra o que acontece quando ignoramos um dos mecanismos mais subestimados do WordPress: a API de Transientes. Vamos dissecar o caso de forma forense, misturando princípios de arquitetura cloud e o desespero de uma madrugada de pânico.
O que é um Transiente e por que ele é perigoso?
No WordPress, transientes são dados temporários armazenados no banco de dados ou em memória (como Redis ou Memcached). Eles são usados para cachear resultados de consultas pesadas, como listas de produtos ou taxonomias. Mas aqui está o segredo: se mal configurados, eles se tornam bombas-relógio.
No caso do nosso e-commerce, o problema estava no plugin de cálculo de frete. Ele usava set_transient() para armazenar cotações de transportadoras com expiração de 12 horas. Só que, em vez de usar um objeto cache externo, o plugin estava escrevendo esses dados como opções _transient_xxx na tabela wp_options. O que acontece? A tabela wp_options cresce descontroladamente, e as queries ficam lentas.
A Anatomia do Desastre
Analisando o banco do cliente, encontrei mais de 200 mil transientes expirados. Sim, expirados — o WordPress não os limpa automaticamente em execuções normais. Cada requisição de página carregava centenas desses registros na memória. Pior: como o cache de objetos estava desativado, toda chamada de transiente batia no MySQL. Isso transformou um processo simples em um gargalo mortal.
Para piorar, o plugin usava wp_cache_set() e wp_cache_get() de forma inconsistente, ora usando o grupo padrão, ora um grupo personalizado. Isso gerava múltiplos caches para a mesma informação, consumindo ainda mais recursos.
Estudo de Caso Reverso: A Solução que pareceu mágica
Depois de identificar os transientes problemáticos, implementei uma estratégia de três camadas:
- Camada 1: Migrar todos os transientes para Redis usando o plugin Redis Object Cache, removendo-os da tabela
wp_options. Isso reduziu o tamanho da tabela de 2GB para 10MB. - Camada 2: Implementar um cron job que deleta transientes expirados a cada hora. Usei um script customizado com
$wpdb->query()para remover registrosWHERE option_name LIKE '_transient_timeout_%' AND option_value < UNIX_TIMESTAMP(). Medida simples, mas muitos ignoram. - Camada 3: Revisar o código do plugin e substituir
set_transient()porwp_cache_set()com timeout gerenciado manualmente via Redis TTL. Isso evitou a poluição do banco e deu controle fino sobre o cache.
O resultado? A latência caiu para 45ms em 24 horas. O cliente nem acreditou. Mas a lição maior é: muitas vezes o gargalo não está no que todo mundo olha (PHP, servidor web), mas no banco de dados mal tratado.
Por que isso é relevante para SEO e Core Web Vitals?
O Google penaliza sites lentos. O Tempo de Resposta do Servidor (TTFB) é um fator crítico. Transientes mal administrados aumentam o TTFB porque cada requisição precisa esperar o banco responder. Além disso, o LCP (Largest Contentful Paint) sofre se o carregamento de CSS/JS depender de queries lentas. Um estudo interno mostrou que 60% dos sites com TTFB > 1s têm problemas relacionados a transientes ou opções.
Como se prevenir: checklist para desenvolvedores
- Ative um cache de objetos persistente (Redis ou Memcached) em qualquer site com mais de 10 mil visitas/mês.
- Use
wp_cache_set()em vez deset_transient()sempre que possível. - Monitore o tamanho da tabela
wp_options— se passar de 100MB, é sinal de que há algo errado. - Evite
delete_expired_transients()em hooks de admin — faça via cron real. - Para WooCommerce, evite transientes em loops de produtos. Prefira índices de banco e cache de objetos.
Conclusão (não é uma conclusão)
O WordPress pode ser traiçoeiro. A simplicidade engana. Aquela opção de banco que parece inofensiva pode ser a causa de uma hecatombe de performance. A história do plugin fantasma ensina: nunca confie no cache padrão, sempre olhe o que está escrito nas opções escondidas. O Redis não é só para grandes sites; é para qualquer site que queira ser rápido. E lembre-se: otimização não é sobre fazer mais, é sobre fazer menos — menos consultas, menos dados, menos dor de cabeça.
Se você está enfrentando lentidão misteriosa, comece por aí. E boa sorte — você vai precisar.