Teste de compatibilidade móvel 2026: ferramentas e API PSI

O Google aposentou o Teste de compatibilidade com dispositivos móveis em dezembro de 2023, mas você ainda pode verificar a usabilidade móvel de graça. Use o PageSpeed Insights e o Lighthouse para diagnóstico de desempenho, o Chrome DevTools para verificar o layout e um celular de verdade para a navegação e os formulários. Essas verificações respondem a perguntas diferentes. Uma página rápida ainda pode ter botões que ninguém alcança, e uma página fácil de usar ainda pode carregar devagar.

Quer o veredito em 20 segundos? Use nosso Teste de compatibilidade móvel gratuito: cole uma URL e receba a pontuação de viewport, largura fixa, texto pequeno, peso da página e rastreamento, com a correção de cada item. Sem e-mail.

Quais verificadores de compatibilidade móvel ainda funcionam em 2026

O conselho de “rodar o Teste de compatibilidade com dispositivos móveis do Google” morreu. O Google anunciou que desativaria o relatório de Usabilidade em dispositivos móveis do Search Console, a ferramenta Teste de compatibilidade com dispositivos móveis e a API do teste a partir de 1º de dezembro de 2023, e a desativação foi confirmada publicamente em 4 de dezembro de 2023. O motivo declarado pelo Google nesse anúncio: a usabilidade móvel continua fazendo parte das orientações sobre experiência na página, mas outros recursos surgiram desde 2015, “including Lighthouse from Chrome”.

O Google também removeu todas as menções à ferramenta da central de ajuda da Pesquisa em 1º de dezembro de 2023 e redirecionou as URLs de usabilidade móvel do Search Console para a visão geral da propriedade. No anúncio de abril de 2023, o Google indica o Lighthouse como substituto. Um guia que ainda oferece a ferramenta aposentada como opção ativa está desatualizado.

Resta um verificador independente: a Mobile Friendliness Test Tool do Bing. Ela verifica como o Bing vê a página no celular, incluindo a configuração do viewport, a largura do conteúdo, a legibilidade e o espaçamento dos alvos de toque. O veredito dela não diz como o Google ou um assistente de IA vai classificar ou citar a página.

Usabilidade móvel e indexação mobile-first são verificações diferentes

O Google usa a versão móvel do conteúdo de uma página para indexação e ranking. As orientações sobre indexação mobile-first aceitam design responsivo, veiculação dinâmica e URLs móveis separadas. O design responsivo é a opção recomendada porque é mais fácil de implementar e manter.

Verifique se o Googlebot consegue acessar o conteúdo, as imagens e os metadados no celular. Depois verifique se uma pessoa consegue usá-los com facilidade. Uma página móvel bloqueada é um problema de rastreamento; um botão apertado é um problema de usabilidade. Nem uma pontuação do Lighthouse nem uma medição de alvos de toque, sozinhas, dizem se uma página será indexada.

Prefere um olhar especializado no seu site em vez de mais uma aba de auditoria? Conheça nossos serviços de otimização de sites.

Auditoria móvel com o PageSpeed Insights e o Lighthouse

Comece pelo PageSpeed Insights. Cole uma URL, rode o teste e leia a aba Celular antes da aba Computador.

O relatório tem duas metades que as pessoas confundem o tempo todo:

• Dados de campo no topo: medições de usuários reais do Chrome vindas do Chrome UX Report, atualizadas diariamente em uma janela móvel de 28 dias. São esses os dados que os sinais de experiência na página do Google realmente usam.
• Dados de laboratório abaixo: uma única execução simulada do Lighthouse nos servidores do Google. Úteis para diagnóstico, não um veredito sobre usuários reais.

Para passar em uma avaliação completa das Core Web Vitals com as três métricas, a página precisa atingir o limite “bom” no percentil 75 das três métricas. Sem dados de campo, o relatório não consegue fazer essa avaliação completa; isso não prova que a página foi reprovada. O Lighthouse não consegue medir o INP de campo com uma única execução de navegação.

