PageSpeed Insights: como ler o relatório começando pelo campo, não pela nota

Quase toda conversa sobre velocidade de site começa com um print: um círculo vermelho com o número 42 e a frase “o site está lento, precisa chegar a 90”. O print vem do PageSpeed Insights, e o pedido parece objetivo. O problema é que ele costuma mirar a parte do relatório que menos diz sobre o cliente real.

O relatório tem duas metades que respondem perguntas diferentes, e a própria documentação do Google as separa com cuidado. Este guia mostra a ordem certa de leitura, explica os três casos que mais geram pedido errado ao fornecedor e termina com o que vale escrever no contrato do site, no lugar de “nota 90”.

O que é o PageSpeed Insights?

O PageSpeed Insights (PSI) é uma ferramenta gratuita do Google que avalia a experiência de uma página no celular e no computador e sugere melhorias. Basta colar a URL em pagespeed.web.dev e esperar o teste terminar; os resultados de celular e de computador aparecem separados.

O ponto que quase ninguém explica é que ele junta dois tipos de dado no mesmo relatório. Segundo a documentação oficial do PageSpeed Insights, o PSI entrega dados de laboratório, úteis para depurar problemas porque são coletados em ambiente controlado, e dados de campo, que capturam a experiência real dos usuários, com um conjunto menor de métricas. Tratar as duas metades como se fossem uma só é a origem da maior parte das brigas sobre velocidade.

De onde vêm os dados de cada metade do relatório?

A metade de cima vem do Chrome UX Report (CrUX), uma base pública que agrega medições de usuários do Chrome que optaram por compartilhar esses dados. É o histórico de como a página se comportou de verdade, em aparelhos, redes e lugares diferentes.

A metade de baixo vem do Lighthouse, a ferramenta de auditoria do próprio Chrome. Ele carrega a página uma vez, num ambiente simulado, e devolve notas para desempenho, acessibilidade, boas práticas e SEO, além da lista de oportunidades e diagnósticos.

O percentil 75 tem um motivo declarado: o Google quer que a página funcione bem para a maioria dos usuários, inclusive em aparelhos e redes mais difíceis. Na prática, três em cada quatro visitas tiveram resultado igual ou melhor que o número exibido no topo; ele não é a média.

Qual a diferença entre dados de campo e de laboratório?

A diferença não é de precisão, é de pergunta. O campo responde “como o site está para quem usa?”. O laboratório responde “o que, neste carregamento simulado, está atrasando a página?”. Um não substitui o outro:

Elaborado pela Alliance Comunicação a partir da documentação do PageSpeed Insights e do artigo “Why lab and field data can be different”, do web.dev.

O artigo do web.dev sobre o tema, escrito por Philip Walton, é direto na regra geral: quando existem os dois, é o dado de campo que deve orientar a prioridade, porque ele representa o que os usuários estão vivendo. O laboratório continua útil para enxergar melhorias que o campo ainda não mostra, como a experiência de quem tem rede lenta e talvez nem consiga carregar o site.

A nota de 0 a 100 conta para o ranqueamento no Google?

A documentação de busca do Google fala em Core Web Vitals, e não na nota do Lighthouse. A Central da Pesquisa define as Core Web Vitals como métricas de experiência real do usuário e indica o relatório do Search Console para acompanhá-las, ou seja, a mesma natureza do bloco de cima do PSI.

A mesma página sobre experiência avisa que tentar uma nota perfeita só por motivo de SEO pode não ser o melhor uso do seu tempo, e lembra que o Google procura mostrar o conteúdo mais relevante mesmo quando a experiência da página é fraca. A leitura que fazemos disso: velocidade importa, mas como critério de desempate e de experiência, não como atalho de posição.

Quem quer entender o que o Google de fato registra sobre o site encontra o relatório de Core Web Vitals no Search Console, que explicamos no guia sobre o que os relatórios do Search Console não mostram.

Como usar o PageSpeed Insights na ordem certa?

A ordem de leitura muda a conclusão. Este é o roteiro que usamos antes de qualquer conversa com desenvolvedor:

1. Escolha o aparelho que traz o seu público

Se a maior parte das visitas vem do celular, comece por ali; se o público é corporativo e acessa do escritório, olhe também o resultado de computador. Os dois podem ser bem diferentes, e misturá-los gera discussão inútil.

2. Veja se o bloco de cima é da página ou da origem

Quando a URL não tem dados suficientes, o PSI recorre à origem, que reúne as visitas de todas as páginas do site. Confira qual dos dois o bloco de cima está mostrando: se for a origem, o veredito fala do domínio como um todo, não daquela landing page específica. Isso muda o peso que você dá ao resultado.

3. Leia o veredito das Core Web Vitals

