Metade da web reprovaria no exame mais básico de performance do Google. Em 2024, segundo o , apenas 48% dos sites acessados no celular passaram nas três Core Web Vitals. Traduzindo o número: enquanto você lê esta frase, um em cada dois concorrentes entrega uma experiência que o próprio Google classifica como ruim.
As Core Web Vitals são esse exame. E a maioria não estudou.
O artigo que você talvez tenha lido por aí trata o assunto como uma lista de boas intenções (“melhore a experiência”, “aumente conversões”). Isso não é estratégia, é pôster motivacional. Performance de verdade tem nome, número e limiar. Aqui você vai sair sabendo exatamente o que medir, qual nota precisa tirar e o que fazer quando a nota vier vermelha.
As Core Web Vitals são um conjunto de três métricas com que o Google quantifica a experiência real de quem usa o seu site: velocidade de carregamento, responsividade à interação e estabilidade visual. Elas fazem parte do sinal de “experiência da página” e são medidas com dados de usuários reais, não com simulações de laboratório.
A diferença em relação a métricas antigas de velocidade é a régua. O Google não pergunta “seu site é rápido?”. Ele pergunta “seu site é rápido para a maioria dos seus visitantes reais, nos aparelhos e conexões que eles realmente usam?”. É uma pergunta muito mais difícil de fraudar.
Hoje as Core Web Vitals são compostas por três métricas. Cada uma tem um limiar oficial para ser considerada “boa”, um intervalo de “precisa melhorar” e uma zona “ruim”. Passar significa ficar na faixa boa no 75º percentil dos seus acessos.
| Métrica | O que mede | Bom | Ruim |
|---|---|---|---|
| LCP (Largest Contentful Paint) | Tempo até o maior elemento visível carregar | ≤ 2,5 s | > 4,0 s |
| INP (Interaction to Next Paint) | Responsividade a cada clique, toque ou tecla | ≤ 200 ms | > 500 ms |
| CLS (Cumulative Layout Shift) | Estabilidade visual, o quanto a página “pula” | ≤ 0,1 | > 0,25 |
O LCP (Largest Contentful Paint) marca o instante em que o maior elemento da tela inicial fica visível, normalmente a imagem principal ou o bloco de texto do topo. É a métrica que responde à pergunta mais primitiva do visitante: “essa página vai abrir ou não?”.
O limiar é 2,5 segundos. Acima de 4 segundos, o Google considera ruim. Os vilões clássicos são imagens pesadas sem compressão, servidor lento de resposta inicial, e recursos que bloqueiam a renderização (CSS e JavaScript que o navegador precisa baixar antes de desenhar qualquer coisa).
O INP (Interaction to Next Paint) mede quanto tempo a página leva para responder visualmente a cada interação do usuário, do primeiro clique até o último. Desde 12 de março de 2024, o INP substituiu oficialmente o antigo FID (First Input Delay) como a métrica de responsividade das Core Web Vitals, conforme a .
A troca não foi cosmética. O FID só media o atraso da primeira interação, e media apenas a parte mais fácil dela. O INP olha todas as interações da sessão e mede o ciclo completo: atraso de entrada, tempo de processamento e atraso de apresentação. Como o usuário passa cerca de 90% do tempo na página depois que ela carregou, faz sentido cobrar responsividade durante toda a visita, não só no primeiro toque. O limiar bom é 200 milissegundos. Quem dependia de JavaScript pesado para “parecer rápido” no carregamento levou um susto quando o INP entrou.
O CLS (Cumulative Layout Shift) mede instabilidade visual. É aquele momento em que você vai tocar num botão e um banner carrega atrasado, empurra o layout e você clica em outra coisa. Cada salto inesperado conta pontos contra você.
O limiar bom é 0,1. As causas mais comuns são imagens e anúncios sem dimensões reservadas, fontes que trocam de tamanho ao carregar, e conteúdo injetado dinamicamente acima do que o usuário já estava lendo. CLS alto é o tipo de problema que o dono do site nunca percebe, porque ele já decorou onde tudo fica. O visitante novo é quem sofre.
Resposta direta: as Core Web Vitals são fator de ranqueamento confirmado pelo Google desde 2021, dentro do sinal de experiência da página. Não são o fator mais forte, conteúdo e relevância pesam mais, mas funcionam como critério de desempate entre páginas que disputam a mesma posição com qualidade de conteúdo parecida.
É aí que mora o valor real. Em um nicho competitivo, dezenas de páginas respondem bem à mesma busca. O Google precisa ordenar todas. Quando o conteúdo empata, quem oferece a experiência mensuravelmente melhor sobe. As Core Web Vitals são um dos sinais que o Google confirma usar, mas estão longe de ser o único: elas dividem espaço com dezenas de outras , do conteúdo aos backlinks. Antes de mexer em milissegundos, vale alinhar o básico. Se você ainda tem dúvida sobre e como o buscador decide o que mostrar, comece por aí.
Há também o efeito indireto, e ele costuma ser maior que o direto. Um site lento aumenta a taxa de rejeição. Taxa de rejeição alta sinaliza para o Google que a página não satisfez a intenção de busca. Menos satisfação, menos ranqueamento. As Core Web Vitals influenciam a posição duas vezes: como sinal explícito e como causa do comportamento que vira sinal implícito.
A discussão sobre Core Web Vitals quase sempre para no SEO. Erro de quem nunca olhou o faturamento. A performance da página é uma das poucas alavancas que melhoram ranqueamento e taxa de conversão ao mesmo tempo.
Os números são brutais. Em uma análise de dados reais de usuários, a encontrou conversão duas vezes maior ao comparar visitantes com LCP de 2 segundos contra visitantes com LCP de 5 segundos, com conteúdo idêntico. Mesma oferta, mesmo público, mesma página. A única variável foi o tempo de carregamento, e ela dobrou a receita.
Pense no que isso significa para o seu investimento em mídia. Você paga pelo clique. O anúncio funciona, o usuário clica, e a landing page lenta devolve metade dessa gente antes da página abrir. Você financiou a visita e jogou no lixo na porta de entrada. Otimizar Core Web Vitals é, na prática, recuperar verba de tráfego pago que estava vazando por lentidão.
Para um negócio que fatura acima de seis dígitos por mês, cada décimo de segundo de LCP em uma página de conversão é dinheiro saindo do caixa em silêncio.
Você não otimiza o que não mede. Há duas categorias de ferramenta, e confundir as duas é o erro número um de quem está começando.
Dados de campo (field data) vêm de usuários reais via Chrome User Experience Report (CrUX). São o que o Google de fato usa para ranquear. Reflete os aparelhos, as conexões e os comportamentos do seu público real.
Dados de laboratório (lab data) vêm de um teste simulado, em ambiente controlado. Servem para diagnosticar e reproduzir problemas, não para representar a realidade.
As ferramentas que importam:
A regra de ouro: decisão de prioridade se toma com dado de campo. Diagnóstico de causa se faz com dado de laboratório.
Diagnóstico sem ação é relatório bonito. Aqui está o que move cada métrica na direção certa.
O LCP quase sempre melhora atacando quatro frentes. Comprima e converta as imagens para formatos modernos como WebP ou AVIF, e nunca sirva uma imagem de 2.000 pixels para um espaço de 600. Reduza o tempo de resposta do servidor com cache e, quando fizer sentido, uma CDN. Elimine recursos que bloqueiam a renderização, adiando JavaScript não essencial e enxugando o CSS crítico. Por fim, pré-carregue o maior elemento da tela inicial para o navegador buscá-lo cedo.
INP ruim é quase sempre JavaScript demais rodando na thread principal. Quebre tarefas longas em pedaços menores para o navegador conseguir responder a cliques entre uma e outra. Remova scripts de terceiros que você não usa (cada tag de monitoramento esquecida cobra seu preço). Adie o que não precisa rodar no carregamento. E teste a interatividade no aparelho mais fraco do seu público, não no seu celular topo de linha, que esconde o problema.
CLS se resolve com disciplina, não com mágica. Defina largura e altura explícitas em toda imagem e vídeo, para o navegador reservar o espaço antes do conteúdo chegar. Reserve áreas fixas para anúncios e banners. Use estratégias de carregamento de fonte que evitem o salto de texto. E nunca injete conteúdo acima do que o usuário já está lendo, salvo em resposta a uma ação dele.
Se o seu diagnóstico apontou lentidão generalizada, o problema raramente é uma métrica isolada, e o nosso guia de como cobre as frentes que este artigo não esgota.
Esta seção existe porque vejo o mesmo equívoco toda semana. Alguém roda o Lighthouse, vê nota 100, e conclui que está resolvido. Duas semanas depois, o Search Console insiste que as URLs estão “ruins”. O cliente acha que o Google está errado. O Google não está errado.
A nota 100 do Lighthouse é laboratório: um teste único, numa máquina potente, com conexão estável. O ranqueamento usa campo: a experiência agregada de milhares de visitantes reais, muitos num celular intermediário com 4G instável no fim do mês. Os dois números medem coisas diferentes e divergir é o esperado.
Otimize para o campo. O laboratório é o microscópio que ajuda a achar a causa, nunca o boletim que vale nota.
Hora da verdade que os guias de checklist evitam. Core Web Vitals não compensam conteúdo fraco. Um site relâmpago que não responde à intenção de busca continua sendo um site relâmpago invisível. A performance é critério de desempate, não substituto de relevância.
Passar nas três métricas também não garante a primeira posição. Garante que você não vai perder posição por causa delas. É proteção, não promoção. Quem vende otimização de Core Web Vitals como atalho para o topo está vendendo ilusão.
E há um custo de oportunidade real. Se o seu site tem problema grave de conteúdo, de arquitetura ou de autoridade, gastar três meses raspando 200 milissegundos de INP é prioridade errada. Performance entra na conta quando o fundamento já está de pé. Na Fresh Lab, a sequência é sempre essa: primeiro o conteúdo merece ranquear, depois a técnica garante que nada o atrapalhe.
O que são Core Web Vitals em poucas palavras?
São três métricas com que o Google mede a experiência real do usuário em uma página: LCP (velocidade de carregamento), INP (responsividade às interações) e CLS (estabilidade visual). São avaliadas com dados de usuários reais e fazem parte dos fatores de ranqueamento do Google desde 2021.
Qual a diferença entre FID e INP?
O FID media apenas o atraso da primeira interação do usuário com a página. O INP, que o substituiu em 12 de março de 2024, mede a responsividade de todas as interações da sessão e captura o ciclo completo de resposta. O limiar bom do INP é de 200 milissegundos ou menos.
Quais são os valores ideais das Core Web Vitals?
Para ser classificado como “bom”, o site precisa atingir, no 75º percentil dos acessos reais: LCP de até 2,5 segundos, INP de até 200 milissegundos e CLS de até 0,1. Valores acima de 4 segundos (LCP), 500 milissegundos (INP) ou 0,25 (CLS) caem na faixa “ruim”.
Core Web Vitals melhoram o posicionamento no Google?
Sim, mas como critério de desempate, não como fator dominante. Entre páginas com qualidade de conteúdo parecida, a que oferece melhor experiência tende a ranquear acima. O efeito indireto também conta: sites lentos elevam a rejeição, e isso sinaliza insatisfação ao Google.
Como testar as Core Web Vitals de graça?
Use o PageSpeed Insights para ver dados de campo e de laboratório juntos, e o relatório de Core Web Vitals do Google Search Console para acompanhar todas as URLs do site por status. Ambos são gratuitos e usam a mesma base de dados que o Google considera no ranqueamento.
Metade da web reprovou no exame e segue achando que o problema é o Google ser exigente. Não é. O Google só está medindo, com número e testemunha, aquilo que o seu visitante sente em silêncio e o seu concorrente já corrigiu. Velocidade não é detalhe de programador. É a primeira impressão que acontece antes da sua primeira palavra ser lida.
We Grow Together!
