PageSpeed Insights e Lighthouse: como ler e usar o relatório

O que são o PageSpeed Insights e o Lighthouse

O PageSpeed Insights (PSI) é uma ferramenta gratuita do Google que mostra como uma página se comporta para usuários reais e em um teste simulado, enquanto o Lighthouse é o motor de auditoria de código aberto que gera a parte simulada desse relatório. Confundir os dois gera boa parte das discussões sobre “nota baixa”.

Na prática:

• PageSpeed Insights (pagespeed.web.dev): para uma URL pública, mostra os dados reais do Chrome e um teste do Lighthouse feito nos servidores do Google, em celular e desktop.
• Lighthouse: roda dentro do Chrome (aba Lighthouse do DevTools), pela linha de comando em Node ou via API. Além de Performance, audita Acessibilidade, Práticas recomendadas e SEO.

Em SEO, o PSI é a porta de entrada para as Core Web Vitals (LCP, INP e CLS) de uma URL específica. O Lighthouse é a bancada de testes para investigar o porquê e validar correções antes de publicar.

Dados de campo (CrUX) x dados de laboratório

É o conceito mais importante do guia. Os dois tipos de dado respondem a perguntas diferentes:

Alguns detalhes do CrUX fazem diferença na leitura:

• Nem toda página tem dado de campo. A URL precisa ser publicamente descobrível e ter tráfego suficiente (o Google não divulga o mínimo). Uma página com noindex ou que não responde com status 200 fica de fora do dado por página.
• Sem dado da URL, o PSI mostra a origem. Quando a página não tem amostra própria, o relatório recorre ao agregado do site inteiro. Um problema localizado pode sumir na média.
• Nem todo usuário entra na conta. Contam visitas no Chrome para desktop e Android de quem tem o compartilhamento de estatísticas ativado. Chrome no iPhone e outros navegadores não contribuem.

Como rodar um teste no PageSpeed Insights

1. Acesse pagespeed.web.dev
   Cole a URL completa da página (com https) e clique em Analisar. Teste também modelos de post, categoria e produto, não só a home.
2. Escolha a aba Celular ou Computador
   O relatório abre no celular. Comece por ele, já que o Google usa a versão móvel para indexação e a maior parte do tráfego costuma ser mobile.
3. Leia primeiro o bloco de campo
   Veja se a avaliação das Core Web Vitals foi aprovada e alterne entre “Este URL” e “Origem” para comparar a página com o site.
4. Só depois olhe o diagnóstico de laboratório
   Use a nota e os insights para encontrar causas. Rode o teste duas ou três vezes antes de tirar conclusões, porque o resultado varia.
5. Registre o antes e o depois
   Salve o relatório antes de cada mudança. Para muitas URLs, use a API do PSI.

Como ler o relatório, bloco a bloco

1. Descubra a experiência dos seus usuários reais

É o bloco de campo. No topo aparece a avaliação das Core Web Vitals (aprovada ou reprovada) e, abaixo, cada métrica com uma barra verde, laranja e vermelha mostrando a distribuição das visitas. O valor exibido é o percentil 75: significa que 75% das visitas tiveram resultado igual ou melhor. A regra oficial é simples: a página passa quando LCP, INP e CLS estão em “bom”. Se não houver dado suficiente de INP, a avaliação considera só LCP e CLS. Sem dado de LCP ou CLS, não há avaliação.

2. Diagnosticar problemas de desempenho

É o bloco de laboratório. Mostra a nota de Performance, uma captura de tela do carregamento e as cinco métricas do Lighthouse. Logo abaixo ficam as notas das outras categorias (Acessibilidade, Práticas recomendadas e SEO).

3. Insights e Diagnósticos

São as recomendações. Cada item pode ser expandido e mostra os arquivos, elementos ou requisições envolvidos e, em vários casos, uma estimativa de economia. Use o filtro por métrica: se o problema do campo é LCP, filtre por LCP e deixe o resto para depois.

Nota de performance x Core Web Vitals

A nota de 0 a 100 é uma média ponderada de cinco métricas de laboratório. Na versão atual da documentação, o peso é: Total Blocking Time 30%, LCP 25%, CLS 25%, First Contentful Paint 10% e Speed Index 10%. As faixas são 0 a 49 (vermelho), 50 a 89 (laranja) e 90 a 100 (verde).

• A nota não é a avaliação das Core Web Vitals. Uma página pode ter nota 55 no celular e passar com folga no campo, ou ter 95 e reprovar porque os usuários reais usam aparelhos lentos ou porque o INP é ruim (o laboratório nem mede INP; o TBT é só um indicador aproximado).
• Insights não entram no cálculo. Eles ajudam a melhorar as métricas, mas resolver um item da lista não soma pontos por si só.
• Chegar a 100 custa caro. Segundo a documentação do Lighthouse, ir de 99 para 100 exige mais ou menos a mesma melhora que ir de 90 para 94. Raramente compensa.

No ranqueamento, entram sinais de experiência baseados em dados reais, com peso menor que relevância e qualidade. Entenda o contexto no guia sobre o algoritmo do Google.

