Seu site é rápido no celular de quem usa?

Abra uma página de produto no celular, escolha uma opção e tente continuar. Se o botão demora a reagir, a imagem empurra o preço ou a tela fica presa enquanto carrega um script, você já encontrou um problema. A nota do último relatório não muda essa experiência.

Um teste no notebook da equipe serve para investigar. A decisão sobre o que melhorar precisa considerar quem usa o site, em qual aparelho e em quais páginas. Um checkout com pouco tráfego pode merecer mais atenção que a página inicial.

Use laboratório para investigar e visitas para priorizar

O Lighthouse executa um teste sob condições controladas. Dados de campo vêm de visitas reais, com variações de dispositivo, rede e comportamento. O guia do web.dev sobre diferenças entre laboratório e campo explica por que os resultados podem divergir.

Nossa sugestão é começar por uma pergunta ligada ao uso. Em qual etapa a pessoa precisa esperar ou repetir uma ação? Depois procure o dado que ajuda a investigar essa espera.

Separe celular e desktop. Separe também páginas com funções diferentes. Uma média do domínio pode esconder uma página de inscrição lenta entre centenas de páginas de conteúdo simples.

Se ainda não há amostra suficiente, registre essa limitação. Não transforme a ausência de dados em aprovação. Use testes controlados para localizar problemas enquanto reúne observações das visitas.

Entenda o que cada medida responde

Os limites de boa experiência dos Core Web Vitals são LCP até 2,5 segundos, INP até 200 milissegundos e CLS até 0,1, avaliados no percentil 75. Em cada métrica, pelo menos 75% das visitas medidas devem ficar dentro do limite.

LCP observa quando o maior bloco de texto ou imagem visível aparece. INP mede a resposta visual a interações. CLS quantifica deslocamentos inesperados do conteúdo. São perguntas diferentes. Uma página pode aparecer depressa e continuar ruim de usar.

Para organizar a investigação, associe o relato à medida:

Relato	Primeiro ponto a investigar
"A foto principal demora"	Qual elemento determina o LCP e quando seu carregamento começa
"Toquei e nada aconteceu"	O trabalho executado durante a interação
"O botão saiu do lugar"	Qual conteúdo entrou sem espaço reservado

Essa tabela orienta a busca. Não prova a causa.

Corrija o atraso que você encontrou

Se a imagem principal determina o LCP, confira se ela aparece no HTML inicial e evite carregá-la com loading="lazy". Entregue um arquivo adequado ao tamanho exibido. Essas são recomendações do guia de otimização de LCP.

Antes de trocar todos os formatos de imagem, olhe a sequência de carregamento. Uma imagem pequena descoberta tarde ainda chega tarde. Anote quando o navegador a solicita para saber se a mudança resolveu a espera que você observou.

Para uma interação lenta, identifique o que mantém a thread principal ocupada. A orientação de otimização de INP inclui reduzir e dividir tarefas longas. Dar retorno visual ao toque também importa, mas não elimina o tempo necessário para concluir uma consulta.

Em um filtro de produtos, por exemplo, meça separadamente a reação do botão e a chegada dos resultados. Melhorar a primeira não prova que a segunda melhorou. O registro precisa distinguir as duas.

Faça o orçamento nascer da página

Um catálogo e um editor de imagens precisam de quantidades diferentes de código. Prefira um orçamento ligado à página que está trabalhando. Registre o tamanho transferido e a duração das interações importantes antes de alterar a implementação.

Depois da correção, repita o mesmo cenário em condições comparáveis. Anote a mudança e acompanhe novas visitas. Se o tráfego mudou junto com o deploy, não atribua toda variação ao código.

Inclua no aceite a tarefa completa. A pessoa deve conseguir abrir o produto, escolher uma opção e enviar o formulário sem perder o que já preencheu. Um relatório ajuda a localizar a demora. É essa tarefa concluída que dá sentido à melhoria.