O que os Core Web Vitals medem sem o FID
Três métricas hoje: LCP, INP e CLS. O FID, que aparecia em quase todo guia sobre o assunto, foi substituído pelo INP em março de 2024 e não faz mais parte dos Core Web Vitals. Guia que ainda ensina FID como métrica atual está desatualizado há mais de dois anos.
- LCP mede velocidade de carregamento: bom é até 2,5 segundos.
- INP mede resposta à interação: bom é até 200 milissegundos.
- CLS mede estabilidade visual: bom é até 0,1.
- As três são avaliadas no percentil 75 das visitas, separadas por mobile e desktop.
- Uma métrica só na faixa de precisa melhorar já reprova a avaliação geral da página.
- FID não existe mais como Core Web Vital desde março de 2024, substituído pelo INP.
A maioria dos guias sobre Core Web Vitals que circula por aí ainda ensina quatro métricas, incluindo o FID. Isso é sinal de conteúdo desatualizado, não de cobertura completa.
Este texto traz as três métricas atuais, os limites certos e como melhorar cada uma.
O que são os Core Web Vitals
Core Web Vitals é o conjunto de métricas que o Google usa para avaliar a experiência real de quem usa uma página: quanto tempo leva para carregar, quão rápido ela responde a um toque e quanto ela se mexe enquanto carrega. As três juntas formam um retrato prático de como é usar o site no dia a dia, muito mais útil do que uma nota genérica de velocidade.
As três métricas atuais são Largest Contentful Paint, Interaction to Next Paint e Cumulative Layout Shift. Cada uma mede uma dimensão diferente da experiência, e as três juntas formam a avaliação completa.
O nome de cada uma explica o que ela cobre: carregamento, resposta e estabilidade. Um site pode ir bem numa dessas dimensões e mal em outra, por isso a avaliação olha as três separadamente, em vez de somar tudo numa nota única.
A avaliação acontece no percentil 75 das visitas reais do site, não numa média simples, e é medida separadamente para celular e computador. Isso significa que a maioria das visitas precisa estar na faixa boa para a página passar na avaliação geral, não só a média.
Na prática: se cem pessoas visitam uma página, o número que conta é o tempo da 75ª visita mais lenta, não a média das cem. Isso evita que um punhado de visita muito rápida esconda um problema real que afeta a maioria de quem usa o site.
LCP, o tempo até o conteúdo principal aparecer
Largest Contentful Paint mede quanto tempo leva até o maior elemento visível da tela terminar de carregar, geralmente uma imagem grande, um vídeo ou um bloco de texto principal, dependendo do que domina visualmente a primeira dobra da página.
O limite bom é até 2,5 segundos. Entre 2,5 e 4 segundos entra na faixa de precisa melhorar. Acima de 4 segundos é considerado ruim, tempo suficiente para boa parte dos visitantes desistir antes de ver o conteúdo.
Imagem pesada sem otimização, fonte que demora a carregar e servidor lento são as causas mais comuns de LCP alto. O tratamento completo de imagem está em SEO para imagens, que cobre formato, compressão e dimensão correta.
INP, a métrica que substituiu o FID
Interaction to Next Paint mede quanto tempo a página leva para responder visualmente depois que alguém clica, toca ou digita algo nela.
O limite bom é até 200 milissegundos. Entre 201 e 500 milissegundos entra na faixa de precisa melhorar. Acima de 500 milissegundos é considerado ruim, o que costuma dar a sensação de a página estar travada durante o toque.
A diferença para o FID, que o INP substituiu, é que o FID só media a primeira interação da visita. O INP mede a interação mais lenta de toda a visita, o que dá um retrato mais completo de como a página se comporta enquanto a pessoa usa ela, não só no primeiro toque.
JavaScript pesado rodando no momento da interação é a causa mais comum de INP alto. Script de terceiro, como chat ou pixel de rastreamento, carregado sem controle, também pesa bastante nessa métrica.
| Aspecto | FID (aposentado) | INP (atual) |
|---|---|---|
| O que media | Só a primeira interação da visita | Todas as interações, usando a mais lenta |
| Limite bom | Até 100 milissegundos | Até 200 milissegundos |
| Status atual | Removido em 12/03/2024 | Core Web Vital oficial desde 12/03/2024 |
| Onde aparece hoje | Nenhum relatório oficial do Google | Search Console e PageSpeed Insights |
A diferença de limite entre os dois (100ms contra 200ms) confunde muita gente, porque parece que o padrão ficou mais frouxo. Na verdade o INP mede um cenário mais difícil, a pior interação de toda a visita, então o limite maior reflete essa mudança de critério, não uma exigência menor.
CLS, o quanto a página se mexe
Cumulative Layout Shift mede o quanto os elementos da página se deslocam de forma inesperada enquanto ela carrega, como um botão que muda de lugar porque uma imagem acima dele terminou de carregar depois.
O limite bom é até 0,1. Entre 0,1 e 0,25 entra na faixa de precisa melhorar. Acima de 0,25 é considerado ruim, o suficiente para a pessoa clicar no lugar errado sem querer.
A causa mais comum é imagem ou anúncio sem dimensão definida no código, que empurra o conteúdo assim que termina de carregar. Reservar o espaço certo antes do carregamento resolve a maior parte dos casos, mesmo antes de a imagem terminar de baixar.
Banner de cookie e pop-up que aparecem depois do carregamento inicial também costumam gerar CLS alto, principalmente quando empurram o conteúdo em vez de aparecer sobrepostos a ele. A solução técnica é posicionar esses elementos de forma que não desloquem nada abaixo deles.
Como melhorar as três métricas
Otimizar imagem resolve boa parte do LCP, e também ajuda o CLS quando a dimensão da imagem é declarada corretamente no código. Formato mais moderno de imagem, com compressão maior sem perda visível de qualidade, costuma reduzir o tempo de carregamento sem exigir troca de servidor.
Reduzir JavaScript desnecessário, principalmente script de terceiro que a página não precisa para funcionar, é o que mais ajuda no INP. Carregar esse tipo de script depois da interação inicial, em vez de no carregamento da página inteira, costuma resolver sem precisar remover a funcionalidade.
Reservar espaço fixo para imagem, vídeo e anúncio antes deles carregarem evita a maior parte dos problemas de CLS. Fonte carregada de forma que não desloca o texto ao redor também ajuda.
O trabalho de melhorar as três métricas se encaixa dentro do checklist de SEO técnico, que cobre o restante da parte técnica de um site.
Tema de WordPress pesado, com muito recurso visual carregado de uma vez, costuma afetar as três métricas ao mesmo tempo. Trocar por um tema mais leve, ou remover plugin que ninguém usa mais, resolve boa parte do problema antes de qualquer ajuste fino.
Por que Core Web Vitals importa para SEO
Core Web Vitals faz parte dos sinais que o Google usa para avaliar a experiência de página, dentro de um conjunto maior de fatores de ranqueamento.
Não é o fator isolado que decide posição, mas página com Core Web Vitals ruim compete em desvantagem contra concorrente com desempenho melhor, principalmente quando o conteúdo dos dois é parecido em qualidade.
Isso importa mais em nicho concorrido, onde vários sites respondem à mesma pergunta com qualidade parecida. Nesse cenário, a experiência técnica passa a pesar mais na decisão do que pesaria num nicho com pouca concorrência de conteúdo.
O efeito indireto costuma pesar mais que o direto: página lenta ou que se mexe demais faz a pessoa sair antes de ler o conteúdo, e isso conecta direto com experiência do usuário, outro sinal que o Google acompanha pelo comportamento de quem visita.
Como medir as três métricas do seu site
O relatório de Core Web Vitals dentro do Search Console mostra dado real de visitante, coletado ao longo do tempo, separado por página e por dispositivo. Ele agrupa páginas parecidas, então corrigir um problema num modelo de página costuma refletir em várias URLs de uma vez.
Ferramenta de teste pontual, como o PageSpeed Insights, mostra uma simulação de laboratório, útil para testar mudança antes de publicar, mas diferente do dado real de campo que o Search Console usa para a avaliação oficial. Ela também gera uma nota de zero a cem, que muita gente confunde com a avaliação oficial de Core Web Vitals, quando na verdade são coisas relacionadas, mas não idênticas.
A diferença entre os dois é importante: uma página pode passar bem no teste de laboratório e ainda reprovar no relatório de campo, porque o teste roda uma vez, num ambiente controlado, e o campo mede a experiência real de gente usando internet variada, em aparelho variado.
Erros comuns
Seguir guia desatualizado que ainda ensina FID como métrica atual é o erro mais comum agora, porque o conteúdo que circula sobre o assunto demorou para se atualizar depois da troca em 2024. Isso leva a otimizar o que não é mais medido, enquanto o que de fato conta continua sem ajuste.
Otimizar apenas para o teste de laboratório, sem checar o relatório de campo do Search Console, vem logo depois. Os dois números podem divergir bastante, e o que conta para a avaliação do Google é o dado de campo.
Outros erros frequentes:
- Adicionar script de terceiro sem medir o impacto dele no INP antes e depois.
- Deixar imagem sem dimensão declarada, mesmo depois de otimizar o peso do arquivo.
- Testar só no computador, ignorando que a avaliação de celular costuma ser mais rigorosa.
- Tratar Core Web Vitals como projeto único, em vez de acompanhamento contínuo conforme o site muda.
- Comparar limite de FID com limite de INP como se fossem a mesma escala, sem entender que os critérios de medição mudaram.
Quando o peso está na estrutura do site, e não num ajuste pontual, remendo não resolve. É o ponto de partida da nossa criação de sites: site leve desde a base, para não depender de correção depois.
Perguntas frequentes
FID ainda é um Core Web Vital?
Não. O INP substituiu o FID em março de 2024. Página com guia ensinando FID como métrica atual está desatualizada.
Qual é o limite bom de cada métrica?
LCP até 2,5 segundos, INP até 200 milissegundos, CLS até 0,1. Acima disso entra em precisa melhorar ou ruim, dependendo do quanto passa do limite.
Core Web Vitals é fator de ranqueamento direto?
É um entre vários sinais que compõem a avaliação de experiência de página, não um fator isolado que decide posição sozinho.
Por que meu site passa no teste, mas reprova no Search Console?
Porque são medições diferentes. O teste roda uma simulação de laboratório uma vez; o Search Console usa dado real de visitante ao longo do tempo, que reflete melhor a experiência de fato.
Uma métrica ruim reprova a página inteira?
Sim. Se qualquer uma das três estiver fora da faixa boa no percentil 75, a página não passa na avaliação geral de Core Web Vitals, mesmo com as outras duas boas.
Preciso de desenvolvedor para corrigir Core Web Vitals?
Depende do problema. Otimização de imagem costuma resolver sem código. Redução de JavaScript de terceiro geralmente exige ajuste técnico.
Quanto tempo leva para o Search Console atualizar o relatório depois de uma correção?
Como o relatório usa dado de campo acumulado ao longo do tempo, a atualização costuma levar semanas, não dias. É normal a melhoria não aparecer de imediato mesmo com a correção já no ar.
Todo site precisa se preocupar com Core Web Vitals?
Vale mais para site com bastante concorrência de conteúdo parecido, onde a experiência de página pode ser o critério que desempata a posição entre resultados de qualidade similar.
Por onde começar
Quem trabalha Core Web Vitals costuma se esforçar no lugar errado, seguindo informação desatualizada sobre quantas métricas existem e o que cada uma mede hoje.
O critério que deve orientar qualquer correção: confira sempre o relatório de campo do Search Console antes de decidir o que otimizar, e trate as três métricas atuais, sem perder tempo com o FID que já saiu de cena há anos.
Nenhuma dessas três métricas se corrige sozinha com o tempo, sem intervenção. Se você quer saber como o seu site está nas três métricas atuais, gravamos uma análise gratuita mostrando o que encontramos, sem custo e sem compromisso.