PageSpeed Insights: como interpretar a nota e o que corrigir

A nota do PageSpeed Insights é o número que menos importa no relatório. O que o Google usa como sinal de experiência de página são os dados de campo, medidos em visitantes reais, e não o círculo colorido de 0 a 100 que aparece no topo. Quem corre atrás de um 100 na nota costuma gastar semanas em ajustes que não mudam nada para o usuário nem para o ranking, enquanto ignora o bloco que de fato conta.

Este guia mostra como ler o relatório de cima para baixo: o que é cada bloco, de onde vem cada número, por que o mesmo endereço recebe notas diferentes em testes seguidos e quais diagnósticos merecem tempo de desenvolvimento. Não entramos no detalhe de cada métrica isolada, como LCP, CLS ou INP, nem no relatório de Core Web Vitals do Search Console. O foco aqui é a ferramenta e a leitura correta do que ela entrega.

Duas fontes de dados na mesma página

O relatório junta duas coisas diferentes, e boa parte da confusão vem de tratá-las como uma só. A primeira é o dado de campo, que aparece na parte de cima sob o título de experiências reais de usuários. Ele vem do Chrome User Experience Report, o CrUX, que reúne medições anônimas de usuários do Chrome que aceitaram compartilhar estatísticas de uso. Os números cobrem uma janela móvel de 28 dias e são apresentados no percentil 75, ou seja, o valor que três em cada quatro visitas atingiram ou superaram em velocidade.

A segunda é o dado de laboratório, que aparece mais abaixo sob o título de diagnóstico de problemas de desempenho. Ele vem do Lighthouse, que carrega a página uma única vez, em um ambiente simulado, e calcula a nota de desempenho a partir dessa única carga. Não existe usuário real nesse teste: existe um dispositivo e uma rede emulados, com as mesmas configurações para todo mundo que roda o teste.

A diferença prática é enorme. O dado de campo responde à pergunta de como o seu site se comporta para quem realmente o visita, com seus aparelhos, suas redes, seus cookies e seus scripts de terceiros carregados. O dado de laboratório responde a uma pergunta mais estreita: o que acontece em uma carga limpa e padronizada, com a vantagem de ser reproduzível e de funcionar até em uma página que ainda não foi publicada.

• Campo: dados reais, janela de 28 dias, percentil 75, só existe se a página ou o site tiver tráfego suficiente.
• Laboratório: uma carga simulada, reproduzível, serve para achar a causa e testar a correção antes de publicar.
• Para o ranking, vale o campo. Para depurar, vale o laboratório.

O que o Google realmente usa e o que é só diagnóstico

Os Core Web Vitals fazem parte dos sinais de experiência de página, e a avaliação é feita com dados de campo. Os três indicadores são o LCP, o INP e o CLS, cada um com um limite considerado bom: até 2,5 segundos para o LCP, até 200 milissegundos para o INP e até 0,1 para o CLS. A avaliação é aprovada quando os três ficam dentro do limite no percentil 75. Basta um indicador reprovado para que a avaliação inteira apareça como não aprovada.

A nota de 0 a 100 é uma criação do Lighthouse. Ela combina métricas de laboratório com pesos que o próprio Lighthouse ajusta de uma versão para outra, e por isso uma nota de hoje não é estritamente comparável à de um ano atrás. Ela é um resumo útil para acompanhar tendência, mas não é o número que entra na avaliação de experiência. Dois sites podem ter nota 55 no laboratório e avaliação aprovada no campo, ou nota 95 e avaliação reprovada, porque seus visitantes usam aparelhos e redes muito diferentes do perfil simulado.

Também é importante lembrar que velocidade é apenas um dos fatores de ranking e raramente o decisivo. Uma página lenta com o melhor conteúdo para a busca ainda pode ficar à frente de uma página rápida e rasa. O ganho de passar de reprovado para aprovado existe, mas não justifica sacrificar conteúdo nem reescrever o site inteiro por causa de alguns pontos de nota.

