Core Web Vitals no WordPress: o guia completo

Core Web Vitals são três métricas do Google medidas em usuários reais do Chrome: Largest Contentful Paint (LCP) para carregamento, Interaction to Next Paint (INP) para responsividade e Cumulative Layout Shift (CLS) para estabilidade visual. Uma página WordPress passa quando o percentil 75 dos dados de campo fica em até 2,5 segundos de LCP, 200 milissegundos de INP e 0,1 de CLS. Para melhorar, comece pelo servidor (cache de página, object cache, PHP), depois a imagem do LCP, depois o JavaScript de plugins e de terceiros e, por fim, os layout shifts causados por fontes, banners e anúncios. Confirme cada mudança nos dados de campo, não só no Lighthouse.

Meu trabalho é auditar sites WordPress, e a história se repete. A maioria dos sites WordPress é lenta por motivos estruturais: hospedagem, banco de dados, assets que bloqueiam a renderização e scripts de terceiros. Instalar mais um plugin de otimização em cima dessa estrutura raramente muda os dados de campo por muito tempo. Este guia mostra a ordem em que eu trabalho, com um guia mais aprofundado de cada métrica linkado na seção dela.

O que são Core Web Vitals e quais são os limites?

O Google avalia cada métrica no percentil 75 (p75) dos carregamentos de página, separando mobile e desktop. Ou seja, uma página está “boa” em LCP quando pelo menos 75% das visitas reais viram o maior elemento renderizar em 2,5 segundos ou menos. Média esconde as visitas lentas. O p75 obriga você a se preocupar com quem acessa de um Android intermediário numa conexão fraca, que muitas vezes é a maior parte do seu tráfego.

O INP substituiu o First Input Delay (FID) como Core Web Vital em março de 2024. O FID só media a espera até o navegador começar a tratar a primeira interação. O INP olha todas as interações da visita e inclui o tempo de rodar os handlers e pintar o resultado, o que deixa a métrica bem mais difícil de passar em sites WordPress carregados de JavaScript.

O Time to First Byte (TTFB) não está na lista. É uma métrica de diagnóstico, e o web.dev considera bom um valor de até 0,8 segundo. Mesmo assim ele pesa muito: o navegador não renderiza nada antes de o HTML chegar, então um TTFB lento consome o orçamento do LCP antes de qualquer imagem carregar. Explico isso em o que o TTFB mede no WordPress e como reduzir.

Como medir Core Web Vitals: dados de campo ou de laboratório?

Dados de campo vêm de visitas reais. A fonte do Google é o Chrome User Experience Report (CrUX), que coleta métricas de usuários do Chrome e publica tudo numa janela móvel de 28 dias. São esses os dados por trás da avaliação de Core Web Vitals no PageSpeed Insights e do relatório de Core Web Vitals no Search Console. Quando o Google fala dos seus Core Web Vitals, é desses dados que ele está falando.

Dados de laboratório vêm de um único carregamento simulado, normalmente o Lighthouse rodando num perfil de dispositivo com throttling. É repetível e ótimo para depurar, mas é uma visita, num dispositivo, com cache vazio. O Lighthouse também não consegue medir INP, porque ninguém clica em nada durante um teste de laboratório. No lugar ele mostra o Total Blocking Time (TBT), que tem correlação com o INP sem ser a mesma coisa. Detalho essa diferença em Core Web Vitals: dados de campo vs laboratório.

Estas são as ferramentas que uso, na ordem em que abro cada uma:

• O relatório de Core Web Vitals do Search Console mostra quais grupos de URLs reprovam, por métrica e dispositivo. O Google agrupa páginas parecidas, então um template ruim pode marcar centenas de URLs de uma vez.
• No PageSpeed Insights, a parte de cima traz os dados de campo do CrUX para a URL (ou para a origem inteira, quando a URL não tem tráfego suficiente). A parte de baixo é um teste de laboratório do Lighthouse. Leia a de cima primeiro.
• A API do CrUX e o dataset do CrUX no BigQuery servem para ver histórico e comparar origens, templates ou concorrentes.
• A biblioteca JavaScript web-vitals dá monitoramento de usuários reais (RUM) no seu próprio site. O build de attribution mostra qual elemento foi o LCP, qual interação foi lenta e qual elemento se deslocou.
• O painel Performance do Chrome DevTools serve para reproduzir um problema específico localmente, com throttling de CPU ligado.

Não esqueça a janela de 28 dias. Uma correção publicada hoje só substitui totalmente os dados antigos no CrUX umas quatro semanas depois. Se você precisa de retorno mais rápido, colete seus próprios dados de campo com a biblioteca web-vitals em vez de atualizar o PageSpeed Insights toda manhã.