Fonte: limites das Core Web Vitals no web.dev, válidos em 2026. O INP substituiu o First Input Delay (FID) como Core Web Vital em 12 de março de 2024, então ignore qualquer checklist que ainda mande otimizar o FID.

Duas mudanças no PageSpeed Insights que moveram a régua

Em 5 de dezembro de 2024, o PageSpeed Insights ajustou a intensidade da limitação da CPU (o processador), o que em geral aumentou o Total Blocking Time nas execuções de laboratório no celular. Os resultados de campo e de computador não foram afetados. Se a sua pontuação de laboratório no celular caiu sem que nada tenha sido publicado, essa é uma causa plausível.

O PageSpeed Insights (PSI) e a API dele passaram para o Lighthouse 13.0 em 20 de outubro de 2025. As versões podem mudar os diagnósticos exibidos, então registre a versão do Lighthouse com cada resultado. Para monitorar usuários reais de forma contínua, o Google recomenda a CrUX API ou a CrUX History API: o Google planeja deixar de incluir os dados de campo do CrUX na API do PSI.

Existe substituto para a API do Teste de compatibilidade?

A antiga API do Teste de compatibilidade com dispositivos móveis foi aposentada junto com a ferramenta. A API do PageSpeed Insights consegue automatizar uma execução móvel do Lighthouse, mas não reproduz o antigo resultado de aprovado ou reprovado. Você ainda precisa das verificações de layout e interação.

Esta requisição pede diagnósticos de desempenho, acessibilidade e SEO no celular. Troque a URL de exemplo por uma página pública que você queira testar:

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'

O guia de primeiros passos do Google permite testar a API sem chave e recomenda uma chave para requisições automatizadas frequentes. Confira a cota atual do seu projeto antes de agendar um lote. Se a resposta for HTTP 429, investigue a cota em vez de tratar a resposta como resultado da página testada. A referência da API documenta os parâmetros e os campos da resposta.

Leia lighthouseResult.categories para as pontuações por categoria e lighthouseResult.audits para os resultados individuais. As pontuações usam uma escala de zero a um; 0,92 corresponde a 92 de 100. Guarde fetchTime e lighthouseVersion com a URL testada para que as comparações futuras usem uma execução conhecida. Trate os erros HTTP e o runtimeError antes de considerar uma resposta como auditoria.

Para o desempenho de campo, use a CrUX API ou a CrUX History API. Uma URL pode não ter dados suficientes de usuários reais. Mantenha essa situação separada de um resultado ruim e nunca apresente uma pontuação de laboratório como aprovação de campo nas Core Web Vitals.

Rodando o Lighthouse localmente

O Lighthouse vem dentro do Chrome DevTools. Abra a página, clique com o botão direito, escolha Inspecionar, abra o painel Lighthouse, selecione Celular e clique em Gerar relatório. Ele roda no Chrome instalado na sua máquina e nunca envia resultados a um servidor remoto, então você pode auditar versões de homologação e protegidas por senha que o PSI não alcança.

A predefinição móvel não é um chute. O Lighthouse aplica um multiplicador de lentidão de CPU de 4x para levar uma CPU de computador ao nível de um celular intermediário, mais uma predefinição de rede “Slow 4G” que representa o quartil mais lento das conexões 4G. A emulação de dispositivo usa um perfil Moto G Power com viewport de 412 por 823 e fator de escala de 1,75, com modo móvel e toque ativados, segundo o próprio constants.js do Lighthouse (uma versão anterior deste artigo citava 2,625, o fator de escala do antigo perfil Moto G4 que o Lighthouse aposentou, e não o valor atual).

O Lighthouse 13 substituiu muitas auditorias de desempenho por insights alinhados ao DevTools, mantendo unsized-images e non-composited-animations como diagnósticos. Ele também removeu a antiga auditoria de tamanho de fonte. Um diagnóstico removido não torna aceitável um texto ilegível; confira o texto real da página em um celular.

