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.
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
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:
- Comece pelas sugestões com maior economia estimada. Quase sempre são imagens, JavaScript sem uso e recursos que bloqueiam o carregamento.
- Não tente zerar a lista. Algumas sugestões dependem de serviços de terceiros que você não controla.
- Uma mudança de cada vez. Corrija, teste de novo e veja o efeito.
- 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.