Front-end
Core Web Vitals verdes em WordPress sem plugin de cache
Plugin de cache é analgésico. Corta a dor por um tempo, mas o problema estrutural continua lá. O que de fato move LCP, INP e CLS em WordPress quando você para de terceirizar a decisão.
· 9 min de leitura
A pergunta mais comum que recebo de donos de site WordPress é "qual plugin de cache você recomenda". A resposta honesta decepciona, que é "nenhum, até a gente entender por que seu site está lento".
Plugin de cache mascara sintoma. Se o seu LCP é 4 segundos sem cache e 1,8 segundo com cache, o site continua estruturalmente pesado, só que escondido atrás de uma camada de HTML estático. Na primeira visita de um usuário novo (cache miss), os 4 segundos voltam. No Google CrUX, essas visitas pesam.
O caminho é mais longo, mas entrega LCP estável independente de cache. Cinco intervenções, em ordem de ROI.
1. Budget de imagem na pasta uploads
A primeira auditoria que rodo em qualquer WordPress lento é find wp-content/uploads -name "*.jpg" -size +300k. Quase sempre aparecem dezenas de imagens de 2 a 5 MB subidas direto do celular, sem compressão, sem redimensionamento.
Intervenção: ativar geração automática de AVIF e WebP (o próprio core do WP 6.5+ faz isso), definir tamanhos de imagem no functions.php que cobrem os breakpoints reais do tema (não os 7 defaults do WP), e forçar decoding="async" + loading="lazy" em todas as imagens abaixo da fold.
Resultado típico: LCP cai 30 a 40%. Zero cache envolvido.
2. Critical CSS inline no head
Todo WordPress carrega um style.css do tema via <link rel="stylesheet">. Esse link bloqueia a renderização até baixar e parsear o CSS inteiro. Se seu tema tem 80 KB de CSS, você acabou de pagar ~150ms de LCP antes mesmo de começar.
Intervenção: extrair o CSS crítico (o que é visível na primeira dobra) com critical ou penthouse no build, inline-ar no <head>, e carregar o resto com media="print" onload="this.media='all'". Trabalho de uma tarde. Ganho permanente.
3. JavaScript que não é crítico, deferido ou removido
WordPress clássico carrega jQuery por default, e a maioria dos plugins empilha JS no wp_head. Resultado: 300 a 800 KB de JS antes da primeira renderização.
Regra prática: nenhum JS no <head> deve ser síncrono. Ou é async (GTM, analytics), ou é defer (scripts do tema), ou é removido. Pra plugins barulhentos, wp_dequeue_script em páginas que não precisam deles (por exemplo, formulários de contato só carregados em /contato).
Ganho: INP cai dramaticamente. Main thread livre pra o que importa.
4. Font loading disciplinado
FOIT (Flash of Invisible Text) é um dos maiores atrasos em LCP. Resolve com font-display: swap no @font-face e <link rel="preload" as="font" type="font/woff2" crossorigin> pra fonte crítica do primeiro viewport.
Bônus: usar a system font stack na base (-apple-system, BlinkMacSystemFont, 'Segoe UI', ...) elimina o problema inteiro. É o que faço no portfólio. LCP abaixo de 1s em 3G.
5. Eliminar redirecionamentos na homepage
Conferir com curl -IL https://seudominio.com. Cada 301/302 no caminho pra homepage é um RTT. HTTP → HTTPS, não-www → www, trailing slash: esses três juntos podem adicionar 500ms. Configurar o servidor pra responder direto na URL canônica (uma única linha de nginx/htaccess) vale mais que qualquer plugin de cache.
Por que cache entra por último (e às vezes não entra)
Depois das cinco intervenções acima, se o site ainda está lento, aí faz sentido considerar cache. Mas na maioria dos projetos que audito, os cinco passos acima já deixam o Lighthouse verde e o CrUX estabilizado. Cache vira cereja.
A razão pela qual isso não é senso comum é simples, que é a indústria de plugins de cache ganha vendendo o atalho. O atalho funciona até a primeira falha de cache, e aí o problema volta, só que mais difícil de debugar porque agora tem uma camada a mais no caminho.
Performance em WordPress não exige framework novo nem stack exótica. Exige disciplina com o que o core do WP já oferece e auditoria do que o tema e os plugins estão empilhando no caminho. O resto é cache camuflando sintoma.