Core Web Vitals: como a velocidade do site afeta SEO e vendas

Core Web Vitals são três métricas que o Google usa para medir a experiência de quem visita um site: quanto tempo o conteúdo principal leva para aparecer (LCP), quanto a página demora para responder a um clique ou toque (INP) e quanto os elementos pulam de lugar durante o carregamento (CLS). Elas entram no ranqueamento como um sinal entre vários, e pesam também numa coisa que não depende do Google: a paciência de quem chegou pelo anúncio ou pela busca.

Este guia serve para quem é dono ou responsável por um site que precisa gerar contato ou venda. Ele explica cada métrica sem jargão, mostra onde medir, por que os números às vezes não batem e quais correções costumam dar mais resultado.

O que são Core Web Vitals e quais são os limiares

O Google escolheu três aspectos da experiência de página e definiu, para cada um, uma faixa de "bom", uma de "precisa melhorar" e uma de "ruim". Os valores estão na página oficial das Core Web Vitals no web.dev e no próprio PageSpeed Insights:

Dois detalhes mudam a leitura da tabela.

O primeiro é o percentil 75. A avaliação não usa a média, e sim o valor que atende três de cada quatro visitas, com celular e computador separados. Não adianta o site abrir rápido no seu notebook se um quarto dos visitantes, num celular simples, espera muito mais.

O segundo é que o INP é recente. Ele substituiu o FID como Core Web Vital em 12 de março de 2024. Guias e ferramentas antigas ainda falam em FID; se o material que você está lendo não menciona o INP, ele está desatualizado.

LCP, INP e CLS em linguagem simples

LCP: quando o conteúdo principal aparece

O LCP marca o momento em que o maior elemento visível da primeira tela termina de ser desenhado. Normalmente é a foto de destaque, a imagem de capa de um vídeo ou o bloco do título. Numa landing page com uma foto de 3 MB no topo, o visitante vê a página em branco ou pela metade até essa foto chegar, e o LCP registra exatamente essa espera.

INP: quanto a página demora para responder

O INP mede o tempo entre uma interação (clique, toque na tela ou tecla) e a próxima atualização visual. Passar o mouse por cima e rolar a página não contam. Ele acompanha as interações da visita inteira e reporta uma das mais lentas, não a primeira. O exemplo típico: a pessoa toca em "Enviar" no formulário e nada acontece por quase um segundo, porque o navegador está ocupado rodando o script do chat, do pixel de anúncio e do mapa de calor. Ela toca de novo, envia duas vezes ou desiste.

CLS: quanto a página pula

O CLS soma os deslocamentos inesperados de conteúdo. Você vai tocar em "Ligar agora", uma faixa de promoção carrega em cima, empurra o botão para baixo e o toque cai no lugar errado. O CLS não tem unidade: é uma pontuação que cresce com o tamanho da área que se moveu e com a distância do movimento.

Dado de laboratório e dado de campo: por que os números não batem

Existem duas formas de medir, e elas respondem a perguntas diferentes.

• Dado de laboratório vem de um teste controlado: um aparelho simulado, uma rede definida, um carregamento da página. É o que o Lighthouse faz, e é o que gera a nota de 0 a 100. Serve para achar a causa de um problema e para testar uma correção antes de publicar.
• Dado de campo vem de visitas reais. O Google coleta essas medições de usuários do Chrome no CrUX (Chrome User Experience Report), e é esse dado que aparece na avaliação de Core Web Vitals do PageSpeed Insights e no relatório do Search Console.

Os dois divergem por motivos legítimos. O teste de laboratório carrega a página sem nada em cache, num único aparelho; o visitante real volta com parte dos arquivos já guardados, usa telas de tamanhos diferentes e recebe versões personalizadas da página. Além disso, o INP depende de alguém clicar, então o laboratório não consegue medi-lo direto: o Lighthouse mostra o TBT (Total Blocking Time), o tempo em que a página ficou travada, como aproximação.

Na hora de priorizar, o dado de campo manda, porque é o que as pessoas vivem. Nota 98 no Lighthouse com avaliação de campo reprovada significa que o site vai bem no teste e mal na vida real.

Como medir no PageSpeed Insights e no Search Console

PageSpeed Insights

Cole o endereço da página no PageSpeed Insights e escolha a aba de celular. O bloco de cima traz a avaliação de Core Web Vitals com dado de campo dos últimos 28 dias. O bloco de baixo é o teste do Lighthouse, com a nota e a lista de diagnósticos, que aponta a imagem pesada, o script que trava e o elemento que se desloca.

Site com pouco tráfego nem sempre tem dado de campo por página. Nesse caso, a ferramenta mostra o resultado do domínio inteiro e, se nem isso existir, só o laboratório. Aí vale medir com visitas reais por conta própria, com uma biblioteca de medição instalada no site, carregada com o mesmo consentimento das outras ferramentas de análise.

Search Console

O relatório de Core Web Vitals do Search Console agrupa as URLs do site em ruim, precisa melhorar e bom, separando celular e computador. Cada grupo recebe o status da pior métrica: página com CLS ruim e LCP razoável aparece como ruim. A vantagem é enxergar padrões: quando todas as páginas de produto estão no vermelho, o problema está no modelo dessas páginas, não em uma página só.

No seu próprio celular

