Como testar a performance de uma landing page em celulares reais

O modo responsivo do navegador encontra layouts quebrados. Ele não transforma o notebook em um celular. A CPU, a GPU, a memória, o sistema térmico e o navegador do aparelho continuam diferentes.

Uma landing page pode passar no Lighthouse do computador e travar quando o visitante abre o menu em um aparelho intermediário. O teste no dispositivo real serve para capturar essa diferença e ligar o sintoma a um trace.

Você não precisa manter um laboratório com dezenas de modelos. Uma matriz curta, escolhida a partir do público e repetida na mesma Version, encontra problemas que a emulação não reproduz.

Separe três tipos de evidência

Emulação, aparelho real e dados de campo respondem perguntas diferentes.

A documentação do Chrome diz que o Device Mode é uma aproximação e não reproduz a arquitetura da CPU móvel. Quando houver dúvida, a recomendação é executar a página no aparelho e usar depuração remota.

Use os três níveis em sequência. O computador ajuda a reproduzir rápido. O aparelho revela limites do hardware. O acompanhamento de Core Web Vitals reais mostra se a correção alcançou o público.

Escolha uma matriz pequena

Comece com dois ou três aparelhos que representem diferenças relevantes:

• um Android de entrada ou mais antigo ainda presente no público;
• um Android intermediário atual;
• um iPhone compatível com a versão mínima atendida pelo site.

Se você já tem analytics, use a distribuição de sistema, navegador, largura de tela e capacidade do aparelho sem coletar identificadores pessoais. Se não tem, use os dispositivos disponíveis e declare a limitação.

Registre para cada teste:

modelo do aparelho:
sistema e versão:
navegador e versão:
conexão usada:
estado da bateria:
temperatura percebida:
URL e Version:
data e hora:

Não compare um aparelho frio e carregado com outro superaquecido depois de vinte execuções. Estado térmico e tarefas em segundo plano podem mudar o resultado.

Defina tarefas que importam

Escolha ações ligadas ao objetivo da landing page:

1. abrir a URL sem cache;
2. esperar o conteúdo principal aparecer;
3. abrir e fechar o menu;
4. rolar até a seção mais longa;
5. expandir uma pergunta;
6. alternar planos ou opções;
7. preencher e enviar o formulário em ambiente seguro;
8. repetir a interação depois da primeira execução.

A primeira ação pode pagar inicialização e importação de código. A repetição mostra o custo depois que o navegador aqueceu caches e estruturas internas.

Se o site tem vídeo, carrossel, mapa ou chat, inclua somente o que participa da jornada principal. O artigo sobre scripts de terceiros ajuda a separar custo próprio de integrações externas.

Calibre a emulação antes do aparelho

No Chrome DevTools do computador, calibre os presets de CPU em Settings, Throttling. A calibração ajusta os multiplicadores para aproximar aparelhos móveis de entrada e intermediários a partir da máquina usada no teste.

Depois grave o cenário no painel Performance com:

• viewport declarado;
• CPU calibrada;
• perfil de rede declarado;
• cache desativado para a carga fria;
• mesmas ações e mesma rota;
• pelo menos três repetições.

A documentação de CPU throttling do Chrome explica a calibração. Mesmo calibrado, o resultado continua sendo simulação. Use-o como linha de base reproduzível, não como prova de um modelo específico.

Inspecione um Android real

O Chrome permite abrir DevTools no computador enquanto a página roda no Android.

O fluxo oficial de depuração remota do Android é:

1. ative as opções do desenvolvedor no aparelho;
2. habilite a depuração USB;
3. conecte o aparelho diretamente ao computador;
4. abra chrome://inspect/#devices no Chrome do computador;
5. aceite a autorização no telefone;
6. abra a URL no Chrome do aparelho;
7. escolha a aba remota e clique em Inspect;
8. grave o carregamento e as interações no painel Performance.

O código executa no telefone. A janela no computador mostra o trace, a rede e a árvore inspecionada.

Use um cabo que transfira dados, mantenha as telas desbloqueadas durante a conexão e confira a versão do Chrome mostrada em chrome://inspect. Se o dispositivo não aparecer, remova hubs USB antes de alterar configurações do projeto.

Acesse uma versão local quando necessário

Se a correção ainda não pode ir para a URL pública, o Chrome oferece encaminhamento de porta pelo cabo USB. Ele mapeia uma porta do Android para o servidor local do computador.

A documentação de port forwarding para Android mostra como expor, por exemplo, localhost:8080 ao aparelho. Esse fluxo evita publicar uma mudança incompleta apenas para medi-la.

Compare depois com a URL final. CDN, cache, compressão, TLS e recursos externos podem se comportar de outro modo na publicação.

Inspecione um iPhone ou iPad

Em um Mac, o Safari consegue inspecionar páginas abertas em um dispositivo iOS ou iPadOS conectado.

O fluxo atual da documentação da Apple é:

1. no aparelho, abra Settings, Apps, Safari, Advanced;
2. ative Web Inspector;
3. conecte e confie no Mac;
4. no Safari do Mac, abra o menu Develop;
5. escolha o dispositivo e a página aberta;
6. use Network e Timelines para gravar o cenário.