Segundo a documentação, a página ou a origem passa na avaliação quando o percentil 75 das três métricas (LCP, INP e CLS) está em “bom”. Se faltar dado de INP, ela passa com LCP e CLS bons; se faltar dado de LCP ou de CLS, não há como avaliar. Esse veredito é o resumo mais honesto do relatório.

4. Olhe as barras de distribuição, não só o número

Cada métrica mostra quanto das visitas caiu em verde, âmbar e vermelho. Uma página com o percentil 75 no limite, mas com uma fatia vermelha grande, está mais perto de reprovar do que parece. É aqui que se vê se o problema atinge poucos ou muitos.

5. Só então desça para o laboratório e trate-o como lista de tarefas

Com o diagnóstico de campo em mãos, a nota e as oportunidades do Lighthouse ganham função: apontar causas prováveis da métrica que reprovou. Se o campo reprovou no LCP, as sugestões sobre imagem principal e servidor vêm primeiro; o resto espera.

Por que a nota do PageSpeed muda a cada teste?

Porque a nota vem de um único carregamento, e cada carregamento acontece em condições um pouco diferentes. A documentação do PSI diz que a variabilidade entra por vários canais, como disponibilidade da rede, do hardware e disputa de recursos, e informa que o teste roda num data center do Google que pode ficar na América do Norte, na Europa ou na Ásia.

A documentação de pontuação do Lighthouse acrescenta outras fontes de oscilação: testes A/B e anúncios diferentes a cada carregamento, mudanças de rota na internet, extensões de navegador e antivírus. E sugere pensar no desempenho como uma distribuição de notas, não como um número só.

Há ainda a composição da nota. Na tabela de pesos publicada para o Lighthouse 10, ela é uma média ponderada de cinco métricas de laboratório:

• Total Blocking Time (TBT): 30% — quanto tempo a página fica travada por código durante o carregamento.
• Largest Contentful Paint (LCP): 25% — quando o maior elemento visível aparece.
• Cumulative Layout Shift (CLS): 25% — quanto o conteúdo pula de lugar.
• First Contentful Paint (FCP): 10% — quando surge o primeiro conteúdo.
• Speed Index: 10% — a rapidez com que a área visível vai sendo preenchida.

Repare que o INP, uma das três Core Web Vitals, não entra na conta: ele depende de interação real e só existe no campo. Uma nota alta, portanto, não diz nada direto sobre a resposta do site ao toque. A mesma documentação lembra que uma nota 100 é extremamente difícil e não é esperada: sair de 99 para 100 exige mais ou menos o mesmo esforço de levar 90 a 94.

Quais são os três casos que geram pedido errado ao fornecedor?

Quase todo pedido mal formulado sobre velocidade nasce de um destes três cenários. Em todos, a correção é a mesma: decidir pelo campo e usar o laboratório para achar a causa.

Caso 1: nota vermelha, campo aprovado

Pode acontecer quando o público usa aparelhos e redes melhores que os da simulação, ou volta ao site com arquivos já guardados em cache. O usuário real já está numa faixa boa; a nota baixa reflete um cenário mais duro. Exigir “chegar a 90” aqui pode consumir semanas de desenvolvimento para uma melhora que o cliente não percebe. O pedido certo é manter o campo aprovado e tratar as oportunidades do laboratório como manutenção.

Caso 2: nota verde, campo reprovado

É o caso mais perigoso, porque dá falsa tranquilidade. O web.dev lista por que isso acontece: o laboratório só mede o CLS de carregamento na parte visível, enquanto o campo conta deslocamentos durante toda a visita, inclusive ao rolar; imagens e iframes sem dimensões carregados mais abaixo escapam do teste. No INP, uma página sem a meta tag de viewport para celular pode ganhar atraso no toque que não aparece no TBT. O pedido certo é atacar a métrica reprovada no campo, mesmo com a nota verde.

Caso 3: “sem dados suficientes”

Aparece em URLs novas, páginas pouco visitadas ou endereços que não são públicos. A documentação explica que o CrUX exige que a URL seja pública, rastreável e indexável, e que tenha amostras suficientes para uma visão representativa. Sem isso, o PSI mostra a origem ou nada. Aqui, o erro é pegar a nota de laboratório e transformá-la em veredito. O pedido certo é medir no próprio site, com coleta de dados de usuários reais, ou acompanhar a origem até a página ganhar tráfego.

Como melhorar o LCP, o INP e o CLS?

A melhoria começa pela métrica que reprovou no campo. As causas abaixo são as que mais vemos em projetos; o laboratório ajuda a confirmar qual delas é a sua:

• LCP alto: imagem principal pesada ou carregada tarde, servidor lento para responder e fontes ou scripts que bloqueiam a renderização. O elemento de LCP que o Lighthouse aponta pode não ser o mesmo que o usuário vê, já que tamanho de tela e conteúdo personalizado mudam o maior elemento.
• INP alto: excesso de JavaScript rodando no momento do toque, scripts de terceiros (chat, pixels, mapas) e ausência de viewport para celular. O TBT do laboratório serve de pista, mas não fecha o diagnóstico.
• CLS alto: imagens, iframes e anúncios sem espaço reservado, banners que empurram o conteúdo e fontes que trocam de tamanho ao carregar. Declarar largura e altura dos elementos é a correção mais barata.