Onde os sites WordPress reprovam nos Core Web Vitals?

Nas auditorias vejo as mesmas falhas o tempo todo, em sites muito diferentes. Mudam o tema, o builder e a hospedagem. As causas mudam pouco.

• HTML lento ou sem cache: falta cache de página, ou o cache de página é ignorado por causa de cookies e query strings. Falta object cache persistente, o autoload da wp_options está inchado, há queries lentas de plugin, a versão do PHP é antiga. Tudo isso aparece como TTFB, e o TTFB faz parte do LCP.
• A imagem do LCP tratada como qualquer outra: lazy load aplicado por um plugin, imagem injetada por script de slider, definida como background no CSS (que o navegador descobre tarde) ou servida com 2.000 pixels de largura para um celular.
• Assets de plugin em todas as páginas: o plugin de formulário carrega scripts e estilos no blog, o slider carrega em páginas sem slider, os assets do WooCommerce carregam em landing pages.
• Scripts de terceiros: tag managers cheios de tags antigas, widgets de chat, plataformas de consentimento, heatmaps, scripts de anúncio. Eles disputam a main thread com o seu próprio código, e é aí que o INP se perde.
• Tamanho do DOM de page builders: os wrappers aninhados do Elementor, do Divi e de builders parecidos deixam cada recálculo de estilo e cada layout mais caro. Isso piora o INP e soma peso de CSS que atrasa o LCP.
• Conteúdo que chega atrasado: web fonts que trocam com métricas diferentes, barras de cookies e de promoção empurradas no topo da página, anúncios e embeds sem espaço reservado. Isso é CLS.

LCP no WordPress: o que atrasa a maior renderização?

O tempo de LCP se divide em quatro partes. O Time to First Byte é a espera pelo HTML. O resource load delay é o intervalo entre o primeiro byte e o momento em que o navegador começa a baixar o recurso do LCP. O resource load duration é o download em si. O element render delay é o tempo entre o fim do download e o elemento aparecer na tela. Cada parte tem suas causas no WordPress, e corrigir a parte errada é como as equipes perdem semanas.

Num post típico de WordPress, o elemento LCP é a imagem destacada. Na home costuma ser uma imagem hero ou um título grande, e na página de produto é a imagem principal do produto. O core do WordPress ajuda aqui: desde o WordPress 6.3 ele adiciona fetchpriority="high" na imagem que considera mais provável de ser o LCP e deixa de aplicar loading="lazy" nas imagens perto do topo da página. Nas auditorias, encontro com frequência um plugin de lazy load, uma configuração do builder ou código customizado do tema desfazendo exatamente isso.

Os outros suspeitos de sempre são imagens hero definidas como background no CSS, sliders que montam o primeiro slide com JavaScript, atributos sizes ausentes ou errados que fazem o navegador baixar a imagem de desktop no celular, e CSS que bloqueia a renderização vindo do tema e de cada plugin ativo. O processo completo, incluindo como ler o breakdown do LCP, está em como melhorar o LCP no WordPress.

INP no WordPress: por que os cliques parecem lentos?

O INP mede três fases de uma interação. O input delay é o tempo que o navegador espera até conseguir rodar o seu event handler, normalmente porque outra tarefa está ocupando a main thread. O processing duration é o tempo que os seus handlers levam. O presentation delay é o tempo de recalcular estilos, fazer o layout e pintar o próximo frame. O INP de uma página fica perto da interação mais lenta que o visitante teve, então um mega menu pesado pode reprovar um template inteiro.

Sites WordPress perdem INP em lugares previsíveis: tags de terceiros disparando enquanto o usuário tenta tocar na tela, plugins jQuery que fazem muito trabalho a cada clique, handlers de variação e de carrinho do WooCommerce, filtros facetados que renderizam de novo pedaços grandes da página e DOMs enormes de builder que deixam cada frame caro de pintar. Os recursos de “atrasar JavaScript até a interação do usuário” dos plugins de cache merecem atenção especial. Eles podem deixar as notas de laboratório lindas enquanto jogam o custo de carregar todos os scripts no primeiro toque do visitante.

O WordPress também oferece ferramentas aqui. Desde o WordPress 6.3 dá para registrar scripts com estratégia de carregamento defer ou async, e desde o 6.5 a Interactivity API move os blocos interativos do core com um runtime pequeno e compartilhado, em vez de uma biblioteca por plugin. Como encontrar a interação lenta e corrigir está em como corrigir o INP no WordPress.

CLS no WordPress: o que mexe no layout?

