SEO técnico
Core Web Vitals e velocidade do site no SEO
Core Web Vitals são LCP, INP e CLS: as métricas de carregamento, resposta e estabilidade visual que o Google recomenda medir em todo site. Elas fazem parte da experiência de página, não substituem relevância, e o Google mede a maioria delas em dois formatos diferentes: laboratório e campo.
Por que a velocidade pesa no SEO
A velocidade do site entra no SEO como parte da experiência de página, e não como um número isolado que garante posição. O Google documenta os limiares de LCP, INP e CLS e recomenda que todo site os meça, mas também é explícito: não existe um único sinal de experiência de página usado pelo ranqueamento, e perseguir nota perfeita só por causa do SEO pode não ser o melhor uso do seu tempo, como mostra o capítulo sobre experiência de página mais adiante.
Isso não quer dizer que velocidade seja irrelevante. O tema aparece dentro do panorama mais amplo de SEO técnico, que cobre rastreio, índice e experiência juntos. Auditar Core Web Vitals de verdade, cruzando origem do problema com prioridade comercial, é parte do que entra numa auditoria de serviços de SEO.
Nota alta não é ranking garantido
O próprio Google escreve que ficar "verde" no relatório de Core Web Vitals não garante topo de página, porque existe muito mais na experiência de página do que essas três métricas sozinhas.
O sintoma clássico é o dono do site abrir o PageSpeed Insights, ver uma nota vermelha e concluir que encontrou "a causa" de não aparecer no Google. Às vezes é isso mesmo. Na maioria das vezes, o problema real é outro: falta de conteúdo relevante, ausência de demanda de busca, ou uma URL sequer indexada, que é o primeiro filtro descrito no guia de SEO técnico. Confundir os dois gasta orçamento no lugar errado.
Também existe o erro oposto: ignorar velocidade porque "conteúdo é o que importa". Sites com interação lenta, imagem que empurra o texto ou carregamento arrastado frustram quem chega até a página, mesmo quando o conteúdo é bom. O trabalho certo não escolhe um lado: mede os três números, entende o que cada um significa e prioriza o que afeta gente de verdade, não só o relatório.
Uma confusão específica merece nome: "nota 100 no PageSpeed" não é sinônimo de bons Core Web Vitals. A nota de 0 a 100 e a aprovação em LCP, INP e CLS são dois testes diferentes, calculados de formas diferentes, e um site pode passar num sem passar no outro. O capítulo sobre laboratório e campo, mais adiante, mostra por quê.
- Sinal de que vale medir: páginas money com muito tráfego mobile, hero pesado, formulário ou carrinho que trava ao tocar.
- Sinal de falso alarme: nota baixa numa página sem visita nenhuma, corrigida antes de qualquer coisa que gere retorno.
- Sinal de outro problema: site rápido e ainda assim sem impressão nas buscas que interessam. Aí o gargalo é indexação, conteúdo ou concorrência, não velocidade.
O que são os Core Web Vitals
- Core Web Vitals
- São o subconjunto de métricas de experiência real que o Google recomenda a todo site medir: LCP para carregamento, INP para resposta a interações e CLS para estabilidade visual, avaliadas no 75º percentil de visitas reais, separadas por mobile e desktop.
A iniciativa é da equipe do Chrome, chamada Web Vitals, e existe para simplificar um cenário em que havia métricas demais para quem não é especialista em performance acompanhar. Dentro dela, as Core Web Vitals são as três que se aplicam a qualquer página, valem para todo site e aparecem nas ferramentas do próprio Google, segundo a documentação de Web Vitals no web.dev.
| Métrica | O que mede | Meta boa (75º percentil) |
|---|---|---|
| LCP | Carregamento do maior elemento visível | até 2,5 segundos |
| INP | Resposta a cliques, toques e teclas | até 200 milissegundos |
| CLS | Estabilidade visual, sem pulos de layout | até 0,1 |
O conjunto muda ao longo do tempo, porque cada métrica passa por um ciclo de vida: experimental, pendente e estável. Hoje LCP, CLS e INP estão todos no estágio estável, o que significa que mudanças na definição são raras e sempre avisadas com antecedência. Foi assim que o INP chegou a esse status, num processo detalhado no capítulo seguinte.
LCP INP e CLS
LCP, INP e CLS medem três momentos diferentes da mesma visita: quanto tempo até o maior conteúdo aparecer, quanto tempo até a página reagir a um toque, e o quanto a tela se mexe sem que ninguém tenha pedido isso.
LCP: o maior elemento
LCP (Largest Contentful Paint) registra o momento em que o maior elemento visível na tela (imagem, bloco de texto ou vídeo) termina de renderizar, contado a partir do início do carregamento. Um LCP bom acontece em até 2,5 segundos; entre 2,5 e 4 segundos precisa melhorar; acima de 4 segundos é considerado ruim, conforme o guia de Largest Contentful Paint.
Na prática, o LCP costuma ser a imagem de destaque, o título grande da home ou o bloco principal de uma página de serviço. Imagem pesada sem compressão, fonte que atrasa a renderização do texto e servidor lento para responder o primeiro byte são as causas mais comuns de LCP alto em site pequeno.
INP: a resposta ao clique
INP (Interaction to Next Paint) mede a capacidade de resposta da página observando clique, toque e tecla ao longo de toda a visita, não só a primeira interação. Um INP bom fica em até 200 milissegundos; entre 200 e 500 milissegundos precisa melhorar; acima de 500 milissegundos é ruim, segundo o guia de Interaction to Next Paint.
A métrica reporta a interação mais lenta observada na visita, e não uma média. Um menu que trava ao abrir, um botão de "adicionar ao carrinho" que demora para dar retorno visual ou um formulário que congela por um instante são exatamente o tipo de atraso que o INP captura.
CLS: sem pulos de layout
CLS (Cumulative Layout Shift) soma o quanto elementos visíveis mudam de posição sem que o usuário tenha feito nada para provocar isso. É uma pontuação sem unidade, calculada pela área afetada e pela distância do deslocamento. Um CLS bom fica em até 0,1; entre 0,1 e 0,25 precisa melhorar; acima de 0,25 é ruim, conforme Cumulative Layout Shift.
Por que o 75º percentil
O Google mede no 75º percentil, não na média, porque o objetivo é garantir boa experiência para a maioria das visitas mesmo em dispositivo fraco e rede ruim. Uma média esconde exatamente os piores casos, que são os que mais frustram.
De FID para INP
O INP substituiu o FID (First Input Delay) como métrica oficial de responsividade em 12 de março de 2024, depois de um ano como métrica pendente. O anúncio foi feito em maio de 2023, no post Introducing INP to Core Web Vitals, do próprio Google Search Central.
A troca não foi cosmética. O FID só media o atraso antes de a primeira interação começar a ser processada, ignorando tudo que acontecia depois. O INP observa clique, toque e tecla durante toda a visita, do atraso inicial até a página realmente responder na tela, o que dá um retrato mais completo de como o site se comporta enquanto a pessoa navega, conforme detalha o próprio guia da métrica.
Em uma frase: FID media a primeira impressão; INP mede a visita inteira, e é o que conta desde março de 2024.
Vale conferir a data de qualquer conteúdo sobre Core Web Vitals antes de confiar nele. Boa parte do material em português sobre o assunto ainda lista LCP, FID e CLS como as três métricas atuais, e essa lista está desatualizada: FID foi descontinuado e removido do programa Core Web Vitals na mesma troca.
Laboratório versus campo
Dado de laboratório vem de uma simulação em ambiente controlado; dado de campo vem de visitas reais de pessoas de verdade. Os dois medem coisas parecidas, mas raramente batem, e confundir um com o outro é a origem de boa parte da frustração com nota de PageSpeed.
PageSpeed Insights e CrUX
O PageSpeed Insights (PSI) combina os dois formatos numa página só: dado de laboratório, gerado pelo Lighthouse a partir de uma página carregada em condições simuladas, e dado de campo, vindo do Chrome UX Report (CrUX), com a experiência real dos últimos 28 dias, conforme About PageSpeed Insights.
| Critério | Laboratório | Campo |
|---|---|---|
| Origem do dado | Simulação, uma execução | Visitas reais, 28 dias |
| Ferramenta típica | Lighthouse | Chrome UX Report |
| Quando falta | Nunca falta | Site novo ou pouco tráfego pode não ter |
Se não há dado de campo
Quando a URL não tem visitas suficientes no CrUX, o PageSpeed Insights recorre ao dado agregado do domínio inteiro. Se nem isso houver, ele mostra só o laboratório. Site novo, recém-lançado ou de baixo tráfego costuma cair nesse caso, e não é sinal de erro.
É por isso que dois relatórios podem discordar sem que nenhum esteja errado: o laboratório testa um único carregamento simulado num aparelho e numa rede fixos, enquanto o campo agrega o comportamento real de gente em celular velho, wi-fi ruim e 4G instável. Para decidir se uma página "passou" nos Core Web Vitals, o campo é a referência; o laboratório serve para depurar antes de publicar.
A nota de 0 a 100 do Lighthouse
- Nota do Lighthouse
- É uma pontuação de 0 a 100 calculada a partir de vários indicadores de laboratório, entre eles First Contentful Paint, Largest Contentful Paint, Speed Index, Cumulative Layout Shift, Time to Interactive e Total Blocking Time. Nota 90 ou mais é boa; de 50 a 89 precisa melhorar; abaixo de 50 é ruim.
Essa nota não é o mesmo teste que aprova ou reprova um site em Core Web Vitals. A avaliação de Core Web Vitals olha só para LCP, INP e CLS no campo, no 75º percentil: uma página passa quando as três estão boas (ou quando LCP e CLS estão boas e não há dado suficiente de INP). Já a nota de 0 a 100 mistura seis indicadores de laboratório, inclusive alguns que nem fazem parte do Core Web Vitals, como Speed Index e Time to Interactive, conforme a mesma documentação da ferramenta.
O Lighthouse também simula um aparelho de gama intermediária numa rede móvel para mobile, e uma conexão cabeada para desktop, e não o celular real de quem visita o site. Por isso uma página pode ter nota baixa no laboratório e ainda assim aprovar em Core Web Vitals no campo, ou o contrário: nota alta no laboratório e reprovação no campo, se o público real usar rede pior que a simulada.
A experiência de página no Google
- Experiência de página
- É o conjunto mais amplo em que Core Web Vitals se encaixa, ao lado de HTTPS, adequação a dispositivos móveis, ausência de interstitial intrusivo e ausência de excesso de anúncio atrapalhando o conteúdo principal.
O Google resume esse conjunto em seis perguntas de autoavaliação, descritas em Understanding page experience.
- As páginas têm bons Core Web Vitals?
- As páginas são servidas de forma segura, em HTTPS?
- O conteúdo se comporta bem em dispositivos móveis?
- O site evita excesso de anúncio atrapalhando o conteúdo principal?
- As páginas evitam interstitial intrusivo?
- O visitante distingue com facilidade o conteúdo principal do resto?
Não existe um único sinal de "experiência de página". Os sistemas centrais de classificação olham para uma variedade de sinais alinhados com a experiência geral, e tentar chegar a uma nota perfeita só por razão de SEO talvez não seja o melhor uso do seu tempo.
A mesma documentação reforça que a Busca do Google sempre procura mostrar o conteúdo mais relevante, mesmo quando a experiência de página está longe do ideal. A experiência de página pesa mais quando existem várias páginas parecidas em relevância disputando a mesma busca: aí ela ajuda a desempatar. Onde não há concorrência relevante nenhuma, corrigir CLS de uma página vazia não faz o telefone tocar.
O que você mesmo consegue medir
Medir Core Web Vitals não exige ferramenta paga nem conhecimento de código. As duas fontes oficiais e gratuitas são o PageSpeed Insights, por URL, e o relatório de Core Web Vitals dentro do Search Console, por grupo de páginas.
No PageSpeed Insights, o dado de campo aparece em barras de distribuição, não num número único: uma fatia verde (bom), uma âmbar (precisa melhorar) e uma vermelha (ruim), com a porcentagem de visitas reais em cada faixa. Ver 70% de LCP na faixa verde e 15% na vermelha conta uma história diferente de "LCP médio de 2,1 segundos", porque mostra que existe uma parcela de visitantes tendo uma experiência ruim mesmo com a média parecendo boa.
-
Abra o PageSpeed Insights
Em
pagespeed.web.dev, cole a URL exata da página money (não só a home) e rode o teste em mobile e em desktop. - Leia o campo antes do laboratório Se aparecer "Dados de Experiência do Usuário no Campo", comece por ali: é o que aconteceu de verdade. Se não aparecer, use o laboratório com essa ressalva em mente.
- Abra o relatório do Search Console No menu Experiência, o relatório de Core Web Vitals agrupa as URLs do site por status: bom, precisa melhorar e ruim, separado por mobile e desktop.
- Teste em condição ruim de propósito No modo dispositivo do navegador, simule rede lenta e observe se o texto principal aparece rápido e se botões respondem sem atraso perceptível.
- Comprima a imagem de destaque. É ela que costuma ser o elemento do LCP em página de serviço e em home.
- Declare largura e altura de imagem. Sem isso o navegador reserva espaço errado, e o texto pula quando a imagem chega. Isso é CLS.
- Reserve espaço para banner e anúncio. Elemento que "chega depois" e empurra o conteúdo é a causa mais comum de CLS ruim.
- Reveja script de terceiro. Chat, pixel de anúncio e pop-up de newsletter em excesso ocupam o navegador e atrasam a resposta ao clique.
Limite declarado
Este checklist não resolve JavaScript pesado, cache de servidor, CDN mal configurado nem stack de e-commerce com dezenas de plugins. Ganho estrutural de LCP e INP costuma exigir mudança de código, e aí o diagnóstico passa do "faça sozinho".
Quando a otimização vira projeto
Volume de páginas e complexidade de stack mudam o que cabe numa tarde. Comprimir três imagens de uma página institucional é ajuste pontual. Uma loja virtual com centenas de páginas de produto, carrossel pesado e três scripts de rastreamento de terceiros é outro tipo de trabalho, que pede priorização por tráfego real e correção na origem do template, não página por página.
O sinal mais claro de que passou do ajuste pontual é o relatório do Search Console mostrar dezenas ou centenas de URLs agrupadas como "precisa melhorar" ou "ruim", todas puxadas pelo mesmo template. Corrigir uma página por vez, nesse cenário, é sintoma tratado sem tocar a causa: o problema mora no componente que se repete em todas elas, seja um carrossel de imagens, um script de chat ou uma fonte carregada do jeito errado.
É esse o trabalho que a Voh! faz, e só ele: busca orgânica, sem Ads e sem rede social. O canal é um só, e ele vale para qualquer site que precise ser encontrado, do institucional à loja virtual, incluindo a criação do site quando ele ainda não existe. São três formas de começar, uma auditoria gratuita, um pacote de implementação com seis meses de acompanhamento e o SEO Mensal, que não exige fidelidade. O diagnóstico vem sempre antes da proposta, porque orçar sem olhar o site é chute. E não existe garantia de posição: o algoritmo é do Google, e quem promete o contrário está prometendo uma decisão que não é dele. Para a história e o método, leia sobre a Voh!.
63 cliques
Premier Inox, Sorocaba, no melhor mês medido
Google Search Console. Resultado daquele projeto, não previsão para outro site.
Numa auditoria técnica, Core Web Vitals entra ao lado de rastreio, índice, canonical e mobile, porque relatório de velocidade isolado de intenção de busca vira lista de tickets sem prioridade comercial. Se a dúvida é o que pesa mais no seu caso, Fale com a Voh!: a análise volta por escrito, antes de qualquer pacote.
Os limites da velocidade no SEO
Velocidade não resolve tudo, e tratar o PageSpeed como o único termômetro do SEO é um erro comum e caro.
- Página não indexada. Core Web Vitals bons não adiantam se a URL nem entrou no índice: isso é assunto de SEO técnico, não de velocidade.
- Demanda inexistente. Site rapidíssimo não cria busca onde ninguém pesquisa o serviço.
- Conteúdo fraco. LCP perfeito numa página que não responde à pergunta de quem busca não converte ninguém.
- Autoridade consolidada do concorrente. Velocidade nivela um piso técnico; não apaga anos de links e marca do outro lado.
- Nota perfeita como meta em si. O próprio Google diz que perseguir 100 no PageSpeed só por SEO pode ser tempo mal gasto.
O que velocidade não promete
Bons Core Web Vitals não garantem primeira posição, prazo de tráfego nem volume de cliente. Eles removem um obstáculo de experiência. O resto depende de indexação, conteúdo e concorrência, sempre no tempo do algoritmo, que é do Google.
Se a urgência é lead nesta semana, ajustar LCP não é o instrumento certo sozinho: orgânico é cumulativo, e velocidade é só uma das frentes dentro dele. Dá para corrigir Core Web Vitals em paralelo a outro canal, com expectativa honesta de prazo, sem tratar performance como atalho de ranking.
Vale registrar também o que velocidade não é: não é sinônimo de SEO técnico inteiro. Rastreio, indexação, robots.txt, sitemap e canonical, cobertos no guia de SEO técnico, decidem se a página entra na disputa. Core Web Vitals decide como a experiência dela é depois que a pessoa chega. Um site pode ter os três limiares bons e ainda estar fora do índice; o inverso, um site bem indexado com Core Web Vitals ruins, também existe. São diagnósticos separados, com ferramentas separadas.
Resumo em 10 pontos
- Core Web Vitals são LCP, INP e CLS, medidos no 75º percentil.
- LCP mede carregamento: bom até 2,5 segundos.
- INP mede resposta a interação: bom até 200 milissegundos.
- CLS mede estabilidade visual: bom até 0,1.
- INP substituiu o FID em 12 de março de 2024.
- Laboratório simula; campo mede visitas reais dos últimos 28 dias.
- PageSpeed Insights e Search Console mostram os dois dados de graça.
- Não existe um sinal único de experiência de página no ranqueamento.
- Velocidade não substitui indexação, conteúdo nem autoridade.
- Ninguém garante posição; o algoritmo é do Google.
Se quiser saber o que especificamente pesa mais no seu site, entre Core Web Vitals, indexação ou conteúdo, Fale com a Voh!: a análise volta por escrito, sem custo e em até 48h, feita por uma agência de SEO que trabalha só busca orgânica.