SEO mobile: o que muda quando o tráfego vem do celular

A maioria dos testes de SEO mobile acontece do jeito errado: no Chrome do desktop, com a janela redimensionada para parecer um celular, numa conexão de escritório de 100 Mbps. Isso mostra o layout, mas esconde o problema real. O visitante típico que chega pelo celular está num Android intermediário, com um processador bem mais fraco que o do seu notebook, navegando em 4G que varia entre bom e péssimo dependendo do bairro e do horário. É essa combinação — hardware modesto mais rede instável — que decide se a página carrega em dois segundos ou em doze.

Este texto não é sobre o que fazer, no sentido de otimizar imagem ou reduzir JavaScript — isso qualquer checklist já diz. É sobre como testar de um jeito que reproduza a experiência real do visitante, como orçar o peso da página para esse cenário, e como confirmar que o Googlebot está vendo a mesma página que a pessoa vê. As métricas de performance em si (o que é INP, o que é CLS, como cada uma é calculada) já têm guias próprios neste blog; aqui o assunto é o dispositivo, a rede e o rastreamento.

Por que testar no desktop engana você

Um notebook processa JavaScript muito mais rápido que um smartphone de entrada ou intermediário. Uma página que parece instantânea no desktop pode travar por um segundo inteiro num aparelho mais simples só para processar os scripts que rodam antes da primeira interação. O problema não aparece no teste porque o hardware do teste não é o hardware do público, e essa diferença de hardware costuma ser maior do que qualquer otimização isolada de código consegue compensar.

O mesmo vale para a rede. Uma conexão de escritório ou de fibra doméstica mascara qualquer coisa relacionada a latência: chamadas de API que disparam em cascata, fontes que só carregam depois do CSS, terceiros que abrem mais uma conexão TCP. Em 4G real, cada uma dessas etapas soma um atraso perceptível, e a soma delas é o motivo de uma página "rápida no teste" carregar visivelmente devagar no bolso do usuário.

Redimensionar a janela do navegador testa o layout responsivo. Não testa performance, e performance é a parte que decide se a pessoa espera a página carregar ou fecha a aba antes disso.

Simule o dispositivo e a rede de verdade

O primeiro ajuste é trocar a emulação por simulação de verdade. O modo de dispositivo do Chrome DevTools já vem com perfis de rede prontos (algo equivalente a "4G rápido" e "4G lento"); usar um desses em vez da rede sem limite muda completamente a leitura de qualquer página. A diferença entre testar sem throttling e testar com um perfil de 4G lento costuma ser a diferença entre "não vejo problema nenhum" e "agora entendo a reclamação".

O segundo ajuste é o processador. O DevTools também permite simular desaceleração de CPU (um fator de 4x ou 6x é um ponto de partida razoável para representar um aparelho de entrada). Rode o teste com throttling de rede e de CPU ao mesmo tempo — isoladamente, cada um esconde parte do problema que o outro revela.