O CLS dá nota para quanto o conteúdo visível se move sem o usuário pedir. Layout shifts que acontecem até 500 milissegundos depois de uma ação do usuário não contam, e a nota considera a pior rajada de deslocamentos durante a visita inteira, não só no carregamento. Por isso o CLS no campo costuma ser pior que no Lighthouse: as ferramentas de laboratório só observam o carregamento, enquanto o visitante real rola a página, e conteúdo com lazy load, anúncios e elementos sticky continuam empurrando coisas.

As causas no WordPress são concretas. Imagens em templates do tema ou em widgets do builder sem width e height (o WordPress adiciona esses atributos nas imagens do conteúdo do post, mas código customizado de template muitas vezes não). Web fonts que entram com métricas diferentes e refazem o fluxo de todos os parágrafos. Banners de cookies e barras de promoção inseridos acima do header. Anúncios, embeds do YouTube e de redes sociais sem espaço reservado. Plugins de otimização que atrasam ou removem CSS, fazendo a página renderizar sem estilo e depois pular. A correção de cada caso está em como reduzir o CLS no WordPress.

TTFB é um Core Web Vital?

Não. O TTFB é uma métrica de diagnóstico que o Google não usa na avaliação de Core Web Vitals. Ele mede o tempo do início da navegação até o primeiro byte da resposta HTML, incluindo redirecionamentos, DNS, abertura de conexão e processamento no servidor. O Google deixou o TTFB de fora porque um TTFB rápido com renderização lenta continua sendo uma página lenta, e arquiteturas diferentes chegam a um bom LCP com TTFBs diferentes.

No WordPress, o TTFB depende principalmente de o PHP precisar rodar ou não. Um cache de página entrega HTML já armazenado e o WordPress nem chega a carregar. Um object cache persistente (Redis ou Memcached com o drop-in object-cache.php) acelera as requisições que não podem ir para o cache, como usuários logados, carrinho e checkout. Um edge cache entrega o HTML de um ponto próximo do visitante. Se você não sabe qual camada está faltando, leia page cache vs object cache vs edge cache: qual você precisa.

Em que ordem corrigir os Core Web Vitals no WordPress?

Esta é a ordem de correção que sigo nas auditorias. Ela começa pelas mudanças que ajudam todos os templates de uma vez e deixa o trabalho caro para quando você já sabe exatamente onde ele é necessário.

1. Segmente os dados de campo. Descubra qual métrica reprova, se no mobile ou no desktop, e em quais templates (home, post, página, produto, categoria, checkout). Os grupos do Search Console aceleram isso. Não otimize uma página que ninguém visita.
2. Corrija a resposta do servidor: cache de página com regras de bypass corretas, object cache persistente, uma versão do PHP com suporte e OPcache, autoload limpo. Confira se query strings de marketing como utm_source não estão gerando cache miss.
3. Corrija o elemento LCP em cada template que reprova: tamanho certo de imagem, srcset e sizes que batem com o layout, sem lazy load, com fetchpriority="high" e uma tag img no HTML em vez de background no CSS ou script de slider.
4. Tire os assets de plugin de onde eles não são usados. Faça o dequeue de scripts e estilos por template com wp_dequeue_script() e wp_dequeue_style(), ou troque o plugin. Carregue scripts com a estratégia defer quando o plugin permitir.
5. Audite os scripts de terceiros. Cada tag precisa de um responsável e de um motivo. Remova o que ninguém usa, carregue o resto depois que a página ficar interativa quando o negócio aceitar isso, e teste as ferramentas de consentimento e de chat em hardware mobile.
6. Reduza o trabalho na main thread para o INP. Quebre tarefas longas, dê um retorno visual antes do processamento pesado e diminua o DOM nos templates feitos com builder.
7. Corrija os layout shifts: dimensões em toda imagem e todo embed, espaço reservado para anúncios e banners, carregamento de fontes que não refaz o fluxo do texto e nada de flash sem estilo causado pela otimização de CSS.
8. Monitore. Mantenha o monitoramento de usuários reais rodando, acompanhe o CrUX ao longo da janela de 28 dias e coloque uma checagem de performance no deploy para que um plugin novo não desfaça o trabalho.

A ordem importa porque as métricas têm causas em comum. A resposta do servidor faz parte do LCP. O JavaScript de plugins afeta o LCP (bloqueio de renderização) e o INP (trabalho na main thread). A otimização de CSS pode ajudar o LCP e quebrar o CLS. Se você começa pelo passo 6 num site sem cache de página, está polindo a camada errada. Se quiser essa ordem aplicada ao seu site, com os dados de campo de cada template, é o que entrego na auditoria de performance WordPress.

Plugins de performance resolvem os Core Web Vitals?

