1. Blog
  2. Design e websites

Core Web Vitals: como investigar a experiência de carregamento

Entenda LCP, INP e CLS e investigue problemas de carregamento com dados de campo, testes de laboratório e prioridades ligadas à experiência real do site.

Página organizada em blocos estáveis, ao lado de cronômetro e instrumentos de medição.
Página organizada em blocos estáveis, ao lado de cronômetro e instrumentos de medição. Composição ilustrativa para este guia.

Em poucas palavras

Um relatório de desempenho pode apresentar números, cores e recomendações suficientes para ocupar semanas de trabalho. Ainda assim, a equipe pode não saber qual problema o visitante enfrenta nem qual mudança merece prioridade. Otimizar uma pontuação sem entender a página e a tarefa afetadas dificulta avaliar se o esforço melhorou a experiência.

Core Web Vitals são métricas que descrevem dimensões específicas do uso de páginas. Elas ajudam a localizar problemas, mas precisam de contexto e investigação. O roteiro abaixo explica os sinais atuais, diferencia campo e laboratório e propõe uma sequência para priorizar correções. Os limites documentados são referências técnicas, não previsões de vendas ou posição na busca. Uma página rápida também precisa ser compreensível, acessível e coerente com a necessidade do visitante.

  • Identifique a dimensão e o escopo do sinal apresentado no relatório
  • Separe medições de campo e testes de laboratório na análise
  • Escolha uma tarefa prioritária e descreva o problema percebido

Entenda qual dimensão cada métrica descreve

Na documentação consultada do web.dev, LCP descreve carregamento do maior conteúdo visível, INP mede resposta a interações e CLS acompanha instabilidade visual. As referências para boa experiência são LCP até 2,5 segundos, INP até 200 milissegundos e CLS até 0,1. A avaliação de campo considera o percentil 75, separando dispositivos móveis e computadores.

Essas definições ajudam a formular perguntas diferentes. A informação principal demora a aparecer? Um controle responde tarde? Elementos mudam de posição durante a leitura? Não trate os três sinais como uma única medida genérica de velocidade. Cada um orienta uma investigação, e a solução depende dos recursos, do comportamento e da estrutura da página em que o problema ocorre.

Separe dados de campo de testes controlados

Dados de campo refletem condições de uso observadas, com diversidade de dispositivos, redes e sessões. Testes de laboratório executam uma situação controlada para investigar comportamento. A MDN apresenta ferramentas de medição e inspeção de desempenho. Na operação proposta aqui, os dois tipos de evidência se complementam: um ajuda a entender alcance e outro facilita reproduzir causas possíveis.

Verifique o escopo do relatório. A informação descreve uma URL, um grupo de páginas ou a origem inteira? Há dados suficientes para a página desejada? A ausência de dados de campo não demonstra boa experiência. Registre a limitação e use os testes disponíveis para investigar, sem apresentar uma medição isolada de laboratório como retrato completo do público que acessa o site.

Localize a tarefa e o elemento afetados

Escolha uma página prioritária e descreva o que a pessoa tenta fazer. Em um artigo, pode ser começar a leitura; em uma ferramenta, inserir dados e obter um resultado; em uma página comercial, entender a oferta e solicitar contato. O mesmo atraso pode ter consequências diferentes conforme a tarefa e o momento em que aparece.

Use as ferramentas técnicas para localizar recursos e atividades envolvidos. Uma imagem grande, uma sequência de scripts ou um espaço não reservado para conteúdo podem ser hipóteses, mas não devem ser tratados como causa antes da inspeção. Registre a evidência que liga o elemento ao comportamento. Isso evita aplicar recomendações genéricas a páginas em que o gargalo está em outro ponto.

Priorize correções por alcance e impacto

Combine relevância da tarefa, frequência do problema e quantidade de páginas afetadas. Um componente compartilhado pode justificar atenção antes de uma exceção pouco usada. Também considere risco e esforço da mudança. Não escolha apenas o item mais fácil do relatório nem assuma que qualquer redução de bytes produz a mesma melhoria percebida por quem usa o site.

Mantenha um registro enxuto com hipótese, evidência, responsável e verificação esperada. Se a mudança reduz trabalho de um script, defina qual interação será testada. Se reserva espaço para imagem, observe o deslocamento durante o carregamento. O critério de aceite deve estar ligado ao problema investigado, evitando declarar sucesso apenas porque um alerta desapareceu na ferramenta.

