Core Web Vitals: o que corrigir primeiro sem refazer o site

Por Rafael Nogueira · Consultor de SEO Técnico

Core Web Vitals é o nome que o Google deu a três medidas da experiência real de quem abre o seu site: quanto tempo demora para o conteúdo principal aparecer, quanto tempo o site leva para responder a um toque ou clique, e quanto a página se mexe sozinha enquanto carrega. São métricas de campo, coletadas de usuários de verdade, não de um teste de laboratório.

A maioria dos sites que recebo para auditoria não precisa de reconstrução. Precisa de cinco ou seis correções pontuais, quase sempre nas imagens, nas fontes e em scripts de terceiros que ninguém lembra por que estão ali.

As três métricas e os limites que valem

O INP entrou no lugar do antigo FID em 2024 e é o mais rigoroso dos três, porque mede todas as interações da visita, não apenas a primeira. É também o que mais reprova sites cheios de script.

LCP: quase sempre é a imagem do topo

Em nove de cada dez casos, o maior elemento da tela é a imagem de capa. As correções que mais rendem, na ordem:

• Dimensione a imagem antes de subir. Uma foto de 3000 pixels exibida em 800 desperdiça banda em todo carregamento.
• Use formato moderno. WebP costuma cortar metade do peso com a mesma qualidade visível.
• Não use carregamento preguiçoso na imagem do topo. É o erro mais comum: o lazy loading ajuda no resto da página e atrasa justamente o elemento medido.
• Avise o navegador com antecedência. Uma linha de preload no cabeçalho adianta a busca da imagem principal.

<link rel="preload" as="image"
      href="/img/capa.webp">

<img src="/img/capa.webp" width="1200"
     height="675" alt="..." fetchpriority="high">

CLS: reserve o espaço antes de preencher

O conteúdo pula quando o navegador não sabe o tamanho do que vai chegar. A solução não é animação nem truque de CSS, é informar as medidas:

• Sempre declare width e height em imagens e vídeos, mesmo usando CSS responsivo.
• Reserve altura fixa para banners, blocos de anúncio e formulários que carregam depois.
• Carregue fontes com font-display: swap e defina uma fonte de sistema parecida como reserva, para o texto não mudar de tamanho na troca.
• Evite inserir avisos, barras de cookies e pop-ups empurrando o conteúdo para baixo; sobreponha em vez de deslocar.

@font-face {
  font-family: "Barlow";
  src: url("/fonts/barlow.woff2") format("woff2");
  font-display: swap;
}

Hospedagem, cache e CDN: quando eles resolvem

Antes de trocar de servidor por causa de lentidão, vale entender qual parte do tempo é dele. O tempo de resposta do servidor, medido até o primeiro byte chegar, é só um pedaço do LCP. Se esse tempo está abaixo de meio segundo e a página ainda demora, o gargalo está no que o navegador faz depois, e trocar de hospedagem não vai mudar nada.

O cache de página costuma render mais que hardware. Em sites feitos com sistema de gerenciamento, cada visita pode disparar consultas ao banco de dados para montar a mesma página. Guardar a versão pronta e servi-la direto corta esse trabalho inteiro. Em sites estáticos isso já é o padrão, e é uma das razões pelas quais eles são rápidos por natureza.

A rede de distribuição de conteúdo faz diferença quando seu público está longe do servidor ou quando o site serve muitas imagens. Ela entrega os arquivos a partir do ponto mais próximo do visitante e tira essa carga da sua máquina. Para um site brasileiro, com servidor no Brasil e público local, o ganho costuma ser modesto nas páginas e relevante nas imagens.

Há ainda dois ajustes baratos que passam despercebidos: comprimir as respostas de texto, o que reduz bastante o peso de HTML, CSS e JavaScript, e definir prazos longos de cache para arquivos que quase nunca mudam, como fontes e ícones. Os dois são configuração de servidor, não exigem mexer no site e valem para todas as páginas de uma vez.

