Vamos conversar

Performance

Core Web Vitals: diagnosticar e melhorar

Entenda LCP, INP e CLS, investigue dados reais e de laboratório, priorize correções por template e valide melhorias sem confundir métricas.

Nível: Intermediário 10 min de leitura Atualizado em Por Fernando Souza

Nesta página

O que é e como funciona

Core Web Vitals são métricas de experiência real de carregamento, interatividade e estabilidade visual. Otimização deve considerar dados de campo e contexto de dispositivo.

Imagens hero pesadas, scripts de terceiros, tarefas longas no navegador, fontes e banners sem espaço reservado degradam a experiência. Templates compartilhados podem multiplicar o mesmo problema por centenas de páginas.

Qual problema resolve

Resolve problemas de experiência medidos em usuários reais: demora para exibir o conteúdo principal (LCP), lentidão para responder a interações (INP) e deslocamentos inesperados de layout (CLS). Esses problemas afetam a percepção de qualidade, as conversões e podem pesar na avaliação de experiência da página pelos buscadores.

Diagnosticar por métrica e por template evita otimizações pontuais que melhoram uma nota de laboratório sem mudar os dados de campo. O objetivo é corrigir a causa no componente compartilhado, e não maquiar uma única URL.

Páginas lentas ou instáveis podem frustrar usuários e prejudicar etapas de conversão. As métricas também participam dos sistemas de classificação do Google, mas melhorar um número isolado não garante aumento de tráfego ou receita.

Quando utilizar

  • Páginas lentas ou com instabilidade visual.
  • Problemas em relatórios de experiência do usuário em dispositivos móveis.

Quando não utilizar

  • A página está lenta por indisponibilidade de servidor ou erro funcional: corrija a falha antes de otimizar métricas de experiência.
  • O problema é exclusivamente de indexação, canonical ou conteúdo: Core Web Vitals não substituem essas correções.
  • Não há dados de campo suficientes: não classifique a experiência como boa ou ruim apenas pela ausência de CrUX.

Matriz de decisão

Situação O que usar Por quê
Imagem principal (hero) carregada com loading="lazy" Remover o lazy loading dessa imagem, declarar width/height, otimizar formato e usar fetchpriority="high" só nela A candidata a LCP é descoberta tarde; prioridade em muitas imagens anula o benefício.
Banner, aviso de cookies ou anúncio inserido sem espaço reservado Reservar altura (min-height ou aspect-ratio) e evitar inserção acima do conteúdo já visível Deslocamento inesperado conta no CLS e atrapalha o toque.
Scripts de terceiros bloqueiam a interação defer/async, carregar sob interação (quando o script não é necessário para responder à própria interação) ou remover; medir INP antes e depois Tarefas longas no thread principal atrasam a resposta ao toque.
Fontes web trocam de aparência durante o carregamento font-display adequado, pré-carregamento criterioso da fonte principal e fallback com métricas parecidas Reduz deslocamento de layout e tempo até o texto estável.
Nota do Lighthouse baixa, mas campo p75 dentro das metas Priorizar o campo; investigar só regressões reais por template A nota de laboratório é diagnóstico, não a experiência medida nos usuários.

Pré-requisitos

  • URLs agrupadas por template e dispositivo, com prioridade de negócio definida.
  • Baseline datado de dados de campo (CrUX/RUM, quando houver) e de laboratório (Lighthouse/DevTools).
  • Acesso aos componentes que carregam imagens, scripts, fontes e elementos que deslocam o layout.

Passo a passo detalhado

  1. Agrupe páginas por template e priorize as que concentram tráfego e problemas.
  2. Colete métricas de campo disponíveis (CrUX/Search Console ou RUM) e registre período e dispositivo.
  3. Rode PageSpeed Insights/Lighthouse em páginas representativas e identifique elementos LCP, interações lentas e mudanças de layout.
  4. Corrija primeiro causas sistêmicas: imagem hero, scripts bloqueantes, tarefas longas, fontes e espaços reservados.
  5. Evite lazy loading em imagem candidata a LCP; mantenha lazy loading apenas em mídia realmente fora da área inicial.
  6. Teste regressões visuais, acessibilidade e funcionalidades após mudanças.
  7. Compare laboratório imediatamente e campo após janela de coleta adequada, com baseline e contexto.

Exemplos práticos e códigos

Exemplo ilustrativo: adapte ao contexto do seu projeto.

<img src="/imagens/hero.webp" width="1200" height="630" fetchpriority="high" alt="Descrição da imagem principal">

Caso completo — sintoma, causa, correção e evidência: Cenário ilustrativo: um template de produto apresenta LCP ruim no celular. O elemento LCP é a imagem principal, carregada com loading="lazy" e descoberta tarde. Remova lazy loading dessa imagem, otimize formato/dimensões e teste fetchpriority="high" apenas se apropriado. Compare Lighthouse antes/depois e aguarde dados de campo suficientes para avaliar o efeito real.

Contraexemplo: Exemplo incorreto: colocar loading="lazy" na imagem principal acima da dobra e depois tentar compensar apenas com fetchpriority.

Como validar a implementação

  1. Compare dados de campo antes e depois da implementação.
  2. Analise LCP, INP e CLS separadamente em mobile e desktop.
  3. Verifique regressões com Lighthouse e Chrome DevTools.
  4. Documente URLs e templates alterados, datas e possíveis fatores externos.

Ferramentas recomendadas

  • PageSpeed Insights — reúne dados de campo quando disponíveis e laboratório; não corrige código.
  • Lighthouse/DevTools — reproduzem diagnósticos controlados; não substituem usuários reais.
  • CrUX e WebPageTest — ajudam a comparar campo e rede de teste, respectivamente.

Ferramentas do laboratório relacionadas

AutoSEO Hubprojeto em desenvolvimento

Erros comuns

  • Tratar nota do Lighthouse como equivalente aos dados reais.
  • Aplicar lazy loading à imagem principal acima da dobra.
  • Otimizar apenas uma URL e ignorar problemas de template.
  • Aplicar prioridade alta a muitas imagens, impedindo a priorização efetiva da candidata a LCP.
  • Ignorar scripts de terceiros e tarefas longas ao investigar INP.
  • Atribuir melhora de campo a um único deploy sem considerar população, período e outras mudanças.

Checklist de execução

Marque as etapas concluídas. O progresso fica salvo apenas neste navegador.

Referências oficiais

Histórico de atualizações

  • Revisão editorial das consultas rápidas e matrizes de decisão: o elemento LCP pode ser texto; scripts carregados sob interação só quando não respondem à própria interação.
  • Publicação após revisão técnica e editorial final (precisão, exemplos, referências oficiais e acessibilidade).

Conteúdos relacionados