Site lento mesmo depois de otimizado: a camada de cache Varnish escondida que travava o LCP de Thomas Fragoso
LCP de 19,8s mesmo após otimização de Core Web Vitals. A causa: cache Varnish do Cloudways nunca purgado, escondendo o ganho real.
O problema
Você otimiza imagens, ajusta o código, mede de novo — e o LCP continua travado no mesmo número absurdo. Antes de suspeitar da própria otimização, vale suspeitar de uma camada de cache que ninguém sabe que existe. Foi o que aconteceu com o site de Thomas Fragoso, tatuador que atende em Málaga, na Espanha: o projeto era melhorar Core Web Vitals para o público europeu, sem trocar de servidor (Cloudways, datacenter nos EUA, decisão já fechada do cliente). Baseline: performance mobile 56/100, LCP crítico de 19,8 segundos na página /espanol/ — a landing principal de captação de leads.
O que não podia quebrar
WP Rocket, GTM e Facebook Pixel já estavam ativos e alimentando os anúncios do cliente — a regra do projeto era otimizar, nunca remover. O formulário de captação de lista de espera era a conversão principal e precisava sobreviver a cada mudança, testado após cada etapa.
Os ganhos sem depender de licença
Imagem do LCP comprimida de 627KB para 80KB. Feed do Instagram diferido via IntersectionObserver, carregando só quando a seção entra na tela. Cache de objeto Redis instalado. Banco de dados limpo de 1.171 revisões e 28 transients. Como a licença WP Rocket da conta antiga estava expirada, um Critical CSS manual via mu-plugin próprio resolveu o CSS bloqueante sem depender de plugin pago — 100% reversível.
A investigação
Quando o cliente comprou a própria licença WP Rocket e a Remove Unused CSS oficial finalmente rodou pela primeira vez, ela falhou silenciosamente — e o site voltou a servir CSS bloqueante, como se todo o trabalho anterior tivesse sumido. A causa não estava no WP Rocket, no Redis nem no Cloudflare: era uma camada de cache Varnish do próprio Cloudways, nunca purgada neste projeto, servindo uma versão antiga e quebrada da página. Localizada batendo direto no IP do servidor (contornando o Cloudflare) e confirmada via `varnishadm` — resolvida sem precisar de acesso root.
Resultado
Depois do purge do Varnish: LCP mobile caiu de 19,8s para a faixa de 13–14s nas medições oficiais do PageSpeed Insights, e desktop foi de LCP 1,4s para 1,9s dentro da margem de ruído — GTmetrix manual (metodologia paralela, sem o throttling agressivo do PSI) registrou 98% de performance e LCP de 838ms em `/espanol/`. Formulário de captação, GTM e Facebook Pixel confirmados intactos em cada etapa.