Principais insights e diagnósticos e como agir

Ao longo de 2025, com a conclusão no Lighthouse 13 (outubro), o Lighthouse substituiu as antigas seções “Oportunidades” e parte dos “Diagnósticos” pelos Insights, os mesmos usados no painel Performance do DevTools. Várias auditorias foram fundidas e algumas foram aposentadas (como a de imagens fora da tela). O PSI pode exibir os nomes traduzidos; abaixo estão os mais comuns e o que fazer com cada um:

Exemplo: o campo mostra LCP de 3,8 s no celular, e o insight de descoberta avisa que a imagem principal está com lazy loading, aplicado pelo tema a todas as imagens. A correção é uma linha de código, e o efeito no campo aparece ao longo das semanas seguintes.

O insight de latência do documento também revela redirecionamentos 301 desnecessários, como links internos que ainda apontam para a URL antiga.

E a categoria SEO do Lighthouse?

Ela verifica o básico técnico: se a página pode ser indexada, se há título e meta description, se os links têm texto descritivo e são rastreáveis, se as imagens têm alt e se a tag canonical é válida. Nota 100 em SEO significa apenas que não há erro grave desses itens, não que a página está otimizada. A análise completa de SEO on-page vai muito além dessa lista.

Lighthouse no Chrome DevTools

O PSI só testa URLs públicas, a partir de servidores do Google. Para páginas em homologação, áreas logadas ou para testar uma mudança antes de subir, use o Lighthouse dentro do Chrome:

1. Abra uma janela anônima
   Assim você reduz a interferência de extensões, que injetam código na página.
2. Abra o DevTools e a aba Lighthouse
   Com a página carregada, pressione F12 (ou clique com o botão direito e escolha Inspecionar) e procure a aba Lighthouse.
3. Escolha o modo
   Navegação recarrega e audita o carregamento (o mais comum). Período (Timespan) grava enquanto você interage com a página, útil para investigar lentidão em cliques. Snapshot audita o estado atual, por exemplo com um menu aberto.
4. Defina dispositivo, categorias e configurações
   Selecione Celular ou Computador e só as categorias que precisa. Nas configurações, mantenha “Limpar armazenamento” para simular uma primeira visita e escolha entre limitação simulada (mais rápida) ou limitação do DevTools (números que batem com o painel Performance).
5. Rode e aprofunde
   Clique em Analisar carregamento da página. Depois, pelo menu do relatório, salve o resultado ou abra o trace no painel Performance para ver exatamente o que a thread principal estava fazendo.

Limitações e erros comuns

• Variação entre testes. Anúncios, testes A/B, rede e carga do servidor mudam o resultado. Rode mais de uma vez e use a mediana; o campo, por cobrir 28 dias, é bem mais estável.
• Esperar resultado imediato no campo. O CrUX olha 28 dias. Uma correção de hoje só aparece por completo semanas depois.
• Ignorar a ausência de dados. Sites pequenos muitas vezes não têm campo por URL. Nesse caso, o laboratório é seu guia, e vale coletar dados reais com a biblioteca web-vitals.

PageSpeed Insights x outras ferramentas

Um fluxo eficiente: o Search Console mostra quais grupos de páginas estão ruins, o PSI confirma o problema em uma URL representativa e o DevTools ajuda a encontrar a causa e testar a correção. Assim você prioriza o que afeta a indexação e a experiência das páginas que realmente trazem tráfego.

Lighthouse e a busca com IA

A busca com IA não criou uma “nota de performance para IA”. O Google continua orientando que, para aparecer nos AI Overviews e no Modo IA, valem as mesmas boas práticas de SEO, incluindo boa experiência da página e conteúdo acessível em texto. Veja os detalhes no guia de SEO para AI Overviews.

A novidade está em outro lugar. A documentação do Lighthouse já descreve uma categoria Agentic Browsing, marcada como experimental e baseada em padrões ainda propostos. Ela avalia se agentes de IA conseguem usar a página: nomes e rótulos na árvore de acessibilidade, estabilidade visual (CLS), integração com WebMCP e a existência de um arquivo llms.txt na raiz. Não há nota ponderada, só verificações aprovadas ou reprovadas. Trate como sinal de tendência, não como requisito de ranqueamento. Para a estratégia completa de visibilidade em respostas geradas, veja o guia de GEO (Generative Engine Optimization).

Perguntas Frequentes

O PageSpeed Insights é gratuito?

Sim. A ferramenta em pagespeed.web.dev é gratuita e não exige login. O Lighthouse é de código aberto.

Qual nota preciso ter para ranquear bem?

Nenhuma. O Google não usa a nota do Lighthouse como critério. O que conta são as Core Web Vitals medidas com usuários reais, e mesmo elas pesam menos que relevância e qualidade do conteúdo.

Por que aparece “não há dados suficientes” no bloco de campo?

A página não teve visitas suficientes de usuários elegíveis do Chrome nos últimos 28 dias, ou não é publicamente indexável. O PSI tenta mostrar os dados da origem; se nem ela tiver amostra, só o laboratório fica disponível.