Core Web Vitals são três métricas de campo usadas para observar carregamento, resposta às interações e estabilidade visual: LCP, INP e CLS. Como referência, o Google considera bons, no percentil 75 das visitas, LCP de até 2,5 segundos, INP de até 200 milissegundos e CLS de até 0,1. Esses limites ajudam a diagnosticar experiência; não garantem posição no Google.
O conjunto não é uma nota geral de qualidade nem uma lista de otimizações iguais para todo site. Primeiro descubra qual métrica está falhando, em quais páginas e dispositivos; depois procure a causa correspondente.
Quais são as métricas atuais?
| Métrica | O que observa | Limite de referência “bom” |
|---|---|---|
| LCP (Largest Contentful Paint) | Quando o maior elemento de conteúdo visível é renderizado. | Até 2,5 s |
| INP (Interaction to Next Paint) | A responsividade das interações ao longo da visita, até a próxima atualização visual. | Até 200 ms |
| CLS (Cumulative Layout Shift) | Mudanças inesperadas na posição dos elementos durante a vida da página. | Até 0,1 |
Em telas menores, deslize a tabela na horizontal para ver todas as colunas.
Os valores devem ser avaliados no percentil 75 e separados entre celular e desktop. A definição oficial e os limites podem mudar; confira a documentação de Web Vitals ao fazer uma auditoria.
Atenção: FID (First Input Delay) não é mais uma Core Web Vital. O INP o substituiu em março de 2024. Materiais, extensões ou relatórios antigos que apresentam FID como métrica atual estão desatualizados.
Dados de campo e testes de laboratório
Dados de campo representam visitas reais e variam conforme dispositivo, rede, localização e interação. O Chrome UX Report (CrUX) agrega dados de usuários que atendem aos critérios de coleta; não é um registro completo de todas as visitas do seu site.
Testes de laboratório são execuções controladas, úteis para investigar alterações durante desenvolvimento e comparar hipóteses. Eles não reproduzem toda a variedade de condições reais. Por exemplo, uma execução automatizada do Lighthouse não consegue medir INP sem interação do usuário; o Total Blocking Time (TBT) pode servir como pista de laboratório para problemas de responsividade, mas não é INP.
Uma leitura prática combina as duas fontes:
- Consulte o relatório de Core Web Vitals do Search Console ou o PageSpeed Insights para identificar grupos de URLs e dados de campo disponíveis.
- Escolha uma URL representativa do grupo com problema.
- Rode um teste de laboratório para observar recursos, imagens, scripts e deslocamentos.
- Formule uma hipótese e altere uma causa por vez.
- Compare novamente em laboratório e acompanhe dados de campo depois da publicação, quando houver volume suficiente.
O PageSpeed Insights exibe dados de campo quando disponíveis e diagnósticos de laboratório. Uma pontuação de laboratório, sozinha, não descreve todas as visitas nem comprova melhora orgânica.
Como investigar cada métrica
LCP alto: encontre o elemento principal e o gargalo
O LCP costuma corresponder a uma imagem, bloco de texto ou outro elemento grande visível na primeira tela. Investigue o próprio elemento e o caminho necessário para apresentá-lo: resposta do servidor, descoberta do recurso, transferência, CSS e JavaScript que bloqueiam a renderização.
Verifique se a imagem principal tem dimensões e formato adequados, se não está carregando com atraso indevido e se fontes ou estilos essenciais atrasam a primeira renderização. Não aplique preload indiscriminadamente: priorize o recurso que o diagnóstico identifica como LCP.
INP alto: observe o que acontece após a ação
INP considera as interações ao longo da visita, incluindo o tempo até iniciar o processamento, a execução dos handlers e a apresentação do próximo quadro. Reproduza ações reais — abrir menu, filtrar, enviar formulário — e procure tarefas longas, trabalho excessivo no thread principal, listeners custosos ou atualização ampla demais da interface.
Um bom resultado em laboratório não comprova INP bom em campo. É necessário observar interações reais em dados de usuários ou reproduzir o fluxo com ferramentas que aceitem entrada.
CLS alto: elimine deslocamentos inesperados
Confira se imagens, vídeos, anúncios e embeds reservam espaço antes de carregar; se fontes tardias mudam a quebra dos textos; e se componentes são inseridos acima do conteúdo já visível. Definir proporção/tamanho para mídia e evitar inserir conteúdo inesperado costuma ajudar a encontrar a causa — mas valide a mudança na página real.
O que as Core Web Vitals dizem — e o que não dizem
As métricas ajudam a identificar fricções técnicas, mas não medem sozinhas clareza da oferta, qualidade do conteúdo, acessibilidade completa, satisfação ou conversão. A documentação do Google afirma que Core Web Vitals são usadas pelos sistemas de ranking, mas também deixa claro que bons resultados não garantem posições altas e que experiência de página não é um único sinal. Veja a orientação do Google sobre experiência da página na Busca.
Por isso, não trate uma nota 100 como objetivo universal nem mude um site estável para perseguir uma pontuação sem entender o problema e o impacto para quem usa a página. Priorize correções que removem espera, bloqueios ou deslocamentos que atrapalham uma tarefa concreta.
Checklist de diagnóstico
- O relatório usa dados de campo, de laboratório ou ambos?
- A amostra tem dados suficientes e está segmentada por celular e desktop?
- Quais URLs pertencem ao grupo com problema e qual elemento ou interação é afetado?
- A hipótese corresponde à métrica (carregamento, resposta ou estabilidade)?
- A correção melhora a tarefa da pessoa sem esconder o conteúdo ou quebrar outra tela?
- Após a mudança, foram repetidos os testes e anotadas as condições de comparação?
Para se aprofundar, veja o guia de otimização de Core Web Vitals em cinco passos e o conteúdo de melhoria da velocidade de um site. Se a necessidade for criar ou reconstruir um site, conheça o processo de criação de sites; uma avaliação precisa depende das páginas, integrações e prioridades do projeto.