O motor e o aparelho são os reais. Um simulador continua útil para cobertura de versões e tamanhos, mas não substitui o teste térmico, de memória e de toque no hardware.

Se você não tem Mac ou iPhone disponível, registre essa lacuna no PR. Não transforme um teste Android em afirmação sobre Safari móvel.

Teste rede sem inventar precisão

Uma conexão móvel varia por sinal, operadora, congestionamento e troca de antena. Um único teste em 4G não representa o público.

Use duas abordagens:

• rede controlada no DevTools para comparar versões;
• Wi-Fi ou rede móvel real para encontrar problemas de uso.

Anote qual delas foi usada. Não misture os resultados na mesma série.

Para uma carga fria, feche a aba, limpe os dados do site quando necessário e abra a URL novamente. Para uma carga quente, mantenha cache e conexão reutilizada. As duas experiências importam, mas respondem perguntas diferentes.

O guia de cadeias de requisições ajuda a explicar por que uma dependência distante fica mais cara quando a latência aumenta.

Relacione a pontuação ao sintoma

No aparelho, observe o que a pessoa percebe e relacione ao trace:

Para interação lenta, use as três fases do guia de redução de INP. Para páginas longas, teste a técnica de content-visibility no mesmo aparelho e confira se a rolagem continua estável.

Uma pontuação isolada não explica o bug. Guarde o trace, a ação, o aparelho e a Version que produziram o resultado.

Controle ruído suficiente para comparar

Antes de cada rodada:

• reinicie o navegador;
• feche apps pesados em segundo plano;
• desative economia de bateria;
• mantenha carga semelhante;
• espere o aparelho esfriar;
• use brilho e orientação definidos;
• confirme que a mesma Version está aberta;
• repita o cenário pelo menos três vezes.

Não precisa esterilizar o telefone até ele deixar de parecer real. O controle serve para distinguir uma mudança do site de uma mudança no estado do aparelho.

Guarde mediana e intervalo das repetições. Se uma execução ficou muito diferente, investigue em vez de apagá-la sem explicação.

Compare a mesma build

O teste perde valor quando cada aparelho abre uma versão diferente. Mostre um identificador de build em local acessível à equipe ou confirme a Version pelo processo de publicação.

Monte um registro curto:

Version: [identificador]
Cenário: carga fria + abrir menu + rolar até formulário

Aparelho A
LCP local:
interação mais lenta:
tarefa dominante:
frames lentos:

Aparelho B
LCP local:
interação mais lenta:
tarefa dominante:
frames lentos:

Decisão:

Não compare o número do Lighthouse do notebook com o trace do telefone como se viessem do mesmo instrumento. Compare tendências e use cada ferramenta para a pergunta que ela mede.

Corrija uma causa e repita

O aparelho de entrada costuma expor trabalho que o computador esconde:

• JavaScript analisado e executado na carga;
• layout amplo depois de uma interação;
• imagem grande decodificada perto da hero;
• efeito visual pintando uma área extensa;
• integração externa iniciada cedo;
• seção longa renderizada antes de entrar na tela.

Faça uma alteração pequena. Depois repita a mesma tarefa no mesmo aparelho. Se o problema era a primeira abertura do menu, não troque o cenário por uma carga de página e declare vitória.

Os guias de LCP da imagem hero e animações lentas ajudam a corrigir dois gargalos comuns encontrados no hardware real.

Publique e confirme no aparelho

Quando a correção passar na comparação local:

1. consulte o Site e a Version atuais;
2. altere os arquivos dentro de public/;
3. publique com deploy;
4. acompanhe deploy_status até um estado terminal;
5. abra a URL pública em cada aparelho da matriz;
6. confirme a nova Version;
7. execute o mesmo roteiro;
8. acompanhe os dados de campo depois da janela definida.

A documentação de Publicação explica o contrato de arquivos e Versions. O fluxo de republicação mantém a URL enquanto você substitui a versão servida.

Prompt para organizar o teste móvel

Monte um teste de performance móvel para esta landing page sem publicar ainda.

URL e Version: [URL e identificador]
Aparelhos disponíveis: [modelos, sistemas e navegadores]
Jornada principal: [ações]

1. Defina uma matriz curta com aparelho de entrada, intermediário e iPhone quando disponíveis.
2. Registre sistema, navegador, conexão, bateria e estado térmico.
3. Calibre a CPU do DevTools e grave uma linha de base controlada.
4. Use depuração remota no Android e Web Inspector no iOS.
5. Teste carga fria, carga quente e as interações da jornada.
6. Repita cada cenário três vezes na mesma Version.
7. Relacione cada sintoma a uma tarefa, recurso ou etapa de renderização.
8. Faça uma correção pequena e repita o mesmo teste.
9. Só proponha a publicação com os resultados e limitações registrados.

O aparelho real não substitui o laboratório nem os dados de campo. Ele fecha o espaço entre os dois. Quando a mesma ação, Version e condição ficam registradas, um telefone lento deixa de ser uma impressão e vira um caso que a equipe consegue corrigir e repetir.