INP: o problema costuma ser script de terceiros

Cada ferramenta de chat, mapa, rastreamento e teste A/B disputa a mesma fila de execução do navegador. Quando o usuário toca em algo e essa fila está ocupada, a resposta atrasa e o INP piora. O que costuma resolver:

• Inventário honesto. Liste os scripts do site e pergunte, para cada um, quem olha aquele dado. O que ninguém usa, sai.
• Carregamento adiado. Use defer ou async e só carregue widgets pesados depois da primeira interação.
• Gerenciador de tags sob controle. É comum encontrar tags duplicadas ou de campanhas encerradas há anos.
• Menos trabalho por clique. Evite recalcular listas inteiras a cada digitação em campos de busca.

Um diagnóstico de dez minutos

Antes de mexer em qualquer código, faça este roteiro na página que mais recebe visitas. Ele separa o que é problema real do que é impressão:

• Abra a página numa janela anônima, com o celular na rede móvel. A maior parte do tráfego chega assim, e é o cenário que o relatório de campo mede.
• Conte quanto tempo até o texto principal aparecer. Se passar de três segundos, o problema está no topo da página.
• Observe se algo pula depois do primeiro desenho. Banner, aviso de cookie e imagem sem medida são os suspeitos de sempre.
• Toque em um menu logo que a página aparece. Se demorar a responder, há script ocupando a fila do navegador.
• Veja o peso total da página. Acima de 3 MB em uma página de conteúdo, quase sempre há imagem grande demais.

Esse roteiro não substitui a medição, mas aponta o lado certo antes de você gastar tempo em otimização que não muda nada.

O que ignorar nos relatórios

Duas recomendações aparecem em quase todo diagnóstico e raramente valem o esforço em sites pequenos. A primeira é a eliminação total do CSS não utilizado: o ganho costuma ser de milésimos e o risco de quebrar o visual é alto. A segunda é a nota geral de desempenho em laboratório, que oscila a cada execução e vira fonte de ansiedade sem informação nova.

Concentre-se nas três métricas de campo e no que elas indicam. Uma página que carrega o conteúdo principal em dois segundos, não se mexe sozinha e responde ao toque na hora está aprovada, mesmo que a nota simulada não seja verde.

Onde medir sem pagar nada

Use o relatório de Core Web Vitals do Search Console para ver o retrato do site inteiro por grupo de páginas, o PageSpeed Insights para diagnosticar uma página específica e a aba Lighthouse do próprio navegador para testar uma correção antes de publicar. Os três são gratuitos e se complementam: o primeiro mostra onde dói, o segundo explica por quê, o terceiro confirma se a correção funcionou.

O que isso muda no ranqueamento

Seja direto com as expectativas: desempenho é critério de desempate, não atalho de posicionamento. Entre duas páginas que respondem igualmente bem à busca, a mais rápida leva vantagem. Entre uma página lenta que responde e uma rápida que não responde, o conteúdo ganha. A diferença real aparece na conversão: página lenta perde visita antes de mostrar o que tem, e isso vale para qualquer site, esteja ele bem posicionado ou não. Se o seu projeto está começando agora, vale conferir também o guia de criação de sites, que trata dessa base desde o início.

O que fazer a partir daqui

Escolha a página que mais recebe visita, rode o PageSpeed Insights nela e corrija na ordem: imagem do topo, medidas declaradas, fontes, scripts de terceiros. Espere vinte e oito dias, que é a janela do relatório de campo, e compare. Essa sequência resolve a maioria dos casos sem tocar no restante do site.

Rafael NogueiraConsultor de SEO Técnico

Rafael é consultor de SEO técnico e desenvolvedor. Especialista em performance, dados estruturados (Schema.org) e arquitetura de sites, já auditou centenas de projetos. No blog, traduz temas técnicos complexos em passos práticos que qualquer time consegue aplicar.