Busca · Guia técnico
Core Web Vitals: como medir e corrigir LCP, INP e CLS
Em resumo
- As três Core Web Vitals são LCP (carregamento), INP (responsividade) e CLS (estabilidade visual).
- O INP substituiu o FID em 12 de março de 2024 e mede todas as interações da visita, não só a primeira.
- A avaliação usa o percentil 75 de visitas reais, separado entre celular e desktop, em janela de 28 dias.
- Nota de laboratório ajuda a diagnosticar, mas o que conta é o dado de campo do Search Console e do CrUX.
- As métricas pesam no SEO como parte da experiência na página, e pesam ainda mais na conversão.
O que são as Core Web Vitals
Core Web Vitals são três métricas que o Google usa para descrever a experiência real de quem abre uma página: quanto tempo o conteúdo principal leva para aparecer, quão rápido a página responde a um toque ou clique e quanto o layout se mexe enquanto carrega. Cada uma tem um nome e um limite:
- LCP (Largest Contentful Paint): mede carregamento. É o tempo até o maior elemento visível da tela, normalmente uma imagem de destaque ou um bloco de texto, ser renderizado.
- INP (Interaction to Next Paint): mede responsividade. Observa as interações da visita e registra quanto tempo a página leva para mostrar uma resposta visual.
- CLS (Cumulative Layout Shift): mede estabilidade visual. Soma os deslocamentos inesperados de elementos durante a visita.
O INP substituiu o FID (First Input Delay) como Core Web Vital em 12 de março de 2024. O FID media apenas o atraso da primeira interação. O INP considera as interações da visita inteira e inclui o tempo de processar e desenhar a resposta, o que o torna bem mais exigente. Sites que passavam com folga no FID descobriram problemas de JavaScript que antes não apareciam em nenhum relatório.
Limites oficiais e como são calculados
O web.dev, documentação de desempenho do Google, define três faixas para cada métrica. O valor considerado é o percentil 75 das visitas, separado entre celular e desktop. Ou seja, a página só é considerada boa quando pelo menos três em cada quatro visitas ficam dentro do limite.
| Métrica | O que mede | Bom | Precisa melhorar | Ruim |
|---|---|---|---|---|
| LCP | Carregamento do conteúdo principal | até 2,5 s | de 2,5 s a 4 s | acima de 4 s |
| INP | Resposta às interações | até 200 ms | de 200 ms a 500 ms | acima de 500 ms |
| CLS | Estabilidade do layout | até 0,1 | de 0,1 a 0,25 | acima de 0,25 |
O uso do percentil 75 tem uma consequência prática: a média engana. Um site pode carregar em 1,8 segundo para a maioria e em 6 segundos para quem usa celular intermediário em rede móvel. Se esse segundo grupo passa de um quarto das visitas, a página falha. Por isso olhamos sempre a distribuição por dispositivo, não um número único.
Dados de campo e dados de laboratório
Esse é o ponto que mais gera confusão em reunião. Existem dois tipos de medição, e eles respondem a perguntas diferentes:
- Dados de campo vêm de visitas reais de usuários do Chrome, agregados no Chrome UX Report (CrUX). Aparecem no relatório de Core Web Vitals do Search Console e no topo do PageSpeed Insights. São esses dados que contam para avaliação. Cobrem uma janela móvel de 28 dias, então uma correção leva semanas para aparecer por completo.
- Dados de laboratório vêm de um teste simulado, como o Lighthouse, com dispositivo e rede definidos. São úteis para diagnosticar e para testar uma correção antes de publicar, mas não refletem a variedade de aparelhos e conexões do público real.
Um site pode ter nota alta no Lighthouse e reprovar em campo, ou o contrário. O INP, em especial, quase não aparece em laboratório, porque depende de interações reais. Quando o tráfego da página é pequeno demais para o CrUX, recomendamos coletar as métricas no próprio site com a biblioteca web-vitals e enviá-las ao GA4, para ter dado de campo mesmo sem volume no relatório público.
Qual o peso real no SEO
A documentação do Google Search afirma que boas Core Web Vitals, junto com outros aspectos de experiência na página, se alinham ao que os sistemas de classificação procuram recompensar. A mesma documentação deixa claro que relevância do conteúdo continua acima de tudo. Uma página lenta com a melhor resposta para a pesquisa tende a vencer uma página rápida com resposta fraca.
Na prática, tratamos as Core Web Vitals como fator de desempate e, principalmente, como fator de conversão. Página que demora para mostrar o produto, que trava ao tocar no botão ou que move o botão de compra no último instante perde venda, independentemente da posição no Google. Em contas de mídia paga, essa perda é ainda mais visível: o clique já foi pago.
O que não prometemos: subir posições apenas por melhorar Core Web Vitals. Essas métricas entram no trabalho de SEO técnico ao lado de rastreamento, indexação, arquitetura e conteúdo.
Como melhorar o LCP
O web.dev divide o LCP em quatro partes: tempo até o primeiro byte (TTFB), atraso até o início do download do recurso, duração do download e atraso de renderização. Identificar qual parte pesa mais evita otimizar o que não é gargalo. As causas mais comuns que encontramos:
- Servidor lento ou sem cache: TTFB alto atrasa tudo o que vem depois.
- Imagem principal descoberta tarde, porque está em CSS de fundo ou é inserida por JavaScript.
- Imagem principal com lazy-loading. A orientação do web.dev é direta: nunca use carregamento tardio na imagem do LCP.
- Imagem pesada, sem formato moderno ou sem tamanhos diferentes para cada tela.
- CSS e scripts que bloqueiam a renderização no início do documento.
Para a imagem principal, o ajuste mais eficiente costuma ser marcá-la como prioridade e garantir que o navegador a encontre cedo:
<!-- Imagem do LCP: prioridade alta, sem lazy-loading, com dimensões -->
<img src="/img/destaque.webp"
width="1200" height="630"
fetchpriority="high"
alt="Descrição da imagem principal">
<!-- Se a imagem só aparece no CSS ou via JavaScript, antecipe a descoberta -->
<link rel="preload" as="image"
href="https://www.seusite.com.br/img/destaque.webp"
type="image/webp"
fetchpriority="high">
<!-- Imagens abaixo da dobra podem, essas sim, carregar depois -->
<img src="/img/secundaria.webp" width="800" height="600"
loading="lazy" alt="Descrição">Use o preload com moderação. Pré-carregar muitos recursos anula o efeito, porque todos passam a disputar a mesma prioridade.
Do lado do servidor, o TTFB melhora com cache de página, CDN próxima do público e redução de redirecionamentos encadeados. Em lojas virtuais e portais com muitas páginas dinâmicas, é comum o TTFB responder por boa parte do LCP antes de qualquer imagem entrar na conta. Por isso medimos o tempo de resposta do servidor separado das outras partes. Otimizar a imagem de destaque não resolve uma página que leva um segundo e meio só para entregar o HTML.
Como melhorar o INP
O INP de uma interação tem três fases: o atraso até o código do evento começar a rodar, o tempo de processamento desse código e o atraso até o navegador desenhar o próximo quadro. Na maioria dos sites que analisamos, o problema está no excesso de JavaScript na linha principal.
- Reduza tarefas longas. Scripts que rodam por centenas de milissegundos bloqueiam qualquer clique nesse intervalo. Dividir o trabalho e devolver o controle ao navegador entre as partes é a recomendação central do web.dev.
- Revise scripts de terceiros. Chat, mapas de calor, pixels e widgets somam peso. Cada um precisa justificar o custo.
- Faça o mínimo no clique. O código do evento deve aplicar a mudança visual primeiro e deixar o resto (envio de dados, cálculos) para depois do próximo quadro.
- Controle o tamanho do DOM. Páginas com milhares de elementos tornam cada atualização mais cara.
Em sites montados com construtores visuais e muitos plugins, o INP costuma ser a métrica mais difícil de corrigir sem rever a base. Nesses casos, discutimos com o cliente se vale remendar ou reconstruir.
Como melhorar o CLS
Deslocamento de layout quase sempre tem uma de quatro origens, e todas têm correção conhecida:
- Imagens e vídeos sem largura e altura declaradas. Com os atributos width e height, o navegador reserva o espaço antes do download.
- Anúncios, embeds e banners que chegam depois. Reserve espaço com altura mínima ou com aspect-ratio.
- Fontes web que trocam a fonte provisória e mudam o tamanho do texto. Escolher fontes de fallback com métricas parecidas reduz o salto.
- Animações que mudam posição com propriedades como top e left. Prefira transform, que não desloca outros elementos.
Avisos de cookies e barras promocionais inseridos no topo da página também são causa frequente. Se eles precisam existir, devem sobrepor o conteúdo ou ter espaço reservado desde o primeiro carregamento.
Como conduzimos um projeto de Core Web Vitals
Para sites com muitas páginas, o trabalho é por modelo de página, não página a página. Uma correção no modelo de produto resolve milhares de URLs de uma vez. O roteiro que seguimos:
- Levantamos os dados de campo no Search Console e no CrUX, agrupados por modelo de página e dispositivo.
- Escolhemos as URLs representativas de cada grupo e diagnosticamos em laboratório qual parte de cada métrica pesa mais.
- Priorizamos pelo cruzamento entre gravidade e tráfego ou receita do modelo.
- Implementamos com o time de desenvolvimento do cliente ou diretamente, conforme o caso, e validamos em laboratório antes de publicar.
- Acompanhamos os dados de campo por pelo menos um ciclo de 28 dias para confirmar a melhora real.
Quando o problema está na base do site, e não em ajustes pontuais, o caminho costuma passar por criação de sites com desempenho tratado como requisito desde o projeto, e não como correção posterior.
Perguntas frequentes
Quais são os valores bons de LCP, INP e CLS?
Pelos limites publicados no web.dev, o LCP é bom até 2,5 segundos, precisa melhorar entre 2,5 e 4 segundos e é ruim acima disso. O INP é bom até 200 milissegundos, precisa melhorar até 500 e é ruim acima de 500. O CLS é bom até 0,1, precisa melhorar até 0,25 e é ruim acima disso. Os valores valem para o percentil 75 das visitas reais, separados entre celular e desktop. Uma página só passa quando as três métricas ficam na faixa boa.
Por que o PageSpeed Insights mostra nota alta e o Search Console reprova?
Porque são medições diferentes. A nota do PageSpeed Insights vem de um teste de laboratório, com aparelho e rede simulados. O Search Console mostra dados de campo, coletados de visitas reais de usuários do Chrome nos últimos 28 dias. Se parte do seu público usa celulares mais simples ou redes lentas, o campo pode reprovar mesmo com nota alta em laboratório. O INP quase não aparece em teste simulado, porque depende de interações reais. Para decisões, priorizamos o dado de campo e usamos o laboratório para diagnóstico.
O que aconteceu com o FID?
O FID, First Input Delay, deixou de ser uma Core Web Vital em 12 de março de 2024, quando foi substituído pelo INP. O FID media só o atraso até o navegador começar a processar a primeira interação da visita. O INP observa as interações ao longo de toda a visita e inclui o processamento e a atualização da tela, por isso revela problemas que o FID escondia. O Search Console removeu o FID dos relatórios na troca, e outras ferramentas do Google fizeram a transição nos meses seguintes.
Melhorar as Core Web Vitals faz meu site subir no Google?
Não há relação direta e garantida. A documentação do Google Search diz que boas Core Web Vitals se alinham ao que os sistemas de classificação procuram recompensar, mas a relevância do conteúdo continua sendo o fator principal. Em páginas com conteúdo equivalente, a experiência pode desempatar. O ganho mais seguro costuma aparecer na conversão: páginas que carregam rápido, respondem ao toque e não mexem o layout perdem menos visitantes. Por isso tratamos o tema como parte do SEO técnico e da taxa de conversão, não como atalho de posição.
Quanto tempo leva para o Search Console mostrar a melhora?
Os dados de campo usam uma janela móvel de 28 dias, então uma correção publicada hoje aparece aos poucos e só se reflete por completo depois de cerca de quatro semanas. Depois de corrigir um grupo de páginas, o Search Console permite iniciar a validação, que acompanha o mesmo período. Enquanto isso, conferimos a correção em laboratório e, quando o site coleta métricas próprias com a biblioteca web-vitals, acompanhamos a evolução diária no GA4, sem esperar a janela pública fechar.