Passo a passo da emulação de dispositivos no Chrome DevTools

Pontuações falam de velocidade. A emulação mostra se a página é utilizável. Faça as duas coisas.

1. Abra a página no Chrome, use o atalho de Inspecionar e ative a Barra de ferramentas de dispositivo.
2. Escolha primeiro um viewport estreito. Teste em 360 por 800 e 390 por 844, depois suba até larguras de tablet.
3. Defina a limitação como Mid-tier mobile ou aplique Slow 4G mais CPU 4x manualmente, igual ao perfil do Lighthouse.
4. Gire para paisagem. Abra o menu principal, um formulário e uma etapa de checkout ou contato em cada orientação.
5. Observe o painel Elements enquanto redimensiona para descobrir qual contêiner está transbordando.

O que a emulação pega e uma pontuação nunca vai pegar:

• Alvos de toque pequenos espremidos contra o vizinho, incluindo casos cobertos pela auditoria de alvos de toque do Lighthouse
• Rolagem horizontal causada por tabela de largura fixa, conteúdo incorporado ou imagem grande demais
• Cabeçalhos fixos e banners de cookies ocupando metade do viewport em uma tela baixa
• Modais com o botão de fechar empurrado para fora da tela
• Campos que abrem o teclado errado ou dão zoom ao receber foco

Para controles de toque confortáveis, mire em 48 por 48 pixels CSS quando o layout permitir. A regra documentada do Lighthouse considera tanto o tamanho do alvo quanto a sobreposição com alvos próximos; ela não reprova todo controle menor. O critério de tamanho de alvo da WCAG 2.2 AA, que é separado, usa 24 por 24 pixels CSS com espaçamento e outras exceções. Nenhum dos dois é um limite universal de ranking do Google.

Conheça o limite. A emulação redimensiona um navegador de computador e simula uma CPU lenta. Ela não reproduz a latência real do toque, as particularidades do Safari no iOS, o alcance do polegar nem o comportamento de um Android intermediário rodando um script pesado sob limitação térmica. Termine toda auditoria em um celular de verdade.

Lendo os dados móveis das Core Web Vitals no Search Console

O antigo relatório de Usabilidade em dispositivos móveis acabou. Use o relatório Core Web Vitals do Search Console para o desempenho com usuários reais e verifique o layout e as interações separadamente.

Abra o Search Console, vá em Core Web Vitals e trabalhe o relatório de dispositivos móveis. O Google divide a visão geral por dispositivo, agrupa URLs com experiências parecidas e dá a cada grupo o status da sua pior métrica. Ou seja, uma métrica ruim em um modelo arrasta todas as URLs desse modelo para Ruim.

Como lemos:

• Clique em Abrir relatório ao lado do gráfico de dispositivos móveis e alterne entre as abas Ruim, Precisa de melhorias e Bom.
• Leia a tabela “Por que os URLs não são considerados bons”. Ela aponta a métrica reprovada e o limite ultrapassado.
• Corrija o modelo, não a URL. O status por grupo significa que uma correção no modelo move muitas páginas.
• Use Iniciar acompanhamento depois de publicar. O Google faz uma sessão de monitoramento de 28 dias e só marca o problema como corrigido se ele ficar ausente durante toda a janela.

Duas ressalvas. Os dados são um agregado móvel de 28 dias, então uma correção publicada na terça não aparece na quarta. E o Google diz claramente que os dados do PageSpeed Insights podem ser diferentes do relatório Core Web Vitals, porque um é uma execução de laboratório em um perfil de dispositivo e o outro são milhares de sessões reais. Quando discordarem, confie nos dados de campo e use a execução de laboratório para achar a causa. O web.dev explica a diferença entre laboratório e campo em mais detalhes. As mesmas métricas fazem parte da nossa forma de trabalhar a otimização de sites.

