PageSpeed Insights: como ler o relatório e por que a nota muda

Entenda cada parte do PageSpeed Insights, a diferença entre dados reais e teste de laboratório, por que a nota muda a cada teste e o que realmente merece a sua atenção.

Equipe Teste de Performance
4 min de leitura

Em resumo

  • O relatório tem duas partes: dados de visitantes reais (o que o Google usa) e um teste de laboratório (a nota de 0 a 100).
  • A nota muda a cada teste por causa da rede, do servidor e da simulação; variações pequenas são normais.
  • Priorize a faixa dos Core Web Vitals dos visitantes reais; a nota serve para encontrar problemas, não para ranquear.
Neste guia
  1. As duas partes do relatório
  2. Por que a nota do celular é tão mais baixa
  3. Por que a nota muda a cada teste
  4. O que fazer quando os dois não concordam
  5. Como usar a lista de sugestões
  6. O que o PageSpeed Insights não faz
  7. Resumo

O PageSpeed Insights é a ferramenta gratuita do Google para medir a velocidade de uma página. É também uma das mais mal interpretadas: muita gente olha só a nota, se assusta com um número vermelho no celular ou fica confusa quando o mesmo site tira 62 num teste e 71 no seguinte.

Vamos ver, parte por parte, o que o relatório mostra e o que fazer com cada informação.

As duas partes do relatório

Depois de colar o endereço e clicar em analisar, o relatório aparece em duas abas, Celular e Computador, e cada uma tem duas partes bem diferentes.

Parte 1: o que os seus visitantes reais vivenciam

No topo ficam os dados de campo: medições de pessoas reais que visitaram a página usando o Chrome, nos últimos 28 dias. Eles vêm do Chrome User Experience Report.

Você vê os três Core Web Vitals (LCP, INP e CLS), além de FCP e TTFB, cada um com uma faixa colorida. No alto, aparece o veredito: a página passou ou não passou na avaliação dos Core Web Vitals.

  • O valor mostrado é o do percentil 75: ou seja, 75% das visitas foram tão boas quanto esse número, ou melhores.
  • Se a página tem poucas visitas, o relatório pode mostrar os dados do site inteiro ou dizer que não há dados suficientes. Isso é comum em sites pequenos e não é um problema por si só.

Esta é a parte que o Google usa para avaliar a experiência na página.

Parte 2: o teste de laboratório

Abaixo vem a famosa nota de 0 a 100, gerada na hora pelo Lighthouse num ambiente simulado:

Nota Faixa
90 a 100 Boa
50 a 89 Precisa melhorar
0 a 49 Ruim

Junto com a nota vêm métricas de laboratório (FCP, LCP, TBT, CLS e Speed Index), uma sequência de imagens do carregamento e uma lista de sugestões do que corrigir, com uma estimativa de quanto cada uma pode ajudar.

Por que a nota do celular é tão mais baixa

No teste de celular, o Google simula um aparelho intermediário numa conexão móvel lenta, de propósito: é a realidade de boa parte das pessoas. Um site que voa no seu computador com wi-fi pode tirar 40 nessa simulação, e isso não é um erro. É um aviso de como ele chega para muita gente.

Como o Google avalia os sites pela versão de celular, essa é a aba que mais importa.

Por que a nota muda a cada teste

Você testa, dá 68. Testa de novo, dá 74. Nada mudou no site. Isso acontece porque o teste depende de:

  • Rede: a conexão entre o servidor do Google e o seu servidor naquele momento.
  • Seu servidor: se estava mais ou menos ocupado, se o cache estava pronto.
  • O próprio ambiente de teste: a máquina que roda a simulação também varia.
  • Local: o teste roda em centros de dados do Google na América do Norte, na Europa ou na Ásia, e a distância até a sua hospedagem influencia.
  • Conteúdo variável: anúncios, banners e scripts de terceiros que carregam diferente a cada visita.

Variação de alguns pontos é normal. Para comparar antes e depois de uma mudança, rode o teste três vezes e considere o resultado do meio.

O que fazer quando os dois não concordam

É comum o laboratório dar nota baixa e os dados reais estarem na faixa boa, ou o contrário.

  • Laboratório ruim, campo bom: seus visitantes provavelmente têm aparelhos e conexões melhores do que a simulação. Ótimo, mas use as sugestões para não piorar.
  • Laboratório bom, campo ruim: algo que o teste não pega está atrapalhando quem visita de verdade: scripts que carregam depois de uma interação, páginas internas mais pesadas ou públicos com conexão pior.

Na dúvida, os dados de campo vencem: são eles que refletem a experiência real e entram na avaliação do Google.

Como usar a lista de sugestões

A lista é útil, mas pode assustar. Algumas dicas:

  1. Comece pelas sugestões com maior economia estimada. Quase sempre são imagens, JavaScript sem uso e recursos que bloqueiam o carregamento.
  2. Não tente zerar a lista. Algumas sugestões dependem de serviços de terceiros que você não controla.
  3. Uma mudança de cada vez. Corrija, teste de novo e veja o efeito.
  4. Leve o relatório para quem cuida do site. As sugestões estão no vocabulário técnico que o desenvolvedor entende.

O que o PageSpeed Insights não faz

  • Não guarda histórico: cada teste é isolado, então é difícil saber se o site melhorou ou piorou ao longo dos meses.
  • Não avisa: se uma atualização de plugin deixar o site lento, você só descobre se testar de novo.
  • Não testa várias páginas de uma vez.
  • Explica pouco: os termos são técnicos e não há orientação de por onde começar.

Para cobrir essas lacunas, existem ferramentas de acompanhamento. O Teste de Performance usa o mesmo motor de medição do Google, explica o resultado em português, guarda o histórico das suas páginas e avisa quando algo piora. No nosso comparativo de ferramentas mostramos as opções lado a lado.

Resumo

  • Olhe primeiro os dados reais e a aba Celular.
  • Use a nota para encontrar problemas, não como meta absoluta.
  • Variação de poucos pontos é normal: compare tendências.
  • Ataque as sugestões de maior impacto primeiro.

Para entender em detalhe cada métrica e como melhorar, veja o nosso guia de Core Web Vitals.

Continue lendo