Sempre que possível, complemente com um teste em aparelho físico e não só emulado. Um Android de faixa intermediária real, conectado por depuração USB ao Chrome do desktop (chrome://inspect), mostra travamentos de scroll, atraso de toque e problemas de memória que a emulação por software simplesmente não reproduz, porque a emulação simula tempo, não hardware.

• Teste com throttling de rede e de CPU juntos, não separados
• Use um perfil de rede 4G, não a conexão sem limite do escritório ou do coworking
• Valide pelo menos uma vez por trimestre num aparelho intermediário real, não só emulado
• Ferramentas de teste remoto com localização e rede configuráveis mostram como a página se comporta a partir de uma conexão de operadora real, não da rede do provedor de hospedagem

Um orçamento de peso para a versão mobile

Sem um limite explícito, o peso da página cresce sozinho: mais uma imagem, mais um pixel de conversão, mais um widget de chat, cada item parece pequeno isoladamente e a soma nunca aparece até o dia em que alguém mede tudo junto. A solução prática é definir um teto de peso total para a versão mobile antes de qualquer decisão de adicionar algo — e tratar qualquer item novo como um débito que precisa ser justificado, não como algo automaticamente aceito.

As imagens costumam ser o maior item do orçamento e o mais fácil de controlar: servir o tamanho real necessário para a tela (não a imagem original de câmera redimensionada por CSS), usar um formato moderno com boa compressão e aplicar carregamento adiado (lazy loading) em tudo que estiver fora da primeira tela visível. Uma única imagem de herói mal otimizada pode pesar sozinha mais do que o restante da página inteira.

Scripts de terceiros são o item que mais foge do controle porque cada um chega isolado, aprovado por uma área diferente da empresa em momentos diferentes: um widget de chat aprovado pelo time de suporte, um pixel de anúncio aprovado pelo time de mídia, um banner de consentimento de cookies aprovado pelo jurídico, uma ferramenta de heatmap aprovada pelo produto. Cada um, sozinho, parece leve. Juntos, com frequência, pesam mais que o conteúdo que o visitante veio buscar — e cada um ainda abre sua própria conexão de rede, o que em 4G custa tempo real antes mesmo do script rodar.

• Defina um teto de peso total (por exemplo, um valor fixo de KB por página) e meça contra ele a cada publicação
• Audite os scripts de terceiros carregados hoje e pergunte, item por item, se ainda são usados
• Carregue chat, pixels e banners de consentimento de forma adiada quando a ferramenta permitir, em vez de bloquear a renderização inicial
• Prefira uma imagem de herói leve e bem dimensionada a uma imagem grande "encolhida" por CSS

O que o Googlebot realmente renderiza

Desde que a indexação passou a ser mobile-first, o Google rastreia e indexa principalmente a versão mobile da página — não a versão desktop. Isso significa que qualquer conteúdo, link interno ou dado estruturado que exista só na versão desktop, ou que na versão mobile só seja carregado após uma interação do usuário, tende a não contar para o ranqueamento da mesma forma. A pergunta relevante deixa de ser "o que existe no HTML" e passa a ser "o que o rastreador mobile efetivamente vê depois de renderizar a página".

A ferramenta de inspeção de URL do Search Console mostra exatamente isso: o HTML renderizado pelo Googlebot, uma captura de tela de como a página apareceu para ele e a lista de recursos que ele não conseguiu carregar. Vale checar essa lista com atenção — é comum encontrar um arquivo de CSS ou de JavaScript bloqueado por robots.txt que, sem querer, impede o rastreador de renderizar o layout mobile corretamente, mesmo que o visitante humano veja a página perfeita.

Vale conferir também se conteúdo, links e dados estruturados batem entre as duas versões quando o site ainda mantém alguma diferenciação entre mobile e desktop (um menu que só existe numa das versões, um bloco de texto que aparece só na desktop). Onde a versão mobile é simplesmente responsiva a partir do mesmo HTML, esse risco praticamente desaparece — o que reforça o design responsivo como a opção mais segura de manutenção.

Uma rotina de checagem antes de publicar

Performance mobile se perde aos poucos, não de uma vez: um script novo aqui, uma imagem maior ali, e seis meses depois ninguém sabe exatamente quando a página deixou de ser rápida. Uma rotina curta antes de cada publicação evita boa parte disso, porque transforma a checagem de "algo que a gente devia lembrar de fazer" em um passo do processo.

• Rodar o teste com throttling de rede e CPU ligados, não a conexão do escritório
• Comparar o peso total da página contra o orçamento definido para o site
• Abrir a inspeção de URL do Search Console e conferir a captura renderizada
• Verificar se algum recurso (CSS, JS, imagem) está bloqueado por robots.txt
• Testar o toque real na tela: tamanho de botões, espaçamento entre links, teclado que não cobre o campo que a pessoa está preenchendo

Erros que só aparecem em campo, não em laboratório

Alguns problemas de SEO mobile simplesmente não aparecem em nenhum teste de laboratório, por mais bem configurado que esteja, porque dependem de condições que só existem no mundo real: uma rede que cai por dois segundos e volta, um teclado virtual que cobre metade da tela num aparelho de tela pequena, um popup de consentimento que trava o toque porque carregou depois do conteúdo por trás dele. Nenhum desses aparece com throttling simulado; aparecem só quando alguém segura o telefone.

Por isso vale complementar os testes técnicos com uma sessão simples e recorrente: pegar um aparelho real, numa rede móvel real, e navegar pelo site como um visitante navegaria — sem script, sem checklist, só prestando atenção em onde a mão hesita ou onde a página trava. É baixo custo e revela categorias de problema que nenhuma ferramenta automatizada cobre sozinha, porque essas ferramentas testam o que foi pensado para testar, e o comportamento real de rede e de toque tem o hábito de escapar exatamente do que foi previsto.

A segunda visita importa tanto quanto a primeira

Boa parte da conversa sobre performance mobile foca só no primeiro carregamento, mas em rede móvel instável a segunda visita — e a terceira, e a quinta — sofre do mesmo problema se a página não for configurada para aproveitar o que já foi baixado. Alguém que sai do site para checar uma mensagem e volta em seguida, ou que visita a mesma página em duas sessões diferentes ao longo do dia, deveria encontrar um carregamento bem mais rápido na segunda vez, não o mesmo tempo de espera.

Isso depende de cabeçalhos de cache configurados corretamente para os recursos estáticos (imagens, CSS, JavaScript, fontes): um tempo de expiração adequado permite que o navegador reutilize o que já baixou em vez de buscar tudo de novo pela rede. Em conexão de fibra a diferença é pequena e passa despercebida; em 4G instável, é a diferença entre a página aparecer quase instantânea e o visitante esperar de novo o mesmo tempo da primeira visita.

Vale checar isso especificamente nos recursos que mudam pouco — logotipo, ícones, folha de estilo principal, bibliotecas de terceiros com versão fixa — porque são justamente esses que mais se beneficiam de um cache de longa duração e que, com frequência, são configurados com um tempo de expiração curto demais ou nenhum tempo de expiração, por descuido na configuração do servidor.

• Confira o cabeçalho de cache dos arquivos estáticos, não só do HTML
• Recursos com versão fixa (uma biblioteca JavaScript, por exemplo) podem ter cache bem mais longo que o HTML da página
• Teste a segunda visita, não só a primeira, ao medir performance mobile