Uma página pode parecer rápida no computador do desenvolvedor e ainda demorar para mostrar seu conteúdo principal no celular de quem chega por uma conexão instável. É por isso que Core Web Vitals SEO exige olhar para a experiência medida em condições reais, além de ajustar o que aparece nos testes técnicos.
As métricas ajudam a identificar problemas de carregamento, resposta a interações e estabilidade visual. Corrigi-las pode tornar o site mais agradável de usar e atender a um aspecto da experiência na página considerado pelo Google, mas não garante posições melhores: relevância, qualidade e outros sinais também influenciam a busca.
O que são Core web Vitals e como se relacionam com SEO?
Core Web Vitals são um conjunto de métricas de campo que avaliam aspectos da experiência de usuários em páginas da web: carregamento do conteúdo principal, resposta às interações e estabilidade visual. Para SEO, elas ajudam a diagnosticar fricções que podem prejudicar o uso, mas não substituem conteúdo relevante nem garantem uma posição específica nos resultados.
Em termos simples, elas tentam responder a três perguntas: a página mostrou logo o que importa? Reagiu quando a pessoa interagiu? O conteúdo ficou no lugar enquanto carregava? Essas medidas integram a avaliação da experiência na página, conforme explica o Google Search Central.
Velocidade do site e Core Web Vitals estão relacionadas, mas não são sinônimos. Uma página pode baixar arquivos rapidamente e ainda apresentar um botão que demora a responder; também pode carregar sem grande atraso, mas deslocar o texto quando um anúncio aparece. Para organizar outros ajustes de conteúdo e estrutura, veja também este guia de otimização on-page para tráfego.
Quais são as métricas Core web Vitals e seus limites?
Os limites considerados bons são LCP de até 2,5 segundos, INP de até 200 milissegundos e CLS de até 0,1. A avaliação considera o percentil 75 das visitas, separado entre dispositivos móveis e computadores: isso significa que pelo menos 75% das experiências precisam ficar dentro do limite para a métrica ser classificada como boa.
Métrica O que mede Bom Precisa melhorar Ruim LCP Tempo até o maior elemento de conteúdo visível ser renderizado Até 2,5 s Acima de 2,5 s até 4 s Acima de 4 s INP Tempo de resposta visual às interações feitas durante a visita Até 200 ms Acima de 200 ms até 500 ms Acima de 500 ms CLS Instabilidade visual causada por mudanças inesperadas no layout Até 0,1 Acima de 0,1 até 0,25 Acima de 0,25
O LCP (Largest Contentful Paint) costuma corresponder à imagem principal, ao título ou a outro bloco grande visível. O INP (Interaction to Next Paint) observa a resposta a interações ao longo da visita, como toques e cliques. Já o CLS (Cumulative Layout Shift) representa mudanças inesperadas na disposição dos elementos, e não qualquer alteração visual solicitada pela própria pessoa.
As definições e os valores são documentados em Core Web Vitals no web.dev. Uma pontuação isolada não descreve toda a experiência: vale conferir qual elemento foi medido e em quais condições a página foi usada.
Como medir os Core web Vitals de uma página?
Use PageSpeed Insights para combinar dados de campo disponíveis com um teste de laboratório; consulte o Search Console para encontrar grupos de URLs com problemas; e use o Lighthouse para investigar uma execução controlada. Cada ferramenta responde a uma pergunta diferente, então não interprete seus resultados como medições equivalentes.
- PageSpeed Insights: mostra dados reais do Chrome UX Report (CrUX), quando existem para a página, e diagnósticos de laboratório produzidos em uma execução simulada.
- Search Console: apresenta grupos de páginas classificados com base nos dados de campo do CrUX, facilitando a identificação de problemas compartilhados.
- Lighthouse: testa uma página em condições controladas, úteis para localizar gargalos e validar mudanças durante o desenvolvimento.
Por que o Lighthouse pode mostrar um resultado diferente do Pagespeed Insights?
Porque o Lighthouse executa um teste de laboratório em condições simuladas, enquanto os dados de campo do PageSpeed Insights vêm de experiências reais registradas no CrUX durante um período de coleta. A velocidade do dispositivo, a rede, a localização e as interações variam entre pessoas; além disso, uma execução de laboratório pode não reproduzir o mesmo percurso que gerou os dados de campo.
Se o laboratório aponta um LCP alto, mas o campo está bom, investigue a diferença antes de alterar o site às cegas. O teste pode ter usado uma conexão mais limitada, ou o elemento principal pode variar entre páginas. Para entender o tráfego que chega ao conteúdo por canais diferentes, este material sobre tráfego orgânico para o site complementa a análise, mas não substitui o diagnóstico técnico.
Como melhorar o LCP e carregar mais rápido o conteúdo principal?
Para melhorar o LCP, descubra primeiro qual elemento foi registrado como o maior conteúdo visível e reduza o tempo até ele aparecer. Otimizar uma imagem que não é esse elemento pode economizar dados sem melhorar a métrica que está fora do limite.
Se o LCP for uma imagem de destaque, use dimensões adequadas, compressão eficiente e formatos modernos quando houver suporte. Evite carregá-la com lazy loading se ela já aparece na primeira tela: esse atraso pode impedir que o navegador priorize o elemento mais importante. Quando fizer sentido, sinalize seu carregamento prioritário e confirme que o arquivo está disponível sem uma sequência longa de solicitações.
Se o elemento principal for texto, procure recursos que bloqueiam a renderização, como CSS ou JavaScript que o navegador precisa processar antes de exibir o conteúdo. No servidor, avalie o tempo de resposta e o uso de cache. Um servidor lento afeta o início do carregamento; scripts, estilos ou fontes que chegam tarde podem atrasar o LCP mesmo com uma resposta inicial rápida.
Um erro recorrente é priorizar imagens fora da tela enquanto a imagem principal continua sem prioridade. A lista de solicitações prioritárias e o elemento LCP identificados no Lighthouse ajudam a distinguir esses casos.
Como melhorar o INP e deixar a página mais responsiva?
Para reduzir o INP, diminua o trabalho que o navegador precisa fazer quando alguém toca, clica ou digita, principalmente o JavaScript executado na thread principal. Uma página pode carregar rápido e ainda travar quando abre um menu ou atualiza um filtro.
- Remova scripts e funcionalidades que não são usados naquela página.
- Divida tarefas longas em partes menores, permitindo que o navegador processe interações entre elas.
- Adie código que não é necessário para a primeira interação e carregue recursos sob demanda quando apropriado.
- Revise eventos de clique, menus, filtros e formulários; evite cálculos pesados e atualizações excessivas do DOM durante a interação.
O INP depende do comportamento da página durante a visita, não apenas do carregamento inicial. No diagnóstico, observe a interação afetada e a duração das tarefas de JavaScript; reduzir o peso total dos arquivos sem corrigir a tarefa que bloqueia a resposta pode não resolver o problema.
Como reduzir o CLS e evitar mudanças inesperadas no layout?
Para reduzir o CLS, reserve espaço para imagens, vídeos, anúncios e outros elementos antes de eles carregarem. Quando o navegador conhece as dimensões, consegue manter o espaço previsto e evita empurrar o conteúdo que já está na tela.
Defina largura e altura ou uma proporção de aspecto para imagens e vídeos. Para anúncios e conteúdo incorporado, reserve uma área compatível com o espaço que esses elementos costumam ocupar; se o tamanho variar, escolha uma reserva que evite deslocamentos nas telas mais comuns.
Fontes também podem alterar a disposição: a troca da fonte provisória pela fonte final pode mudar quebras de linha e deslocar elementos. Use estratégias de carregamento que reduzam esse efeito e confira o layout em dispositivos reais ou emulações de tamanhos diferentes. Conteúdo inserido no topo da página depois que ela já carregou, como uma faixa ou aviso, merece atenção especial: se necessário, reserve espaço ou mostre a mensagem sem deslocar o que a pessoa está lendo.
Como priorizar correções e acompanhar os resultados?
Priorize páginas com tráfego ou valor para o negócio, problemas de campo e uma causa técnica identificável; depois procure corrigir a causa comum a um modelo de página, não apenas uma URL isolada. Uma correção de template pode resolver o mesmo defeito em várias páginas, enquanto um problema exclusivo de uma página exige tratamento próprio.
O Search Console e o CrUX agrupam páginas semelhantes, mas isso não significa que todas se comportem da mesma forma. Use os grupos para localizar padrões e verifique URLs representativas, incluindo páginas com estruturas ou funcionalidades diferentes. Uma página de produto com galeria e avaliações, por exemplo, pode ter causas de INP ou CLS que não existem em um artigo simples.
O que significa não haver dados de campo para uma página?
Significa que o CrUX não tem dados suficientes para apresentar uma medição de campo daquela URL ou do grupo correspondente no contexto consultado. Isso não prova que a página seja rápida nem que tenha problemas; use testes de laboratório e investigue páginas semelhantes com dados, sem tratar a falta de registro como aprovação.
Quanto tempo os dados de campo levam para refletir uma correção?
Não há um prazo único: os dados de campo são agregados em uma janela móvel de 28 dias, por isso uma mudança pode levar semanas para aparecer por completo. Testes de laboratório confirmam efeitos técnicos logo após a publicação, mas não substituem a observação do tráfego real nesse período.
Depois de publicar, teste novamente as URLs afetadas e confirme que a correção chegou ao ambiente de produção. Em seguida, acompanhe o Search Console e o PageSpeed Insights; se a métrica não mudar, confira se o elemento diagnosticado continua igual e se a alteração foi aplicada ao modelo correto.
Para planejar ajustes de conteúdo junto com melhorias técnicas, veja também como criar conteúdo evergreen para SEO. A qualidade da página depende de mais de um aspecto, e uma métrica isolada não representa todo o trabalho de otimização.
Dúvida Resposta em uma linha O que medir? LCP, INP e CLS com dados de campo e diagnósticos de laboratório. O que corrigir primeiro? A causa técnica que afeta páginas importantes e aparece nos dados de usuários. É preciso revisar cada URL? Agrupe por modelo, mas valide páginas representativas e exceções. Quando conferir de novo? Teste em laboratório após publicar e acompanhe o campo ao longo da janela de 28 dias.
O próximo passo é abrir o Search Console, identificar o grupo de URLs com pior avaliação e escolher uma página representativa. No PageSpeed Insights, confirme qual métrica falha e qual elemento ou interação a provoca; só então priorize a correção correspondente e registre a data de publicação para comparar os dados depois.
📱 Veja este conteúdo em Web Story
Perguntas frequentes
Uma boa pontuação no Lighthouse garante melhor posição no Google?
Não. A nota do Lighthouse é um diagnóstico de laboratório, e uma pontuação alta não garante melhora de ranking. Ela pode orientar correções, mas o posicionamento depende de vários fatores, incluindo a relevância do conteúdo.
O INP substituiu qual métrica?
O INP substituiu o FID como métrica Core Web Vitals em março de 2024. O INP avalia a responsividade considerando interações ao longo da visita, enquanto o FID se concentrava no atraso da primeira interação.
Preciso otimizar todo o Javascript do site?
Não necessariamente. Comece pelos scripts e tarefas associados às interações que apresentam INP ruim. Remover ou adiar código sem verificar suas funções pode quebrar recursos úteis e não melhorar a experiência medida.
