Página lenta no celular: laboratório ou usuários reais?

Você rodou um teste de velocidade, viu uma nota baixa no celular e ficou em dúvida: o site está mesmo lento para os clientes? Nem sempre. O PageSpeed Insights mostra dois tipos de dado, o de laboratório e o de usuários reais, e confundir os dois leva a correções desnecessárias ou a um falso alívio.

Este guia explica a diferença e mostra como decidir o que mexer primeiro em um site de pequeno negócio, sem prometer que uma nota alta traga mais clientes.

O que o teste de laboratório mede

O dado de laboratório vem do Lighthouse, que carrega a página uma vez em um ambiente controlado, simulando um aparelho intermediário e uma conexão específica. A documentação do PageSpeed Insights descreve esse dado como útil para depurar problemas, mas lembra que ele pode não refletir os gargalos do mundo real.

Por ser repetível, ele serve para comparar antes e depois de uma mudança. Se você reduziu uma imagem e o teste melhorou, houve ganho naquela simulação. Isso ainda não prova que o cliente percebeu a diferença.

O que os dados de usuários reais mostram

O dado de campo vem do Chrome User Experience Report (CrUX), um conjunto anonimizado de medições de pessoas que visitaram o site em aparelhos e redes variados, acumulado em uma janela de cerca de 28 dias. Ele traz métricas como o tempo até o maior elemento aparecer (LCP), a resposta aos toques (INP) e a estabilidade visual (CLS).

Esse dado reflete a experiência de quem realmente acessa, mas tem limites:

• Exige um número mínimo de visitas. Em sites pequenos ou páginas recentes, ele pode não aparecer.
• Quando falta dado da página, a ferramenta pode mostrar o dado do site inteiro (origem), que mistura páginas diferentes.
• Se nem a origem tem amostra suficiente, não há dado de usuários reais, e só resta o laboratório.

Por que os dois resultados divergem

As diferenças são esperadas. O laboratório usa um aparelho e uma rede definidos; seus clientes usam celulares diversos, com Wi-Fi bom ou sinal fraco. O campo agrega semanas de visitas; o laboratório é uma foto de um momento. Além disso, o laboratório não simula o que as pessoas fazem depois do carregamento, como rolar e tocar em botões.

Imagine uma floricultura cujo teste de laboratório dá nota baixa por causa de um carrossel pesado, mas cujos visitantes, quase todos em Wi-Fi de casa, têm boa experiência no campo. Nesse caso o aviso do laboratório ainda vale como pista, só que a urgência é menor do que a nota sugere.

Erros comuns ao interpretar a nota

O primeiro erro é perseguir a nota 100. Ela é um resumo do laboratório, e o ganho entre uma nota boa e uma perfeita raramente muda a experiência de quem visita um site de serviços. O segundo é tratar toda recomendação como obrigação: cada sugestão tem impacto diferente, e algumas não se aplicam ao seu caso.

O terceiro erro é comparar o seu resultado com o de um site grande, com equipe técnica e infraestrutura própria. Compare o site com ele mesmo ao longo do tempo. O quarto é testar só a página inicial: muitas vezes o cliente chega por uma página de serviço ou por um artigo, e é nela que a experiência importa.

Em resumo, nenhuma nota substitui o contexto: quem acessa, de qual aparelho, e quão rápido consegue chegar ao contato. Use o teste como pista, não como veredito.

Como ler o relatório na ordem certa

1. Veja primeiro se existe dado de campo para a página. Se existir, ele diz como está a experiência real.
2. Confira se o dado é da página ou da origem inteira.
3. Compare as métricas com os limites de "bom" publicados na referência de Core Web Vitals do web.dev: LCP de até 2,5 segundos, INP de até 200 milissegundos e CLS de até 0,1.
4. Use as oportunidades do laboratório para descobrir a causa: imagens grandes, scripts de terceiros, fontes pesadas.
5. Mude uma coisa por vez e repita o teste algumas vezes, porque o resultado oscila.

Para entender o que cada métrica significa, veja o guia sobre Core Web Vitals.

O que fazer primeiro em um site pequeno

Pense na rotina de quem procura o seu serviço: abre o celular, toca no resultado, espera a página carregar e procura telefone, endereço ou botão de contato. Qualquer atraso nesse caminho custa atenção, e é por ele que a revisão deve começar.

Comece pelo que costuma pesar: fotos sem compressão, vídeos que carregam sozinhos, widgets de chat e rastreadores acumulados. Conserte a página que mais recebe visitas ou a que leva ao contato, não o site todo. Se você não sabe quais páginas são essas, comece medindo o que o site traz. Em sites criados com Lovable, inclua a conferência de desempenho na revisão feita depois de publicar.

Anote o resultado antes e depois de cada ajuste, com a data e a página testada. Esse registro simples evita a dúvida de meses depois sobre o que realmente funcionou e ajuda a conversar com quem mantém o site.

Um site rápido, sozinho, não garante posição nem clientes. Velocidade reduz atrito, mas o conteúdo e a clareza da oferta continuam decidindo. Veja também por que um site bonito não significa ser encontrado.

Fontes consultadas: Google PageSpeed Insights e web.dev. Confira os limites no dia em que for aplicar, pois podem mudar.