Por que a nota muda a cada teste

Rode o mesmo endereço três vezes seguidas e é normal receber três notas diferentes. Isso não é defeito da ferramenta, é consequência de medir uma carga única em uma internet que não é estável. As variações mais comuns vêm de quatro origens.

A primeira é o servidor. Uma resposta inicial que demora 300 ms em um teste e 900 ms em outro desloca todas as métricas seguintes. Páginas sem cache de página ou com banco de dados sob carga oscilam bastante. A segunda são os scripts de terceiros: anúncios, pixels, widgets de chat e testes A/B carregam conteúdo diferente a cada visita, e o tempo gasto executando JavaScript muda junto. A terceira é o caminho de rede entre os servidores do Google e o seu servidor, que varia conforme o horário e a região do teste. A quarta é o conteúdo dinâmico, como banners de cookies, carrosséis e recomendações, que mudam o elemento maior da página de um teste para o outro.

• Rode o teste de três a cinco vezes e compare a mediana, não o melhor nem o pior resultado.
• Mude uma coisa por vez e teste de novo; várias mudanças simultâneas escondem qual delas ajudou.
• Compare sempre no mesmo modo (celular ou computador) e, se possível, em horários parecidos.
• Variações de poucos pontos são ruído. Só uma diferença repetida em várias execuções indica mudança real.

Celular e computador: o que a simulação assume

O Lighthouse usa um perfil para celular e outro para computador. No celular, a simulação aplica um processador desacelerado e uma conexão equivalente a uma rede móvel lenta, então a nota costuma ser bem menor do que a do computador para a mesma página. Isso assusta quem olha os dois lados, mas é o comportamento esperado: a aba de celular foi desenhada para ser exigente.

Como o índice do Google é predominantemente móvel, o relatório de celular é o ponto de partida natural. Mesmo assim, a pergunta que decide onde investir é outra: qual parcela do seu tráfego vem de celular e de que tipo de aparelho? Um site cuja audiência é majoritariamente de celulares de entrada no Brasil, com redes instáveis, tende a sofrer mais no campo do que o laboratório sugere. Já um site B2B acessado em notebooks corporativos pode estar aprovado no campo mesmo com a nota de celular baixa.

Se os seus dados de campo mostram a maior parte dos problemas em apenas um dos perfis, concentre o trabalho nele. Corrigir o perfil em que ninguém acessa é uma forma cara de melhorar uma nota.

Página ou origem: como ler o bloco de campo

No topo do relatório há um seletor entre a URL testada e a origem inteira. A origem agrega todas as páginas do domínio que têm dados no CrUX. Quando a URL específica não tem tráfego suficiente para ter amostra própria, a ferramenta avisa e mostra apenas a origem, o que é comum em páginas novas, em páginas profundas e em sites pequenos.

Isso muda a interpretação. Ver a origem aprovada não garante que a página que você está analisando esteja aprovada, e ver a origem reprovada pode ser culpa de um tipo de página específico, como as páginas de produto pesadas, e não do site todo. O caminho prático é testar uma URL representativa de cada modelo de página (página inicial, categoria, produto, artigo) e tratar cada modelo como uma unidade de correção, já que a mesma alteração no template resolve centenas de endereços de uma vez.

Se não aparecer nenhum dado de campo, isso não significa que o site é ruim. Significa apenas que não há amostra suficiente. Nesse caso o laboratório é tudo o que você tem, e vale usá-lo com a consciência de que ele é uma estimativa.

Quais diagnósticos valem o tempo de quem trabalha com SEO

Abaixo da nota, o Lighthouse lista oportunidades e diagnósticos, e nem todos têm o mesmo peso. O critério útil é ligar cada item a um indicador de campo que está reprovado. Se o LCP está ruim, olhe os itens que atrasam o maior elemento visível. Se o INP está ruim, olhe o que ocupa a thread principal. Se o CLS está ruim, olhe o que se move sem aviso. O resto é otimização opcional.

