Quando o PageSpeed Insights mostra a avaliação das Core Web Vitals reprovada, isso quer dizer que, nos últimos 28 dias de visitas reais no Chrome, pelo menos uma entre LCP, INP e CLS ficou acima do limite bom no percentil 75. É um veredito sobre dados de campo, não sobre a nota do Lighthouse que aparece logo abaixo. Para resolver, descubra qual métrica reprovou, veja se o resultado é da URL ou da origem inteira e se é do celular ou do desktop, ache o template que causa o problema, corrija a causa e espere a janela de 28 dias virar antes de julgar o resultado.
Essa é uma das perguntas que mais recebo, quase sempre com um print mostrando “Reprovada” em vermelho no topo e um 90 e tantos verde mais embaixo. As duas coisas são verdade ao mesmo tempo. O número verde é uma visita simulada. A palavra vermelha é o seu público de verdade.
O que significa a avaliação das Core Web Vitals reprovada?
O PageSpeed Insights lê o percentil 75 de cada Core Web Vital no Chrome User Experience Report (CrUX). A avaliação é aprovada quando as três estão na faixa boa:
- LCP em até 2,5 segundos.
- INP em até 200 milissegundos.
- CLS em até 0,1.
Se qualquer uma passar desse limite, a avaliação reprova, mesmo que caia só em “precisa melhorar” e não em “ruim”. Quando não há dado suficiente de INP, o PageSpeed Insights ainda pode aprovar a página com base em LCP e CLS.
Dois detalhes mudam a leitura. Primeiro, existe a opção entre “Esta URL” e “Origem”. Uma URL com pouco tráfego pode ter só dado de origem, e aí o veredito é sobre o site inteiro. Segundo, celular e desktop são relatórios separados. Reprovar no celular e passar no desktop é o padrão que mais vejo em WordPress.
Por que reprova se a minha nota no PageSpeed é alta?
Porque a nota e a avaliação vêm de dados diferentes. A nota de performance é calculada pelo Lighthouse a partir de uma execução de laboratório: um aparelho emulado, uma rede simulada, nenhuma interação real. A avaliação vem das visitas reais, em celulares reais.
Algumas diferenças que encontro sempre:
- Problema de INP não aparece num carregamento de laboratório, porque ninguém clica. O Lighthouse mostra o Total Blocking Time, que só dá uma pista.
- Visitante real chega com cache frio, em celular mais velho, às vezes com banner de consentimento e espaço de anúncio que a execução de laboratório nem vê.
- Deslocamentos de layout que acontecem depois do carregamento, enquanto a pessoa rola a tela, passam batido num teste de laboratório que termina cedo.
- O teste de laboratório pode pegar a página em cache, enquanto muitos visitantes reais, logados ou com parâmetros na URL, passam direto pelo cache.
As ferramentas em si estão comparadas em PageSpeed Insights vs Lighthouse, e a ideia geral por trás da diferença está em dados de campo vs dados de laboratório.
Passo a passo para corrigir uma avaliação reprovada
- Identifique a métrica que reprovou. Na seção de dados de campo, procure a métrica em laranja ou vermelho. Anote o dispositivo e se você está olhando dado de URL ou de origem.
- Ache os templates afetados. No Google Search Console, abra o relatório Core Web Vitals. Ele agrupa URLs com problemas parecidos e mostra uma URL de exemplo de cada grupo. No WordPress, um grupo costuma corresponder a um template: post, página de produto, arquivo de categoria.
- Reproduza em laboratório. Abra a URL de exemplo no Chrome DevTools, limite CPU e rede e grave com o painel Performance. Encontre o elemento LCP, as tarefas longas ou os deslocamentos de layout.
- Corrija a causa, não o sintoma. Uma correção no tema ou no servidor ajuda todas as páginas que usam aquilo. Uma correção feita numa página só raramente mexe com um grupo inteiro.
- Valide. Confirme no Lighthouse que a métrica de laboratório mudou. Depois, no Search Console, use “Validar correção” no problema. O Search Console acompanha o grupo por 28 dias.
- Espere o dado de campo. O CrUX é uma janela móvel de 28 dias, então o percentil 75 muda aos poucos. Conferir todo dia só gera ansiedade.
Qual métrica reprovou? Onde eu olho primeiro
| Métrica reprovada | Causas comuns no WordPress | Onde ler mais |
|---|---|---|
| LCP | Sem cache de página ou TTFB lento, imagem de destaque com lazy load, imagem grande demais no celular, CSS e JavaScript bloqueando a renderização | LCP no WordPress |
| INP | JavaScript pesado de builder ou plugin, tags de terceiros (chat, analytics, anúncios), DOM muito grande | INP no WordPress |
| CLS | Imagens e embeds sem dimensões, troca de fonte, banners inseridos acima do conteúdo, anúncios sem espaço reservado | CLS no WordPress |
Quando o LCP reprova, sempre confiro o TTFB na mesma seção de campo. Ele não é Core Web Vital, mas um primeiro byte acima de 0,8 segundo consome boa parte do orçamento do LCP antes de o navegador conseguir pedir a imagem. O guia de TTFB no WordPress trata disso.
Por que a origem reprova se a minha página passa?
O resultado da origem agrega todas as páginas do site que recebem tráfego. Uma home rápida não resolve se a maioria das visitas cai em páginas de produto lentas ou em posts antigos cheios de embed. Se a origem reprova e a URL que você testou passa, o problema está em outros templates. É no Search Console que você encontra quais.
O contrário também acontece. Uma URL específica reprova enquanto a origem passa, geralmente porque aquela página tem algo só dela: um vídeo no topo, uma tabela enorme, um plugin de formulário que só carrega ali.
O que não resolve uma avaliação reprovada
Algumas tentativas que vejo e que não mudam o dado de campo, ou mudam para pior:
- Correr atrás da nota do Lighthouse. Atrasar todos os scripts até a nota chegar a 100 pode piorar o INP quando o usuário real começa a clicar, porque todo aquele JavaScript roda justamente no momento da interação.
- Testar só a home. A avaliação da origem depende de para onde o tráfego vai de fato.
- Instalar um segundo plugin de otimização em cima do primeiro. Dois plugins minificando, combinando e atrasando os mesmos arquivos costumam quebrar coisas, e a sobreposição é difícil de depurar.
- Rodar o PageSpeed Insights de novo esperando outro veredito. A seção de campo não muda entre execuções no mesmo dia.
Quanto tempo leva para aprovar depois da correção?
Se a correção estiver certa, o percentil 75 começa a melhorar conforme visitas novas substituem as antigas na janela de 28 dias. A troca completa leva umas quatro semanas. A validação do Search Console roda num prazo parecido. O tráfego também conta: uma URL com pouco acesso pode sair do dado por URL e passar a ser julgada pela origem.
Durante a espera, acompanho o monitoramento de usuário real quando o site tem. A biblioteca web-vitals, do Google, reporta LCP, INP e CLS dos seus visitantes, e assim você vê a tendência todo dia em vez de esperar o CrUX.
Perguntas frequentes
Avaliação reprovada derruba meu ranking?
Pode pesar um pouco, mas relevância vem antes. Explico como o Google usa a experiência na página em Core Web Vitals são fator de ranking? Uma avaliação reprovada é motivo melhor para se preocupar com abandono e conversão em celular lento.
Minha página mostra “sem dados”. Ela reprovou?
Não. “Sem dados” quer dizer que o CrUX não tem visitas suficientes daquela URL. Olhe a visão de origem. Se ela também estiver vazia, não existe avaliação, e você precisa de teste de laboratório mais uma medição de campo própria.
Corrijo primeiro o celular ou o desktop?
O celular, em quase todos os casos. Ele costuma ser o pior dos dois, e o que ajuda um celular lento tende a ajudar o desktop também.
Para a ordem completa de correção das três métricas, veja Core Web Vitals no WordPress. Se a sua avaliação continua reprovando e você quer alguém para achar a causa nos dados de campo, é isso que faço como especialista em Core Web Vitals, e a equipe da WebOption pode implementar as correções quando você precisar de alguém mexendo no código.