Hospedagem conta mais do que parece, sobretudo no tempo de resposta do servidor. Antes de culpar o código, vale conferir o que o plano entrega; o artigo sobre o que o plano de hospedagem não diz mostra onde procurar.

E o Speed Index?

O Speed Index é uma métrica só de laboratório, que mede a rapidez com que a área visível é preenchida, e pesa 10% da nota no Lighthouse 10. Ele melhora junto com o LCP e o FCP, quando o conteúdo de cima carrega primeiro. Perseguir o Speed Index isoladamente raramente compensa: ele não faz parte das Core Web Vitals.

E no WordPress?

No WordPress, a nossa experiência é que o peso costuma vir de tema carregado de recursos que a página não usa, de plugins que somam scripts em todas as páginas e de imagens enviadas sem tratamento. A ordem que recomendamos é a mesma: identificar a métrica reprovada no campo, desligar o que não é necessário e só então instalar plugin de cache ou de otimização, conferindo o efeito no campo nas semanas seguintes.

Quais são os erros mais comuns ao usar o PageSpeed Insights?

• Usar a nota como veredito. A própria documentação diz que bons dados de laboratório não significam, necessariamente, boa experiência para o usuário real.
• Comparar prints de dias diferentes. A nota oscila entre rodadas; comparar um teste de ontem com um de hoje mede o acaso junto com a mudança.
• Ignorar o aparelho que importa. Corrigir o computador quando o público é de celular, ou o contrário.
• Ler origem como se fosse a página. Quando o bloco de cima é do domínio inteiro, ele não prova nada sobre uma landing page específica.
• Esperar efeito no dia seguinte. O campo acumula 28 dias; uma correção publicada hoje leva semanas para aparecer por inteiro.
• Testar só a home. As páginas que vendem, como produto, serviço e formulário, podem estar bem piores que a página inicial.

Como medir a velocidade do site de forma contínua?

Um teste avulso no PSI é uma fotografia. Para acompanhar, a medição precisa virar rotina:

1. Liste de 5 a 10 URLs que representam o site: home, páginas de serviço ou produto, formulário e um artigo do blog.
2. Uma vez por mês, registre o veredito de campo de cada uma (passa, não passa, sem dados) e o percentil 75 de LCP, INP e CLS.
3. Acompanhe o relatório de Core Web Vitals do Search Console, que é a ferramenta indicada pela Central da Pesquisa para esse fim.
4. Quando a página não tiver dados de campo, colete dados dos próprios visitantes no site; o web.dev recomenda essa coleta própria por trazer informações mais acionáveis do que o CrUX sozinho.
5. Use o laboratório só para investigar a métrica que piorou e para testar a correção antes de publicar.

Quem já mede o site com web analytics bem configurado pode cruzar essa planilha com a conversão: é o jeito mais claro de saber se a velocidade está, de fato, custando lead ou venda.

A nota diz como foi um teste. O campo diz como foi o mês de quem visitou o site.

O que muda por tipo de site?

O método é o mesmo, mas o ponto de atenção muda conforme o que o site precisa entregar:

Elaborado pela Alliance Comunicação com base na prática de projetos web.

Se o site ainda vai nascer ou ser refeito, vale tratar performance como requisito de escopo desde o começo, como discutimos no artigo sobre criação de site, velocidade e conversão.

O que pedir no contrato do site?

“Nota 90 no PageSpeed” é uma meta ruim para contrato: oscila entre rodadas, ignora o INP e pode estar verde com o usuário real reprovado. Uma cláusula mais útil se apoia no campo:

1. Meta pelas Core Web Vitals no campo: percentil 75 de LCP até 2,5 s, INP abaixo de 200 ms e CLS abaixo de 0,1, nas páginas listadas e no resultado de celular.
2. Prazo de verificação compatível com a janela de 28 dias do CrUX, contado a partir da publicação.
3. Plano para páginas sem dados de campo: coleta própria ou acompanhamento da origem, definido antes da entrega.
4. Relatório de laboratório como anexo técnico, para registrar causas e correções, sem valor de aceite.
5. Responsabilidade clara sobre scripts de terceiros que o cliente pede para instalar depois da entrega.

Velocidade é só uma das frentes que decidem se o site converte. Para ver onde ela entra no conjunto do seu marketing, o diagnóstico de marketing gratuito devolve as prioridades em ordem. E, se a conclusão for refazer ou ajustar o site, a equipe de desenvolvimento web da Alliance trabalha com meta de campo, não de nota.