Os itens que costumam render mais, em ordem aproximada de retorno, são os seguintes. Primeiro, o tempo de resposta do servidor: nenhuma otimização de front-end compensa uma resposta inicial lenta, e cache de página, compressão e uma hospedagem adequada resolvem muito. Segundo, a imagem principal: servir no tamanho certo, em formato moderno e sem carregamento preguiçoso na imagem que aparece primeiro na tela. Terceiro, recursos que bloqueiam a renderização, como CSS e scripts carregados no cabeçalho sem necessidade. Quarto, o volume de JavaScript executado, em especial de terceiros. Quinto, dimensões declaradas em imagens, anúncios e incorporações, para reservar espaço e evitar saltos de layout.

Há itens que pouco afetam o resultado e atraem atenção demais. Avisos de ganho de poucos milissegundos, sugestões de minificar arquivos que já vêm comprimidos e recomendações de remover CSS não usado em páginas simples raramente movem um indicador de campo. O relatório mostra uma economia estimada para cada oportunidade, mas essa estimativa é apenas uma projeção do laboratório, e somar as economias de vários itens dá um total otimista, porque os ganhos se sobrepõem.

• Prioridade alta: resposta lenta do servidor, imagem principal pesada ou atrasada, JavaScript de terceiros que bloqueia a thread principal, elementos sem dimensão que empurram o conteúdo.
• Prioridade média: CSS e fontes que bloqueiam a renderização, cadeias longas de requisições, cache mal configurado para arquivos estáticos.
• Prioridade baixa: micro ajustes de tamanho de arquivo, pequenos avisos sem relação com um indicador reprovado.

Um exemplo de leitura: de relatório a plano de correção

Imagine uma loja virtual com a página de produto em nota 48 no celular. No campo, o LCP está em 3,4 segundos, o INP em 180 milissegundos e o CLS em 0,02. A avaliação é reprovada por causa de um único indicador, o LCP. A nota baixa no laboratório chama atenção para o tempo total de bloqueio e para dezenas de scripts, mas o INP de campo já está dentro do limite. Consertar o INP seria gastar esforço onde o campo não reclama.

Ao abrir o diagnóstico do LCP, o relatório aponta que o elemento é a foto do produto, servida em tamanho muito maior do que o exibido e com carregamento preguiçoso. A resposta do servidor também aparece com 800 ms. O plano sai quase sozinho: remover o carregamento preguiçoso da primeira imagem, gerar versões no tamanho certo, avaliar cache de página para reduzir a resposta inicial e só depois voltar a medir.

O resultado esperado não é uma nota 100. É o LCP de campo cair abaixo de 2,5 segundos ao longo das semanas seguintes, já que o CrUX leva cerca de 28 dias para refletir completamente a mudança. Essa espera é outra armadilha frequente: quem corrige hoje e confere amanhã acha que nada funcionou. O laboratório confirma o efeito na hora, e o campo confirma o efeito real com atraso.

Erros comuns ao usar a ferramenta

O erro mais frequente é perseguir a nota de laboratório como meta final, muitas vezes removendo funcionalidades que o negócio precisa, como rastreamento e chat, só para ganhar pontos. O segundo é comparar sites de concorrentes por nota: sem saber a configuração de cada um, é uma comparação sem sentido. Um terceiro é testar apenas a página inicial, quando o tráfego orgânico está concentrado em artigos e categorias com outro template.

Outro engano é esquecer que testes com a página atrás de login, de bloqueio de país ou de proteção contra robôs podem falhar ou medir uma página de desafio em vez do conteúdo real. Se o relatório mostra valores estranhos, confira se o que foi carregado é a página correta. Por fim, não ignore o contexto de cache: a primeira visita de um usuário novo carrega tudo do zero, e é essa carga que o laboratório simula.