Verifique correções sem perder a funcionalidade

Repita o teste em condições comparáveis e confirme que a tarefa continua funcionando. Remover um recurso pode melhorar um número e quebrar uma função importante. Depois da publicação, acompanhe os dados de campo quando disponíveis, respeitando a janela e o escopo do relatório utilizado. A mudança não aparece necessariamente de forma imediata em todas as visualizações agregadas.

Registre regressões após alterações de tema, campanhas e novos componentes. A experiência pode piorar quando entram imagens, scripts e incorporações sem critérios. Uma rotina de revisão proporcional ajuda a manter o resultado. Não é necessário transformar cada publicação em uma auditoria completa, mas mudanças que afetam componentes centrais devem acionar a verificação dos percursos e sinais relevantes.

Exemplo hipotético

Exemplo hipotético: uma página que muda enquanto o visitante lê

Uma empresa fictícia observa instabilidade visual em páginas de artigo. Durante o carregamento, um bloco de imagem aparece acima do texto sem espaço previamente reservado. A equipe confirma o deslocamento em um teste controlado e verifica que o mesmo componente é usado em todo o blog. A prioridade é corrigir o modelo para reservar o espaço adequado, preservando a adaptação a telas diferentes.

Depois da alteração, a equipe repete o percurso e confere se imagens e legendas continuam legíveis. A comparação técnica usa condições semelhantes e o acompanhamento de campo é registrado como etapa posterior. O caso não pressupõe impacto em vendas. A melhoria investigada é específica: reduzir um deslocamento que interrompia a leitura nas páginas e condições observadas.

Do sinal à pergunta de investigação

Deslize o infográfico para ver todos os detalhes ou abra a versão em texto abaixo.

Ler o infográfico em texto
  • LCP: O conteúdo principal demora a aparecer?
  • INP: A interação recebe uma resposta visual tardia?
  • CLS: A interface muda de posição de forma inesperada?
  • Contexto: Qual tarefa, página e condição estão afetadas?
Baixar o infográfico em SVG

Checklist de aplicação

  • Identifique a dimensão e o escopo do sinal apresentado no relatório.
  • Separe medições de campo e testes de laboratório na análise.
  • Escolha uma tarefa prioritária e descreva o problema percebido.
  • Inspecione o elemento antes de atribuir a ele a causa da falha.
  • Priorize componentes pelo impacto e pelo alcance entre páginas.
  • Repita o teste e confira a funcionalidade após a correção.

Dúvidas frequentes

Uma pontuação alta significa que o site está pronto?

Não. Desempenho é uma dimensão da experiência. A página ainda pode ter mensagem confusa, barreiras de acessibilidade ou funções quebradas. Use os indicadores para investigar os aspectos que eles medem e mantenha verificações próprias para conteúdo, navegação e conclusão das tarefas importantes do site.

Por que duas execuções de teste dão resultados diferentes?

Condições de rede, processamento, cache e recursos carregados podem variar. Antes de comparar, registre o ambiente e procure consistência na observação do problema. Uma execução isolada pode revelar uma pista, mas não deve ser usada para atribuir uma mudança pequena a uma causa definitiva sem investigação adicional.

O que fazer quando não há dados de campo?

Declare essa ausência e use testes controlados para investigar percursos prioritários. Se a infraestrutura permitir, avalie uma medição de uso real adequada ao projeto. Não preencha a lacuna com suposições sobre toda a audiência. A conclusão precisa permanecer limitada às páginas, condições e interações efetivamente verificadas.

Fontes e aprofundamento

As referências apoiam conceitos e detalhes técnicos. O roteiro de aplicação e os exemplos são uma síntese editorial; consulte o contexto e os limites de cada fonte.

  • web.dev, Web VitalsSustenta a distinção entre carregamento, interatividade e estabilidade visual nas Core Web Vitals.
  • MDN, Measuring performanceSustenta o uso de medições e ferramentas para investigar desempenho; a priorização proposta é autoral.

Experimente aqui, com seus dados.

Use a ferramenta sem sair da leitura. Suas respostas são processadas no navegador e não preenchem o formulário de contato.

Abrir Autoavaliação de site e landing page
Usar a ferramenta em uma página completa
Como este conteúdo é preparado

Continue a leitura

Explore a Exponency

O que você quer resolver?

Escolha um caminho ou procure um assunto.