Para testar a velocidade de uma página no celular, coloque a URL no PageSpeed Insights e leia primeiro os dados de usuários reais no topo e depois os resultados de laboratório do Lighthouse logo abaixo. Os dados reais mostram se quem acessa pelo celular tem uma experiência rápida; os de laboratório ajudam a descobrir por que não tem. Uma página passa nas Core Web Vitals no mobile quando, em pelo menos 75% das visitas, o conteúdo principal aparece em até 2,5 segundos, as interações respondem em até 200 milissegundos e a pontuação de mudança de layout fica em 0,1 ou menos.
Dados de campo e dados de laboratório são coisas diferentes
A maior parte da confusão com notas de velocidade vem de misturar os dois.
Dados de campo são coletados de usuários reais do Chrome que visitaram sua página nos últimos 28 dias, pelo Chrome User Experience Report. Refletem celulares, redes e comportamentos reais. Só existem para páginas e sites com tráfego suficiente.
Dados de laboratório vêm de um único teste simulado, geralmente o Lighthouse carregando a página em um celular intermediário emulado com rede limitada. O teste é repetível e detalhado, por isso é a ferramenta certa para depurar. A nota dele (de 0 a 100) não é usada pelo Google no ranqueamento e muda a cada execução.
Quando os dois discordam, confie nos dados de campo para saber se está bom e nos de laboratório para saber o que corrigir.
Limites das Core Web Vitals no mobile
| Métrica | O que mede | Bom | Precisa melhorar | Ruim |
|---|---|---|---|---|
| Largest Contentful Paint (LCP) | Quando o conteúdo principal aparece | ≤ 2,5 s | 2,5–4 s | > 4 s |
| Interaction to Next Paint (INP) | A rapidez com que a página responde a toques e cliques | ≤ 200 ms | 200–500 ms | > 500 ms |
| Cumulative Layout Shift (CLS) | Quanto o layout pula durante o carregamento | ≤ 0,1 | 0,1–0,25 | > 0,25 |
Cada métrica é avaliada no percentil 75 das visitas, separadamente para mobile e desktop. Os números de mobile quase sempre são piores, porque celulares têm processadores mais lentos e redes menos estáveis. Os limites são definidos pelo Google no web.dev.
As melhores ferramentas gratuitas para medir a velocidade do site no celular
| Ferramenta | Tipo de dado | Use para |
|---|---|---|
| PageSpeed Insights | Campo (se houver) + laboratório | A primeira verificação de qualquer URL pública |
| Search Console, relatório Core Web Vitals | Campo | Encontrar grupos de páginas lentas no site inteiro |
| Lighthouse no Chrome DevTools | Laboratório | Testar páginas com login ou em localhost; diagnóstico detalhado |
| Painel Performance do DevTools | Laboratório, mais métricas ao vivo das suas interações | Achar o script ou elemento exato que causa o atraso |
| WebPageTest | Laboratório em dispositivos e locais reais | Filmstrips, waterfalls e testes a partir de outros países |
Como rodar o Lighthouse passo a passo está no guia de auditoria mobile com o Lighthouse.
Como fazer um teste de velocidade mobile que sirva
- Teste a página certa. Use as páginas de entrada mais visitadas, não só a home.
- Veja os dados de campo primeiro no PageSpeed Insights. Se aparecer “Sem dados”, olhe os dados da origem ou o Search Console.
- Rode o teste de laboratório três vezes e use a mediana. Uma execução só varia demais.
- Limite a máquina ao testar localmente. No DevTools, coloque a CPU 4x mais lenta e a rede em Fast 4G ou Slow 4G antes de gravar no Performance. Seu notebook é muito mais rápido que a maioria dos celulares.
- Observe a página enquanto carrega. Problemas de velocidade costumam ser visíveis: uma imagem principal que aparece tarde, um banner de cookies que empurra o conteúdo. Uma visualização mobile ajuda. O modo dispositivo do DevTools ou o Mobile View Extension mostram o carregamento no tamanho de celular com user agent mobile, o que importa se o servidor envia arquivos diferentes para celulares.
Correções que costumam melhorar os números
Para um LCP lento
- Entregue a imagem principal em formato moderno e no tamanho de celular, com
srcsetesizes. - Não use lazy loading na imagem principal; adicione
fetchpriority="high"a ela. - Reduza o tempo de resposta do servidor com cache ou CDN.
- Tire do
<head>o CSS e o JavaScript que bloqueiam a renderização, ou carregue-os depois.
Para um INP lento
- Divida tarefas longas de JavaScript; qualquer coisa acima de 50 ms bloqueia os toques.
- Adie ou remova scripts de terceiros (chats, gerenciadores de tags, testes A/B) que rodam em todas as páginas.
- Evite trabalho pesado em handlers de clique e de input: mostre um retorno primeiro e só depois faça o trabalho.
Para um CLS alto
- Defina
widtheheight(ouaspect-ratio) em imagens, vídeos e embeds. - Reserve espaço para anúncios e banners.
- Carregue fontes web com
font-display: swape escolha uma fonte reserva com métricas parecidas.
Quanto a velocidade no celular importa?
O Google usa as Core Web Vitals como parte dos sinais de experiência na página, mas relevância e qualidade do conteúdo pesam mais no ranqueamento. O motivo mais forte é o comportamento das pessoas: no celular, uma página lenta ou que pula perde visitantes antes que leiam qualquer coisa. Trate as Core Web Vitals como um piso de qualidade, não como uma nota a perseguir.
Para o restante da checagem antes do lançamento, veja o checklist de teste de site mobile e, para correções mobile mais amplas, como deixar um site responsivo.
Perguntas frequentes
Qual é uma boa nota de velocidade mobile?
A nota do Lighthouse é uma estimativa de laboratório. O que importa mais é passar nas Core Web Vitals nos dados de campo: LCP abaixo de 2,5 s, INP abaixo de 200 ms e CLS abaixo de 0,1 em pelo menos 75% das visitas.
Por que minha nota no mobile é muito menor que no desktop?
Os testes de laboratório para mobile simulam processador e rede mais lentos. JavaScript pesado e imagens grandes pesam muito mais nesse perfil.
Dá para testar a velocidade mobile em localhost?
Sim, com o Lighthouse ou o painel Performance do Chrome DevTools. O PageSpeed Insights só testa URLs públicas.