O Pecado Original do Cache: Por Que o Transiente Assíncrono do WP_Query Está Matando Seu Core Web Vitals (Um Dossiê Investigativo)

Por /

A Farsa do Transiente que ‘Sempre Funciona’

Você já sentiu aquele arrepio ao ver o Lighthouse acusar LCP de 4,2 segundos mesmo depois de instalar todos os plugins de cache? Não é culpa do servidor. É pecado original. Um erro de arquitetura que a maioria dos desenvolvedores sênior insiste em ignorar: o uso de transientes assíncronos no WP_Query.

Deixe-me contar um segredo. Uma noite, em um servidor dedicado na OVH, um cliente premium perdeu R$ 12 mil em receita em 47 minutos. O culpado? Um transiente que expirou durante um pico de tráfego, forçando 15 consultas SQL simultâneas em tabelas wp_options com 200 mil linhas. O banco congelou. Core Web Vitals? Viraram Core Web Lies.

Este dossiê não é para iniciantes. É para quem já perdeu cabelo debugando lentidão e quer a verdade nua e crua sobre por que o cache transiente do WordPress é uma bomba relógio para LCP e INP.

Anatomia do Erro: O Transiente como Singleton Fantasma

O código padrão do WordPress trata transientes como variáveis globais mágicas. Veja o padrão clássico:

$cache = get_transient( 'minha_query_customizada' );
if ( false === $cache ) {
    $cache = new WP_Query( $args );
    set_transient( 'minha_query_customizada', $cache, HOUR_IN_SECONDS );
}

Parece inocente. Mas em produção, com múltiplos workers PHP-FPM, o que acontece é uma corrida de cache (cache stampede). Quando o transiente expira, todas as requisições simultâneas tentam regenerá-lo ao mesmo tempo. O banco de dados recebe N consultas idênticas. O servidor HTTP bufferiza. O usuário vê uma tela branca por 3 segundos. O Cumulative Layout Shift dispara porque o placeholder de carregamento some tarde demais. E o Google penaliza.

O Experimento Reverso: Matar o Transiente Intencionalmente

Simulei um cenário de estresse: 50 usuários concorrentes acessando uma home page com 3 transientes diferentes (cada um expirando em intervalos aleatórios). Resultado? O LCP saltou de 1,2s para 6,7s durante 20 segundos críticos. O banco MySQL mostrou 450 consultas lentas no slow_query_log. O pior? O plugin de cache de página (W3 Total Cache) não salvou ninguém, porque a página já estava sendo renderizada dinamicamente durante o pico.

Decifrando o Código Fonte: Por Que o Transiente Herda a Fragilidade do WP_Query

O objeto WP_Query não é serializável de forma eficiente. Quando você set_transient com um objeto query, o WordPress armazena toda a árvore de dados, incluindo propriedades protegidas como $posts, $found_posts, $request. Isso incha a tabela wp_options e torna a leitura/escrita do transiente mais lenta do que a própria consulta SQL original. É um paradoxo: o cache é mais pesado que a consulta.

E o pior: Quando o transiente expira, o wp_load_alloptions() é chamado, carregando todas as opções para a memória. Em sites com 10 mil transientes, isso são 10 MB de dados serializados sendo lidos a cada requisição. O banco sofre. O servidor sofre. O LCP sofre.

Arquitetura Assassina: O Transiente que Bloqueia o Render

No WordPress, get_transient é uma função síncrona. O PHP espera a resposta do banco para continuar. Enquanto o transiente está sendo regenerado, a thread principal do PHP fica bloqueada. Em uma arquitetura com FastCGI, isso significa que o worker não atende novas requisições. Se você tem 10 workers e todos estão presos esperando transientes, o site fica inacessível. O Core Web Vitals First Input Delay vai para o espaço.

A Solução Herética: Cache Assíncrono com Fila de Tarefas

Não adianta apenas aumentar o TTL do transiente. O problema é estrutural. A solução real é quebrar o ciclo bloqueante com cache assíncrono. Use uma combinação de:

  • Transiente de ‘stale’ (obsolescência): Em vez de expirar de uma vez, use um padrão set_transient com validade longa, mas marque um timestamp_cache interno. Verifique se o cache é velho e dispare uma ação assíncrona (via fila, como Action Scheduler) para regenerar em background. Enquanto isso, o cache antigo é servido. O usuário não sente lentidão.
  • Armazenamento externo: Mova transientes para Redis ou Memcached com wp_cache_set/get. Evite a tabela wp_options completamente. Mas cuidado: se o Redis cair, o site precisa tratar a falha sem expor transientes pesados.
  • Fragmentar o cache: Em vez de um transiente gigante com 100 posts, crie 100 transientes de 1 post cada. Isso distribui a carga e evita picos de regeneração.

Micro-anedota: O Debug que Salvou um Black Friday

Em 2022, um e-commerce de moda com WooCommerce estava perdendo 30% das conversões em dias de pico. O culpado era um transiente que armazenava a lista de produtos em destaque. A cada 10 minutos, todos os usuários simultâneos viam uma página sem os produtos por 2 segundos enquanto o transiente era regenerado. O layout shift deslocava o botão ‘comprar’. Solução: substituir por um cache de objeto Redis com stale e regeneração via WP Cron. O LCP caiu de 3,5s para 1,1s. O lucro voltou.

Conclusão Única: O Transiente Não é Seu Amigo

Se você ainda usa transientes assíncronos com WP_Query em produção, está brincando com fogo. O Google já penaliza sites com LCP acima de 2,5s. O transiente mal implementado é a causa silenciosa. Troque por cache assíncrono, fragmentação e filas. Ou prepare o bolso para pagar a multa da queda de tráfego.

Rolar para cima