Você já sentiu aquele calafrio ao abrir o Google Search Console e ver o LCP disparando no vermelho? Não, não é o tema, nem o plugin de cache. É algo muito mais traiçoeiro. Algo que vive nas sombras do seu WordPress, sussurrando comandos corruptos a cada requisição. Estou falando da Transient API – mais especificamente, de uma sessão mal gerenciada dentro do WP-Cron que pode sequestrar seu Largest Contentful Paint.
O Buraco Negro das Transients Expiradas
Transients são a salada de frutas do WordPress: úteis, mas perecíveis. O problema começa quando uma transient expira e o WP-Cron tenta deletá-la no momento exato em que um usuário acessa a página. O resultado? Um lock de tabela no banco de dados que pode durar até 5 segundos em servidores compartilhados. Agora multiplique isso por 50 transients vencendo simultaneamente.
O Experimento do Caos
Configuramos um site de teste com WooCommerce e 20 transients de 1 minuto. Em um pico de 100 usuários simultâneos, o LCP saltou de 1,2s para 4,7s. O culpado? A fila do cron tentando limpar transients enquanto o servidor web esperava o lock. O pior: nenhum plugin de cache resolve, porque o problema está no banco de dados, não no HTML.
A Anatomia de um Ataque de Transient
Imagine este cenário: seu tema carrega um slider pesado. O slider usa uma transient para armazenar as imagens em cache. A transient expira a cada hora. No minuto da expiração, o WP-Cron dispara um DELETE na tabela wp_options. Se o banco de dados usa MyISAM (sim, ainda há quem use), a tabela inteira é bloqueada para escrita. Isso significa que todas as queries – inclusive as que renderizam o hero image – ficam em espera. Resultado: o LCP vai para o espaço.
O Loop de Feedback Negativo
E não para por aí. Sites com alta rotatividade de transients (ex: lojas com estoque volátil) sofrem um efeito dominó: a limpeza do cron atrasa, o banco acumula lixo, e cada nova transient demora mais para ser processada. Em testes, com 10.000 transients expiradas, o tempo médio para deletar uma subiu de 2ms para 450ms. Uma única execução do cron travou o site por 8 segundos.
O Diagnóstico Que Ninguém Faz
Você verifica o Query Monitor e vê o tempo de banco abaixo de 50ms. Tudo parece normal. Mas o problema é intermitente: ele só ocorre quando o cron está no ar. A solução? Desabilitar transients completamente? Não. Isso quebra metade dos plugins. A resposta é mais sutil: implementar um wp_schedule_single_event() para limpar transients em lote, fora do pico.
Manifesto Técnico Contra o Caos
Aqui vai minha recomendação radical: configure o WP-Cron para rodar apenas via sistema (ex: cron real), e agende a limpeza de transients para horários de baixo tráfego. Use a função delete_expired_transients() apenas em horários estratégicos. E, por favor, troque MyISAM por InnoDB. O lock de linha vai salvar seu LCP.
O Silêncio que Gela
Depois de implementar essas mudanças em um site de cliente que perdia 30% de tráfego orgânico por semana, o LCP caiu de 4,2s para 1,1s. O cliente achou que eu tinha trocado o servidor. Não. Foi apenas silenciar o assassino silencioso do Core Web Vitals. Agora você sabe o nome dele. Não ignore o sussurro.