O Caso do Plugin Fantasma
Você já sentiu aquele arrepio na nuca quando um site carrega, mas algo está errado? O Core Web Vitals grita, mas ninguém ouve. Pois é, eu já vi isso acontecer. E não foi em um site qualquer. Foram milhares.
Vamos direto ao ponto: um plugin de cache popular, usado por milhões, estava silenciosamente quebrando o Largest Contentful Paint (LCP) e o Cumulative Layout Shift (CLS) em sites que, aparentemente, estavam perfeitos. O culpado? Um conflito de banco de dados que ninguém esperava.
A Descoberta Inusitada
Eu estava debugando um cliente premium – um site de notícias com tráfego pesado. Tudo parecia normal: o cache estava ativo, as páginas carregavam em 0.8s no back-end. Mas o Lighthouse insistia: LCP de 4s, CLS de 0.3.
Comecei a examinar os logs. Nada. Até que olhei para o banco de dados. Era uma segunda-feira à noite, e eu estava prestes a desistir quando notei algo: a tabela wp_options estava com 2 milhões de linhas de lixo. O plugin de cache, toda vez que gerava uma página, escrevia um registro de metadados redundante. E nunca limpava.
Isso forçava o MySQL a fazer full scans a cada requisição. O tempo de query, que era de 2ms, saltou para 120ms. Multiplique por 5 queries por página… e você tem 600ms de atraso só no banco. Sem contar que o layout shift acontecia porque o cache servia o HTML antes de o banco terminar de escrever os metadados, resultando em elementos que apareciam depois.
O Efeito Dominó
Mas o pior ainda estava por vir. Eu investiguei outros 12 sites com o mesmo problema – todos usando o mesmo plugin. Em um deles, um site de e-commerce, o LCP chegava a 7s em dispositivos móveis. O motivo? O plugin, ao invés de usar transients, usava wp_options para armazenar miniaturas de cache de objetos. Um erro bobo de programação, mas que passou despercebido por anos.
A solução? Implementei um sistema de limpeza programada: a cada 10 minutos, um cron job deletava registros órfãos. O LCP caiu para 1.2s, o CLS para 0.02. Mas o mais assustador: o plugin nunca foi atualizado. Os devs não sabiam. A comunidade não sabia. Mil sites sofrendo em silêncio.
Micro-anedota dos Bastidores
Numa madrugada de sexta, eu estava em uma call com o CTO de uma startup. Ele me disse: ‘O site está rápido, mas o PageSpeed Insights dá nota 45. É um bug do Google, certeza.’ Mostrei a ele a tabela wp_options com 800 mil linhas inúteis. Ele ficou pálido. ‘Isso é um problema de 1 milhão de dólares para a gente’, ele murmurou. E não era mentira.
Lições e Soluções
Se você mantém sites WordPress, nunca confie cegamente em plugins de cache populares. Sempre monitore o banco de dados. Use SHOW TABLE STATUS para ver o tamanho real da tabela wp_options. Implemente ferramentas como Query Monitor para detectar lentidão.
E mais: teste o Core Web Vitals em páginas cacheadas e não cacheadas. O bug do cache fantasma só aparece quando o cache está ativo – porque o conflito está na geração do cache, não na entrega.
Se você já teve um site com LCP inexplicável, talvez seja hora de olhar para o banco. O culpado pode estar escondido em uma tabela que você nunca imaginou.
E lembre-se: o maior erro técnico é achar que um plugin famoso está imune a bugs. No fim, a engenharia é sobre questionar tudo.