Core Web Vitals são as três métricas que o Google usa para medir a experiência real de carregamento e uso de uma página: LCP (carregamento do maior elemento visível), INP (tempo de resposta às interações) e CLS (estabilidade visual). Para passar, a página precisa ter LCP de até 2,5 segundos, INP de até 200 milissegundos e CLS de até 0,1, medidos no percentil 75 de visitas reais. Elas entram no ranqueamento, mas pesam menos do que relevância, e o ganho maior costuma aparecer em conversão.
Em sites B2B de tecnologia, eu vejo o mesmo padrão se repetir. O time de marketing roda o PageSpeed Insights, vê uma nota vermelha, entra em pânico e pede uma "otimização de performance" sem saber qual página, qual métrica ou qual causa atacar. O resultado é trabalho espalhado e pouca melhora no relatório que importa.
Neste guia eu explico o que cada métrica mede hoje, onde está o dado confiável, quanto isso pesa de verdade no Google e quais são as causas que mais encontro em sites de SaaS, cloud e integradores. No fim, mostro como priorizar por template de página, que é o jeito mais barato de fazer o relatório sair do vermelho.
As Core Web Vitals fazem parte de um conjunto maior de métricas de experiência que o Google mantém no web.dev. Segundo a página oficial de Web Vitals, as três métricas atuais estão no estágio estável, e a avaliação considera o percentil 75 das visitas, separando celular e desktop. A página passa quando atinge o limite "bom" nas três ao mesmo tempo.
O LCP mede quanto tempo leva para o maior elemento visível na primeira tela aparecer. Pode ser uma imagem, o pôster ou o primeiro quadro de um vídeo, uma imagem de fundo carregada por CSS ou um bloco de texto. Os limites são: até 2,5 segundos é bom, entre 2,5 e 4 segundos precisa melhorar e acima de 4 segundos é ruim.
Em site B2B, o elemento de LCP quase sempre é a imagem ou o vídeo do hero da home e das landing pages, ou o título do post no blog. Saber qual elemento é o LCP de cada template é o primeiro passo de qualquer diagnóstico.
O INP mede o tempo entre uma interação do usuário (clique, toque ou tecla) e o momento em que o navegador mostra a resposta na tela. Rolagem e hover não contam. Até 200 milissegundos é bom, até 500 milissegundos precisa melhorar e acima disso é ruim.
O INP substituiu o FID (First Input Delay) como Core Web Vital em 12 de março de 2024, segundo o anúncio no blog do web.dev. A diferença prática é grande. O FID olhava só o atraso da primeira interação. O INP observa as interações da visita inteira, então um formulário de demonstração lento ou um widget que trava a página depois do carregamento passam a contar.
O CLS mede quanto o conteúdo pula de lugar enquanto a pessoa usa a página. Até 0,1 é bom e acima de 0,25 é ruim. As causas clássicas, segundo o próprio web.dev, são imagens e vídeos sem dimensão definida, anúncios e widgets que mudam de tamanho, fontes que ocupam espaço diferente da fonte reserva e conteúdo injetado acima do que já estava na tela.
Aqui eu prefiro ser conservador, porque é onde mais vejo promessa exagerada. A documentação de experiência na página do Google Search Central diz que as Core Web Vitals são usadas pelos sistemas de ranqueamento. A mesma página diz que não existe um sinal único de experiência na página e que o Google procura mostrar o conteúdo mais relevante mesmo quando a experiência é inferior.
Na prática, eu leio isso assim: performance funciona como critério de desempate entre páginas que respondem bem à mesma busca. Se uma página responde muito melhor à busca, ela tende a ficar na frente mesmo sendo mais lenta. O Google também avisa que bons números, sozinhos, não asseguram posição alta.
Então por que eu trato Core Web Vitals como prioridade em projetos B2B? Por dois motivos. O primeiro é que, em buscas competitivas de software, os concorrentes costumam ter conteúdo parecido, e aí o desempate importa. O segundo é que o comprador B2B chega por anúncio, e-mail, LinkedIn e indicação, além da busca. Uma página que demora para mostrar o hero ou trava ao abrir o formulário de demonstração perde lead em todos esses canais.
A confusão mais comum que encontro é tratar a nota do PageSpeed Insights como se fosse a avaliação do Google. São coisas diferentes, e o artigo do web.dev sobre dados de laboratório e de campo explica bem o porquê.
Dados de campo vêm de visitas reais. A fonte do Google é o Chrome User Experience Report (CrUX), que agrega medições de usuários do Chrome numa janela móvel de 28 dias. É esse dado que aparece no relatório de Core Web Vitals do Search Console e no bloco "Descubra o que seus usuários reais estão experimentando" do PageSpeed Insights.
Um detalhe que afeta muito site B2B: o CrUX só inclui páginas e origens com tráfego suficiente, e o Google não divulga o número mínimo. Muita landing page de nicho não tem dado próprio. Nesse caso, o PageSpeed Insights mostra o dado da origem inteira, e se nem a origem tiver volume, não mostra dado de campo nenhum.
O Lighthouse, que gera a nota de 0 a 100 do PageSpeed Insights, simula um carregamento com um aparelho, uma rede e uma localização fixos. Ele é ótimo para depurar, porque o resultado é repetível e mostra a causa provável de cada problema. Mas ele não interage com a página, então não mede INP. No lugar, mostra o Total Blocking Time (TBT), que serve como pista e não substitui o INP.
Minha regra é simples: eu uso o dado de campo para decidir se existe problema e em quais páginas. Depois disso, recorro ao laboratório para entender a causa e testar a correção antes de publicar. Se o campo está verde e o laboratório está amarelo, eu raramente priorizo.
O relatório do Search Console é o lugar onde eu começo qualquer diagnóstico. Segundo a ajuda oficial do relatório de Core Web Vitals, ele agrupa URLs com experiência parecida e dá a cada grupo o status da pior métrica naquele tipo de dispositivo. Os valores do grupo são o percentil 75 dos últimos 28 dias.
Três leituras que eu faço sempre:
Se o site é pequeno e o relatório aparece vazio, isso indica falta de volume no CrUX, não ausência de problema. Nesse caso, eu uso o laboratório com mais peso e, quando possível, instalo medição de usuário real com a biblioteca web-vitals enviando dados para o GA4.
Depois de olhar muitos sites de SaaS, cloud e consultorias de TI, eu vejo as mesmas causas aparecerem. Quase sempre elas nascem de decisões de marketing tomadas sem medir o custo de performance, e trocar de hospedagem raramente resolve.
O vídeo de fundo na primeira dobra é o campeão de LCP ruim. Quando o pôster ou o primeiro quadro do vídeo vira o elemento de LCP, a página depende de um arquivo pesado para "terminar" de carregar. Eu costumo trocar por uma imagem otimizada com o vídeo carregando só depois de um clique, ou deixo um pôster leve com prioridade alta de carregamento.
O guia de otimização de LCP divide o tempo em quatro partes (resposta do servidor, atraso para começar a baixar o recurso, tempo de download e atraso de renderização) e recomenda nunca usar lazy loading na imagem de LCP. Esse erro aparece com frequência em sites montados em construtores visuais, quando o lazy loading fica ligado em todas as imagens.
Chat de atendimento, ferramenta de agendamento, pop-up de cookies, pixel de identificação de empresa: cada um carrega JavaScript que disputa a thread principal do navegador. Isso afeta o INP, porque a página fica ocupada executando código de terceiros quando o visitante tenta clicar.
A solução que mais uso é a fachada: um botão estático com a aparência do chat, que carrega o widget real só quando alguém clica. A documentação do Lighthouse sobre fachadas cita chat e vídeos incorporados como casos típicos e avisa da troca envolvida: o selo de mensagem não lida, por exemplo, só aparece depois que o widget carrega.
Em quase toda auditoria eu encontro um contêiner do Google Tag Manager com tags de campanhas encerradas, pixels duplicados e HTML personalizado colado direto no contêiner. O guia de boas práticas de tags do web.dev recomenda pausar ou excluir tags sem uso, evitar tags de HTML personalizado quando houver modelo pronto, disparar o que não é essencial depois do carregamento da janela e restringir cada tag às páginas onde ela é usada.
Esse trabalho é barato e costuma render bastante. Eu peço uma lista de quem é dono de cada tag. O que ninguém reivindica, eu pauso e observo por algumas semanas antes de excluir.
Site de tecnologia gosta de tipografia própria, muitas vezes com quatro ou cinco pesos carregados de um serviço externo. Isso pode atrasar a exibição do texto e, quando a fonte troca pela reserva, empurrar o layout. Eu reduzo o número de pesos, uso WOFF2, faço preconnect com a origem das fontes e ajusto a fonte reserva com size-adjust para ocupar o mesmo espaço.
Demos interativas, tours de produto e vídeos de apresentação embutidos em iframe são comuns em páginas de SaaS. Eles carregam um aplicativo inteiro dentro da página. Quando ficam acima da dobra sem dimensão reservada, viram causa de CLS. Quando carregam junto com a página, pesam no INP. Eu trato do mesmo jeito que o vídeo: imagem estática com espaço reservado e carregamento do embed só na interação.
Logos de clientes, capturas de tela do produto e ilustrações exportadas em alta resolução sem largura e altura definidas aparecem em quase todo site que audito. É a causa mais simples de CLS e a mais fácil de resolver no template.
O erro de método mais caro que vejo é otimizar URL por URL. Site B2B tem poucos templates e muitas páginas: home, landing de produto, landing de solução, página de integração, post de blog, case, página de preço. Corrigir o template resolve todas as páginas que usam ele.
Eu monto uma planilha simples com uma linha por template e quatro colunas: status de cada métrica no campo, volume orgânico do template, papel no funil e esforço estimado. A ordem de ataque sai do cruzamento entre problema real e valor comercial.
Esse raciocínio por template é o mesmo que aplico em SEO técnico de forma geral: o problema que se repete por estrutura vale mais do que o problema isolado.
Quando um cliente pergunta como melhorar Core Web Vitals, eu respondo com este roteiro. Ele começa no dado de campo e só termina quando o relatório confirma a melhora.
Se o site está em reconstrução, esse é o melhor momento para resolver tudo de uma vez. Eu falo sobre isso no guia de site para SaaS, e a escolha da plataforma também conta, como discuto em Webflow ou WordPress. Em sites montados com React sem renderização no servidor, o problema costuma ir além de performance e atingir a indexação. Esse caso tem um guia próprio sobre SEO para sites em JavaScript.
Não da forma que muita gente imagina. O Google diz que usa as Core Web Vitals no ranqueamento, mas que relevância vem antes e que não existe um sinal único de experiência na página. Na minha leitura, elas pesam mais como desempate entre páginas parecidas do que como causa de queda forte.
A nota de 0 a 100 vem do Lighthouse, que simula um carregamento em condições fixas. O Search Console mostra dados de campo do CrUX, coletados de visitas reais nos últimos 28 dias. Eu confio no campo para saber se existe problema e recorro ao laboratório na hora de investigar a causa.
O FID deixou de ser Core Web Vital em 12 de março de 2024, quando foi substituído pelo INP. O Search Console removeu o FID nessa data. Se algum relatório ou ferramenta ainda mostra FID como métrica principal, ele está desatualizado.
Provavelmente por falta de volume. O CrUX só inclui páginas e origens com tráfego suficiente de usuários do Chrome, e o Google não divulga o mínimo. Sites B2B de nicho caem nessa situação com frequência. Nesse caso, eu uso o laboratório e, se possível, medição de usuário real com a biblioteca web-vitals.
Como o dado de campo é calculado sobre os últimos 28 dias, a melhora aparece de forma gradual ao longo de cerca de um mês depois da publicação da correção. A validação no Search Console também acompanha uma janela de 28 dias. Prazos maiores acontecem quando o volume de visitas é baixo.
Se o relatório de Core Web Vitals do seu site está vermelho e o time não sabe por onde começar, o primeiro passo é mapear quais templates estão com problema no dado de campo e quanto cada um vale para o funil. A Pipa faz esse levantamento dentro do trabalho de SEO técnico para empresas B2B de tecnologia e da auditoria de SEO, sempre começando pelo que tem mais impacto comercial. Se quiser uma primeira leitura do seu site sem custo, peça o diagnóstico gratuito.