Nenhuma ferramenta substitui abrir o site num celular comum, fora do wi-fi, e tentar fazer o que o cliente faz: achar o serviço, tocar no WhatsApp, preencher o formulário.

Causas típicas de site lento e como corrigir

Imagem pesada ou sem dimensão

É a causa mais comum de LCP alto e de CLS. A foto de destaque sai da câmera com vários megabytes e vai para o ar sem tratamento. Sem largura e altura declaradas, o navegador não reserva o espaço e o texto pula quando a imagem chega. A correção:

• exportar no tamanho em que a imagem aparece, em formato moderno (WebP ou AVIF);
• declarar largura e altura em toda imagem;
• nunca usar carregamento tardio (lazy loading) na imagem principal;
• sinalizar a imagem principal como prioridade.

<img src="/img/fachada-1200.webp" width="1200" height="675"
     alt="Fachada da clínica" fetchpriority="high">

Fonte externa

Fonte carregada de outro domínio exige uma conexão extra antes de o texto aparecer. Enquanto isso, o título fica invisível ou é desenhado com outra fonte e muda de tamanho quando a definitiva chega. Hospede a fonte no próprio domínio, carregue só os pesos usados e pré-carregue a fonte do título.

JavaScript demais

Chat, pixels de anúncio, mapa de calor, gerenciador de tags com dezenas de etiquetas, carrossel, animações. Cada script disputa o mesmo processador do celular, e é aqui que o INP estoura. A correção começa por um inventário: o que está instalado, quem usa o dado, desde quando. O que ninguém consulta sai. O que fica pode carregar depois da primeira interação ou depois do consentimento, o que também atende à LGPD.

Vídeo pesado no topo

Vídeo de fundo em reprodução automática baixa vários megabytes antes de o visitante ler uma palavra. Use uma imagem de capa leve como elemento principal, carregue o vídeo depois e, no celular, considere mostrar só a imagem.

Hospedagem lenta

Nada acontece na tela antes de o servidor enviar o primeiro byte, o chamado TTFB (Time to First Byte). Hospedagem compartilhada saturada, página montada no banco de dados a cada visita e servidor longe dos visitantes atrasam todas as métricas ao mesmo tempo. Cache de página, CDN (rede que entrega arquivos de um ponto perto do visitante) e geração estática para conteúdo que muda pouco resolvem boa parte. Ter a hospedagem sob controle da empresa é o que permite trocar de plano ou de fornecedor sem ficar refém; o texto sobre domínio, DNS, e-mail e hospedagem mostra o que precisa estar em nome de quem.

Elementos que entram depois

Banner de cookies, faixa de promoção e botão de chat que aparecem empurrando o conteúdo geram CLS. Reserve o espaço desde o início ou use elementos fixos sobrepostos, sem deslocar o texto.

Quanto a velocidade pesa no Google e nas vendas

A posição oficial do Google está na documentação sobre experiência na página: as Core Web Vitals são usadas pelos sistemas de ranqueamento, mas não existe um sinal único de experiência, e a busca sempre tenta mostrar o conteúdo mais relevante, mesmo quando a experiência da página é fraca. O mesmo texto avisa que resultado bom no Search Console não garante as primeiras posições.

Na prática, isso quer dizer três coisas:

• velocidade não compensa conteúdo fraco, e a página que responde melhor à busca continua na frente;
• quando muitas páginas úteis disputam a mesma busca, a experiência pode contribuir para o resultado;
• o próprio Google diz que buscar nota perfeita só por causa de SEO pode não ser o melhor uso do tempo, e tirar conteúdo útil para ganhar pontos é troca ruim.

Nas vendas, o efeito é mais direto e não depende do algoritmo. No tráfego pago, o clique é cobrado mesmo que a pessoa desista antes de a página aparecer. Um formulário com INP alto recebe envio duplicado ou abandono. Um CLS alto faz o visitante tocar no lugar errado e perder a paciência. Nenhum desses efeitos aparece no relatório de SEO; eles aparecem no número de contatos. Por isso vale cruzar o relatório de velocidade com os contatos por página: se a página mais lenta é também a que menos converte no celular, a prioridade está dada.

Por onde começar a corrigir

Uma ordem que funciona para a maioria dos sites:

1. Rode o PageSpeed Insights, na aba de celular, nas três páginas que mais trazem contato ou venda, não só na home.
2. Abra o relatório de Core Web Vitals do Search Console e veja se o problema é de uma página ou de um modelo de página.
3. Ataque primeiro a imagem principal e os scripts de terceiros: são as correções de maior efeito e menor risco.
4. Declare dimensões em imagens e reserve espaço para o que entra depois.
5. Se o servidor demora a responder, trate a hospedagem antes de otimizar detalhes.
6. Espere a janela de 28 dias e confira o dado de campo. Depois, mantenha um monitoramento do site para saber quando um plugin novo ou um script de campanha piorar tudo de novo.

Mexer em script de terceiro pode quebrar formulário ou medição sem ninguém notar. Por isso, quando fazemos esse trabalho na Locomotiva Tech, a correção nasce num ambiente isolado, é medida com as páginas reais antes de ir ao ar e sobe com caminho de volta documentado. Se o site precisa ser refeito do zero, velocidade entra como requisito desde o primeiro rascunho na criação de sites, e o site institucional que gera contato mostra o que mais precisa estar nele.