Eles resolvem parte do trabalho. Um bom plugin de cache traz cache de página, otimização de arquivos, scripts atrasados e às vezes CSS crítico. Nada disso conserta uma hospedagem lenta, um banco com megabytes de options em autoload, um layout de builder com milhares de elementos ou um tag manager com quarenta tags. Trato esses plugins como ferramentas que configuro site a site, e testo cada recurso contra os dados de campo.

Dois recursos causam a maior parte das regressões que encontro. O “remover CSS não utilizado” pode tirar estilos que a página precisa depois de uma interação ou em outro tamanho de tela, o que gera layout shifts e componentes quebrados. O “atrasar JavaScript” pode melhorar o LCP e as notas de laboratório enquanto empurra a execução dos scripts para a primeira interação, e isso aparece depois como INP ruim no CrUX. Nenhum dos dois é ruim por si só. Os dois precisam ser testados em templates reais, num celular.

Core Web Vitals afetam o ranking no Google?

Afetam, mas menos do que muitas ferramentas dão a entender. Core Web Vitals fazem parte dos sinais de experiência na página usados pelos sistemas de ranking do Google. O próprio Google diz que continua mostrando o conteúdo mais relevante mesmo quando a experiência na página dele é pior que a de um concorrente. Na prática, uma página rápida com conteúdo fraco não ganha de uma página lenta que responde melhor à pergunta.

Eu corrijo Core Web Vitals porque página lenta perde visitante, e no WordPress esse trabalho costuma resolver problemas estruturais reais no caminho: servidores sobrecarregados, plugins que ninguém precisa, scripts sem dono. O ganho de ranking existe, mas não é o motivo principal.

Perguntas frequentes

Por que o Lighthouse mostra nota alta e a avaliação de Core Web Vitals reprova?

Porque medem coisas diferentes. O Lighthouse é um carregamento simulado em laboratório. A avaliação usa 28 dias de visitas reais do CrUX no percentil 75. Visitantes reais usam celulares e redes mais lentos, chegam com estados de cache diferentes, interagem com a página e rolam a tela. O Lighthouse não mede INP. Quando os dois discordam, confie nos dados de campo e use o laboratório só para depurar.

Quanto tempo leva para as correções aparecerem nos Core Web Vitals?

O CrUX usa uma janela móvel de 28 dias, então uma correção leva umas quatro semanas para substituir totalmente os dados antigos no PageSpeed Insights e no Search Console. O p75 vai mudando aos poucos nesse período. Depois disso, a validação do Search Console pode levar mais tempo. Rode seu próprio monitoramento de usuários reais se precisar confirmar uma correção em poucos dias.

Por que não aparecem dados de campo da minha página no PageSpeed Insights?

O CrUX só publica dados de URLs e origens com tráfego elegível suficiente. Se a página não se qualifica, o PageSpeed Insights mostra os dados da origem ou não mostra nada. Páginas com pouco tráfego continuam sendo avaliadas no Search Console pelo grupo de URLs a que pertencem, e é por isso que corrigir um template costuma valer mais que corrigir URLs soltas.

Uma CDN resolve os Core Web Vitals no WordPress?

Uma CDN entrega imagens, CSS e JavaScript de pontos mais próximos, o que ajuda na parte de download do LCP. Se ela também fizer cache do HTML na borda, pode derrubar bastante o TTFB para visitantes anônimos. Ela não resolve trabalho na main thread, então não conserta o INP, e não faz nada pelos layout shifts causados por fontes, banners ou dimensões ausentes.

Elementor é ruim para os Core Web Vitals?

Sites em Elementor conseguem passar nos Core Web Vitals, mas já começam com mais trabalho pela frente. Os problemas comuns são DOM grande, muitos assets de widgets e CSS global pesado. Os layouts com containers do Elementor geram menos wrappers que a estrutura antiga de seções e colunas, então vale planejar a migração dos layouts antigos para containers em qualquer site Elementor que reprove em INP ou LCP.

Ainda preciso me preocupar com o First Input Delay?

Não. O INP substituiu o FID como Core Web Vital em março de 2024, e o Google não mostra mais o FID nas ferramentas de Core Web Vitals. Se um relatório antigo ou um plugin ainda mostra FID, ignore esse número e olhe o INP nos seus dados de campo.

Peça uma auditoria de Core Web Vitals para o seu site WordPress

Se os seus dados de campo reprovam e você não sabe por quê, comece por um diagnóstico em vez de mais um plugin. Eu audito sites WordPress métrica por métrica e template por template, e entrego uma ordem de correção baseada em dados de campo. Você pode ler mais sobre como trabalho como consultor de Core Web Vitals. Quando também é preciso mexer no código, a implementação fica com o time de performance da WebOption.