As falhas móveis mais comuns e como corrigir

Estas são as falhas que as ferramentas acima foram feitas para pegar, com o limite ou a regra que cada uma usa.

Repare qual ferramenta detecta o quê. Nenhum verificador cobre a lista inteira, e é exatamente por isso que o antigo selo de aprovado ou reprovado nunca foi suficiente.

A auditoria que fazemos, passo a passo

Esta é a sequência que usamos no nosso site e nos sites de clientes, nesta ordem.

1. Escolha três URLs, não uma. A página inicial, uma página importante de serviço ou produto e um post do blog. Modelos falham de jeitos diferentes.
2. Search Console primeiro. Core Web Vitals, visão de dispositivos móveis. Anote quais grupos de URLs estão em Ruim ou Precisa de melhorias e qual métrica aparece. São usuários reais, então isso define a prioridade.
3. PSI em uma URL de cada grupo reprovado. Compare dados de campo com dados de laboratório. Se o campo diz Ruim e o laboratório diz que está tudo bem, procure scripts de terceiros, estados com login ou servidores de origem lentos que uma execução limpa de laboratório nunca vê.
4. Lighthouse local nas mesmas três URLs. Predefinição móvel. Leia os diagnósticos de alvos de toque e unsized-images, e o painel de Acessibilidade para falhas de contraste.
5. Modo de dispositivo do DevTools em 360 por 800. Abra o menu, um formulário e a principal etapa de conversão. Gire. Procure overflow e conteúdo bloqueado.
6. Mobile Friendliness Test do Bing nas mesmas URLs, para ter o veredito de um segundo rastreador sobre viewport, largura, legibilidade e espaçamento de toque.
7. Um celular de verdade, de preferência um Android intermediário. Carregue pela rede móvel, não pelo Wi-Fi do escritório. Faça a ação de conversão do começo ao fim.
8. Publique as correções nos modelos e use Iniciar acompanhamento no Search Console, contando 28 dias até a validação terminar.

Por que os dados de campo e de laboratório discordam

O Google deixa claro que os dados do PageSpeed Insights podem ser diferentes do relatório Core Web Vitals. Dados de laboratório são uma execução simulada em um perfil de dispositivo. Dados de campo são um agregado móvel de 28 dias de usuários reais do Chrome. O guia do web.dev sobre dados de laboratório e de campo lista as causas mais comuns: aparelhos e redes reais variam mais que o laboratório, scripts de terceiros se comportam de outro jeito com usuários reais, o cache e o cache de voltar e avançar mudam as visitas repetidas, e o CrUX só informa URLs com tráfego suficiente. Quando discordarem, trate os dados de campo como veredito e a execução de laboratório como diagnóstico.

Quando revisamos um site, olhamos primeiro os dados de campo do Search Console e depois usamos o PSI e o Lighthouse para identificar o elemento ou o script. Os próprios guias de otimização do Google são o manual:

• LCP lento: otimizar o Largest Contentful Paint. Comprima a imagem principal, use um formato moderno, pré-carregue o elemento LCP e não use lazy loading nele.
• INP alto: otimizar o Interaction to Next Paint. Divida tarefas longas e adie ou remova o JavaScript de terceiros que bloqueia a thread principal.
• CLS alto: otimizar o Cumulative Layout Shift. Defina largura, altura ou aspect-ratio em imagens e incorporações para que o layout não pule quando elas carregam.

O Search Console agrupa URLs com experiências parecidas e dá a cada grupo o status da sua pior métrica. Uma única correção de modelo, como definir dimensões de imagem em um componente de card compartilhado, pode mover muitas URLs de uma vez. Depois de publicar, use Iniciar acompanhamento e espere a janela inteira de 28 dias até o Google marcar o problema como corrigido.

