Como testar seu site no celular
Teste páginas representativas e o percurso real de contato, reserva ou compra. Use PageSpeed e Lighthouse para desempenho, emulação para layout e um celular para interação. Separe pontuações de laboratório, dados de campo e tarefas concluídas. Registre URL, estado, aparelho e configurações, depois repita os mesmos testes após
Para verificar se seu site funciona no celular, combine um relatório de desempenho com um teste prático da tarefa do visitante. Uma página rápida pode ter um botão de envio inacessível. Um layout responsivo ainda pode perder os dados de
O Google aposentou o Teste de compatibilidade com dispositivos móveis e sua API em dezembro de 2023. PageSpeed Insights, Lighthouse, emulação do navegador e um celular real cobrem aspectos diferentes. Nenhum deles certifica sozinho que um site seja utilizável, acessível ou vá alcançar boas posições
Escolha páginas e ações importantes
Comece pela página inicial, uma página principal de produto ou serviço e um artigo. Inclua o percurso real de contato, reserva ou compra, mesmo que ele passe por outro domínio. Teste os idiomas relevantes e diferentes estados: primeira visita com aviso de consentimento, visita seguinte, menu aberto e formulário
Nosso verificador móvel gratuito pode servir como primeira checagem. Ele examina o HTML obtido e as informações da resposta em busca de indícios como uma tag viewport ausente, larguras fixas e texto muito pequeno definidos por estilos em linha. Não renderiza a página nem executa JavaScript nem calcula o layout a partir de folhas de estilo externas. O tamanho do HTML não é o total baixado, e o tempo de obtenção não é o tempo de carregamento em um celular. Confirme os alertas
| Verificação | Serve para | Não comprova |
|---|---|---|
| PageSpeed Insights | Desempenho de usuários reais, quando disponível, mais teste Lighthouse | Que todos os menus, formulários e pagamentos funcionem |
| Lighthouse no Chrome | Diagnóstico reproduzível, inclusive de páginas acessíveis localmente | Desempenho de toda a população de visitantes |
| Modo de dispositivo do DevTools | Layout, quebra de texto e sobreposições em larguras escolhidas | Comportamento exato de um celular físico |
| Search Console | Problemas de Core Web Vitals por grupos de URLs | Inventário completo de defeitos de uso ou acessibilidade |
| Celular real | Toque, teclado, navegador e conclusão de uma tarefa | Cobertura de todos os aparelhos e visitantes |
Separe os dois resultados do PageSpeed
Abra o PageSpeed Insights, informe a URL pública e
Os dados de campo vêm do Chrome UX Report e cobrem os 28 dias anteriores. Confira se o título indica “Este URL” ou “Origem”. Quando os dados da URL são insuficientes, o PageSpeed pode usar os da origem, que reúne páginas com o mesmo protocolo, nome de host e porta. Uma avaliação aprovada no nível da origem não comprova que aquela página específica passou. Se faltam dados nos dois níveis, ausência de avaliação não
A seção de laboratório é um novo teste Lighthouse em condições simuladas. Ela ajuda a investigar um recurso lento ou um script bloqueante. Sua pontuação de desempenho é separada da avaliação de campo. Uma única navegação não mede o INP dos seus visitantes. O Google explica essas diferenças.
Este exemplo salvo mostra dados de campo da origem: LCP de 2,4 segundos, INP de 112 milissegundos e CLS de 0. Não contém pontuação de desempenho Lighthouse. Ilustra como ler o escopo do relatório; não é uma medição atual da nossa
O que significam os limites das Core Web Vitals
A classificação usa o percentil 75 das respectivas medições de campo, não
| Métrica | Bom | Precisa melhorar | Ruim |
|---|---|---|---|
| LCP: conteúdo principal aparece | ≤ 2,5 s | > 2,5 até 4 s | > 4 s |
| INP: resposta à interação | ≤ 200 ms | > 200 até 500 ms | > 500 ms |
| CLS: mudanças inesperadas de posição | ≤ 0,1 | > 0,1 até 0,25 | > 0,25 |
Para passar na avaliação completa, as três precisam ser boas. Com dados insuficientes de INP, o PageSpeed ainda pode aprovar se LCP e CLS forem bons. Dados insuficientes de LCP ou CLS impedem a avaliação. Essa regra documentada do PageSpeed não substitui testes
Compare o Search Console no mesmo escopo
No Search Console, abra Core Web Vitals e o relatório móvel. Examine o grupo afetado, sua pior métrica e as URLs de exemplo. O Google agrupa páginas com experiências parecidas; esses grupos não correspondem necessariamente aos seus modelos de página. Reproduza o problema antes de atribuí-lo a um
PageSpeed e Search Console podem divergir mesmo quando você compara apenas dados de campo. Confira URL, origem ou grupo, aparelho, período e tratamento das URLs. O Search Console distingue parâmetros de URL; os dados de campo do PageSpeed são agregados sem esses parâmetros. Portanto, nem toda diferença é “laboratório contra usuários reais”. A documentação do relatório explica
Depois de publicar uma correção, repita imediatamente os mesmos passos no navegador e as mesmas configurações de laboratório. Os resultados de campo mudam com a entrada de novas visitas na janela móvel. “Iniciar acompanhamento” abre uma validação de 28 dias; não força rastreamento nem reindexação. Os dados exibidos podem mudar antes dos 28 dias, enquanto a validação continua precisando do período de acompanhamento e de
Registre as configurações do Lighthouse
Abra a página no Chrome, abra o DevTools, escolha Lighthouse e selecione Celular antes de executar a auditoria. O Lighthouse local pode testar páginas autenticadas que uma requisição pública do PageSpeed não alcança. A documentação do Lighthouse apresenta
Guarde relatório, data, URL, versão do Lighthouse, perfil do aparelho, limitação de velocidade e versão da página. Mantenha essas condições constantes ao comparar uma mudança e repita resultados surpreendentes. Computador, navegador, estado do consentimento e configuração podem alterar a medição. Reduzir manualmente a velocidade da CPU no DevTools não garante reproduzir a simulação
Automatize um teste com a API PageSpeed
Este comando Bash solicita diagnósticos móveis de desempenho, acessibilidade e SEO. Troque a URL de exemplo por uma
curl --get \
'https://www.googleapis.com/pagespeedonline/v5/runPagespeed' \
--data-urlencode 'url=https://example.com/' \
--data-urlencode 'strategy=mobile' \
--data-urlencode 'category=performance' \
--data-urlencode 'category=accessibility' \
--data-urlencode 'category=seo'No Windows, use um terminal Bash para essa sintaxe em várias linhas. O guia inicial documenta o acesso e recomenda uma chave para consultas automatizadas frequentes. Verifique a cota do projeto antes de agendar lotes. Um erro HTTP, inclusive de cota, não representa reprovação da página
Dentro de lighthouseResult, leia categories e audits; uma pontuação de categoria 0.92 equivale a 92 de 100. Guarde fetchTime, lighthouseVersion, requestedUrl, finalUrl e configSettings, e trate runtimeError antes de aceitar o resultado. Consulte a referência da resposta. Para monitoramento contínuo de campo, o Google recomenda CrUX API ou CrUX History API porque planeja retirar os dados CrUX da
Teste a tarefa no navegador e no celular
Ative a barra de dispositivos do DevTools e comece em 360 × 800 e 390 × 844 pixels CSS. Varie a largura e depois teste na horizontal. O modo de dispositivo é uma aproximação. Termine em aparelhos físicos e navegadores relevantes para seus visitantes, incluindo Safari no iPhone
- Abra e feche navegação, controles de consentimento e caixas de diálogo. Cabeçalhos fixos e avisos não devem cobrir conteúdo nem botões.
- Leia títulos longos, tabelas e traduções. Teste zoom e layout estreito. O critério de refluxo das Diretrizes de Acessibilidade para Conteúdo Web (WCAG) usa 320 pixels CSS para conteúdo com rolagem vertical, equivalentes a uma janela de 1280 pixels com zoom de 400%. Tabelas realmente bidimensionais têm uma exceção: preserve conteúdo legível e rolagem utilizável, em vez de ocultar o que transborda.
- Toque em controles vizinhos e use teclado quando houver suporte. O critério de tamanho do alvo da WCAG 2.2 AA usa 24 × 24 pixels CSS, com exceções de espaçamento e outros casos. Controles maiores, como 48 × 48, podem ser mais confortáveis. Nenhuma medida comprova sozinha conformidade de acessibilidade.
- Preencha o formulário com o teclado virtual aberto. Confira rótulos, foco, erros, preservação dos dados, envio e confirmação. Para compras ou reservas, use um ambiente de teste autorizado e verifique o recibo ou registro correspondente.
- Repita em uma conexão móvel representativa. Carregamento lento ou requisição com falha deve deixar um caminho claro para continuar.
Um relato útil é específico. Exemplo hipotético: “Na reserva em 390 × 844, o teclado e o aviso de consentimento cobrem Enviar. A página rola, mas o botão continua inacessível”. Inclua URL, navegador, aparelho, estado, passos, captura, resultado esperado e responsável. Uma reserva bloqueada merece atenção mesmo com desempenho
Corrija a causa medida
Para um LCP lento, identifique o maior elemento real e o motivo do atraso. Se for uma imagem, torne-a detectável cedo e evite carregamento adiado. Pré-carregue apenas recursos que precisem ser descobertos antes, não todas as imagens e fontes. O guia de LCP explica
Registre interações lentas e investigue o trabalho bloqueante. Reduza scripts desnecessários ou divida tarefas longas, preservando funções obrigatórias e consentimento. Para mudanças de layout, reserve espaço para imagens, incorporações e conteúdo inserido. Os guias de INP e CLS ajudam a diagnosticar esses
No WordPress ou Shopify, teste mudanças de tema ou app em homologação, com o mesmo conteúdo e percurso. Meça o efeito antes de culpar todos os plugins ou propor uma reconstrução. Algumas correções são configurações; outras exigem alterar componentes. Nosso serviço de otimização de sites ajuda a identificar e executar o trabalho, com desenvolvimento web quando for preciso
Separe indexação e usabilidade
O Google recomenda design responsivo para indexação mobile-first, mas aceita outras configurações móveis. Garanta que Googlebot acesse conteúdo, imagens e metadados móveis. Uma página utilizável ainda pode ter um problema de indexação que exige uma investigação de SEO separada.
As métricas Core Web Vitals participam dos sistemas de classificação, mas bons resultados não garantem posições altas e uma pontuação ruim não comprova penalidade. As orientações de experiência na página do Google situam essas métricas dentro da utilidade mais ampla
Mantenha um registro prático: problema encontrado, alteração publicada, tarefa testada novamente com sucesso e validação de campo pendente. Revise os percursos afetados após mudanças de tema, app, formulário ou tags. Obter uma avaliação positiva e permitir que o visitante conclua a tarefa são