Repita a sequência de oito passos depois de trocas de tema, instalação de plug-ins ou apps e qualquer publicação no gerenciador de tags, além de uma rodada trimestral programada. Os scripts de terceiros são um risco documentado para o INP nas orientações do Google sobre INP, e é por isso que o passo 3 compara os dados de campo com uma execução limpa de laboratório. Para rastreamento, indexação e trabalho na página em torno desta verificação móvel, veja nosso serviço de otimização para mecanismos de busca.

E se você usa WordPress ou Shopify

As duas plataformas levam você quase até o fim com configuração, sem código:

• Um tema responsivo, testado em 360 px antes de você se comprometer com ele
• Lazy loading nativo em tudo, menos na imagem de LCP
• Formatos modernos de imagem nas dimensões certas, não arquivos de computador reduzidos com CSS (folhas de estilo em cascata)
• Modelos do Shopify Online Store 2.0 e tamanho de imagem por seção
• Uma auditoria dos apps e plug-ins instalados, já que cada um costuma adicionar JavaScript que bloqueia a renderização

Rode o Lighthouse de novo depois de cada mudança de tema ou app. É aí que as pontuações móveis caem sem ninguém perceber. Se o próprio tema é o teto, a solução é reconstruir o site em um framework moderno, com desempenho e SEO planejados desde o início, que é o que entrega nosso serviço de desenvolvimento de sites.

Perguntas frequentes

Como verifico a compatibilidade móvel agora que o teste do Google acabou?

Rode o Lighthouse no Chrome DevTools com a predefinição Celular, confira a aba Celular no PageSpeed Insights, leia o relatório móvel de Core Web Vitals no Search Console e confirme em um celular de verdade. O Mobile Friendliness Test do Bing ainda dá um veredito de aprovado ou reprovado, se você quiser um.

Qual é a diferença entre compatível com dispositivos móveis e responsivo?

Compatível com dispositivos móveis significa que a página é utilizável em um celular. O design responsivo adapta a mesma página a viewports diferentes com layouts fluidos e media queries de CSS. O Google recomenda o design responsivo por ser mais fácil de manter, mas também aceita veiculação dinâmica e URLs móveis separadas.

Preciso de um site móvel separado?

Não. Uma única URL responsiva é mais simples de manter, evita lidar com conteúdo duplicado e oferece um só conjunto de sinais para SEO e para a otimização para mecanismos generativos.

O Google penaliza sites que não são compatíveis com dispositivos móveis?

Verifique o acesso ao conteúdo e a experiência do usuário separadamente. O Google precisa acessar e renderizar o seu conteúdo móvel para indexá-lo. As Core Web Vitals são usadas no ranking, mas o Google continua buscando conteúdo relevante mesmo quando a experiência na página é fraca. Uma pontuação móvel ruim, por si só, não prova desindexação, penalidade nem uma perda específica de posições.

Por que o PageSpeed Insights e o Search Console discordam?

O Google afirma que os dois podem ser diferentes. Os dados de laboratório do PSI são uma execução simulada em um perfil de dispositivo. O Search Console mostra um agregado móvel de 28 dias de usuários reais do Chrome em todo um grupo de URLs. A documentação do Google sobre o relatório Core Web Vitals e o artigo do web.dev sobre laboratório e campo dizem para tratar os dados de campo como veredito e os de laboratório como diagnóstico.

Quatro ferramentas substituíram o selo único

O selo único de aprovado ou reprovado acabou e não vai voltar. O que o substituiu é melhor: medição de campo com usuários reais, uma auditoria de laboratório que você pode rodar na homologação, emulação de viewport para o layout e o veredito de um segundo rastreador, o do Bing. Monte seu processo em torno dessas quatro, priorize pelo que o Search Console diz que os usuários reais vivem e corrija modelos em vez de URLs individuais.

Cuidamos disso a partir de Vancouver como otimização de sites. Se o desempenho móvel está custando posições ou conversões, uma auditoria de crescimento é o lugar para começar.