Neste artigo
- O que a indexação mobile-first diz, de fato
- O celular define o ranking, ou é só um dos sinais?
- Os Core Web Vitals que valem hoje
- Como o Google mede isso por aparelho, não pela média do site
- O papel da rede 4G e do aparelho do visitante
- O que mais pesa no carregamento pelo celular
- Como testar o próprio site, não o próprio celular
Em 2025, 65% dos usuários de internet no Brasil acessavam a rede só pelo celular, sem usar computador, segundo o Cetic.br. Se um site carrega bem no notebook do escritório mas trava no 4G do cliente, é essa maioria que sente o problema primeiro. E é a versão para celular desse site, não a versão de desktop, que o Google usa para rastrear e indexar o conteúdo.
O que a indexação mobile-first diz, de fato
A documentação do Google Search Central é direta: o Google usa a versão para dispositivos móveis do conteúdo de um site, rastreada com o agente de smartphones, para indexação e classificação. Essa é a definição oficial de indexação mobile-first, e não é uma promessa futura. Segundo o próprio blog do Google Search Central, a transição terminou em 31 de outubro de 2023: depois de anos migrando site por site, o Google passou a rastrear e indexar a quase totalidade da web pela versão mobile, com uma exceção pequena, um conjunto reduzido de sites que simplesmente não funcionam em celular (erro em todas as páginas, robots.txt bloqueando só a versão mobile, ou todo o site redirecionando para a home), que continuam no rastreador de desktop legado enquanto esse problema não é corrigido.
Vale notar o que essa definição não diz. Ela fala em indexação e classificação, o rastreador entende e organiza o conteúdo pela versão mobile, e não afirma que a velocidade no celular seja, sozinha, o fator que decide a posição de uma página. A própria documentação do Google também pondera: embora não seja necessário ter uma versão para dispositivos móveis das páginas para que o conteúdo seja incluído nos resultados da Pesquisa Google, é altamente recomendável.
O celular define o ranking, ou é só um dos sinais?
Este texto usa o verbo pesar de propósito, em vez de definir. É a distinção que a própria Google faz na documentação sobre experiência da página: não existe um sinal único de experiência, os sistemas centrais de classificação da Busca avaliam uma série de sinais que se relacionam com a experiência geral, entre eles os Core Web Vitals, o HTTPS, a ausência de intersticiais intrusivos e a usabilidade em dispositivos móveis. A mesma página avisa que ter bons números no relatório de Core Web Vitals do Search Console, ou em ferramentas de terceiros, não garante que as páginas fiquem no topo dos resultados: a Busca sempre tenta mostrar o conteúdo mais relevante, mesmo quando a experiência da página é mediana.
Na prática, a velocidade no celular entra na conta, mas não substitui um conteúdo que responda à pergunta de quem busca. Para entender o conjunto de fatores que compõem uma estratégia de SEO, vale o guia de SEO para pequenas empresas.
Os Core Web Vitals que valem hoje
O Web Vitals do web.dev resume três métricas centrais de experiência: Largest Contentful Paint (LCP), o tempo até o maior elemento visível da tela terminar de carregar; Interaction to Next Paint (INP), o tempo de resposta da página a uma interação do visitante; e Cumulative Layout Shift (CLS), o quanto os elementos da página se deslocam de forma inesperada durante o carregamento.
| Status | LCP | INP | CLS |
|---|---|---|---|
| Bom | até 2,5s | até 200ms | até 0,1 |
| Precisa de melhorias | até 4s | até 500ms | até 0,25 |
| Ruim | acima de 4s | acima de 500ms | acima de 0,25 |
O status de uma página segue sempre a pior das três métricas: uma página com CLS ruim recebe status ruim mesmo com LCP ótimo, segundo o relatório de Core Web Vitals do Search Console.
Como o Google mede isso por aparelho, não pela média do site
Essas métricas não vêm de um teste único, feito uma vez num computador de laboratório. O web.dev recomenda medi-las no percentil 75 dos carregamentos reais, separados entre dispositivos móveis e desktop. Essa base de dados reais tem nome: Chrome UX Report (CrUX), que reúne, segundo a documentação do Chrome for Developers, visitas do Chrome em desktop (Windows, macOS, ChromeOS, Linux) e do Chrome para Android, por isso não inclui o Chrome para iOS nem navegadores baseados em Chromium de outras marcas. Dentro do CrUX, a dimensão form factor separa cada visita em phone, tablet ou desktop, inferida a partir do user agent do navegador.
É esse mesmo recorte por aparelho que aparece no relatório de Core Web Vitals do Search Console: os dados são organizados pelo dispositivo usado para acessar a URL, celular ou computador, cada um com sua própria página de resumo.
O papel da rede 4G e do aparelho do visitante
O 4G do título não é decorativo. Até fevereiro de 2025, o CrUX tinha uma dimensão chamada Effective Connection Type, que classificava a conexão de cada visita em faixas como 4G, 3G ou 2G. Segundo a documentação do Chrome for Developers, essa dimensão foi retirada naquele mês e substituída pela métrica RTT (round trip time, o tempo de ida e volta do sinal), mas a própria documentação já registrava que a maior parte das visitas rodava em conexões classificadas como 4G.
Quem sente esse tipo de limitação na prática é quem usa o PageSpeed Insights. Segundo a documentação oficial da ferramenta, a parte de laboratório (Lighthouse) simula as condições de carregamento de um aparelho de nível intermediário, o Moto G4, numa rede mobile, para a aba celular, e um desktop emulado com conexão cabeada, para a aba computador. Em outra auditoria do Lighthouse, voltada a apps, a documentação do Chrome for Developers descreve o cálculo do tempo até a página ficar interativa numa conexão 4G lenta, e reprova o resultado se esse tempo passar de 10 segundos. É essa combinação, aparelho comum mais rede limitada, que costuma expor um site testado só no wifi rápido do escritório e no celular topo de linha de quem o construiu.
O servidor que hospeda o site entra nessa conta antes do aparelho do visitante. Segundo o guia de otimização de LCP do web.dev, um TTFB alto (o tempo até o primeiro byte da página chegar) pode tornar difícil, ou até impossível, atingir um LCP de 2,5 segundos, porque nada acontece no site enquanto o servidor não entrega esse primeiro byte. Vale ver como escolher hospedagem sem cair em armadilha comum no post Hospedagem de Site: Como Escolher sem Cair em Cilada.
O que mais pesa no carregamento pelo celular
Três tipos de recurso costumam concentrar o peso de uma página lenta no celular, segundo os guias de otimização do web.dev.
- Imagens. Formatos modernos como WebP ou AVIF reduzem o tamanho do arquivo, e a imagem que forma o elemento do LCP nunca deve usar carregamento lazy, porque isso atrasa exatamente a métrica que se quer melhorar. A mesma documentação recomenda pré carregar essa imagem com prioridade alta, usando o atributo fetchpriority.
- JavaScript. Byte a byte, o JavaScript custa mais para o navegador processar do que uma imagem ou uma fonte do mesmo tamanho, porque o código precisa ser interpretado, compilado e executado, não só decodificado. A documentação do web.dev cita um exemplo real: o site da CNN levava cerca de 4 segundos para interpretar e compilar o próprio JavaScript num iPhone 8 topo de linha, contra cerca de 13 segundos num aparelho mediano (Moto G4).
- Fontes. Enquanto uma fonte web não carrega, o navegador costuma atrasar a exibição do texto, e a troca de fonte pode deslocar o layout e piorar o CLS. O web.dev recomenda usar só o formato WOFF2, reduzir os caracteres incluídos na fonte e usar a propriedade font-display para controlar esse comportamento durante o carregamento.
Um raciocínio mais completo sobre o que pesa em cada métrica está no post Site Lento Perde Venda: Como Deixar Seu Site Rápido (Core Web Vitals).
Como testar o próprio site, não o próprio celular
Testar no próprio celular, numa rede boa, mostra a experiência de quem testa, não a de quem usa o site em outro contexto. O caminho correto passa por duas ferramentas com dado real.
PageSpeed Insights. Reporta os dois lados: o dado de campo, vindo do CrUX dos últimos 28 dias, quando o site tem tráfego suficiente, e o dado de laboratório do Lighthouse, na simulação de aparelho e rede descrita acima. A ferramenta mostra abas separadas para celular e para computador, segundo a documentação oficial do PageSpeed Insights.
Relatório de Core Web Vitals do Search Console. Mostra o mesmo tipo de dado de campo ao longo do tempo, agrupado por status (bom, precisa de melhorias ou ruim) e separado por dispositivo, o que ajuda a enxergar se o problema é geral ou concentrado no celular.
Rodar esse teste de tempos em tempos, e não só depois de uma reclamação, é o tipo de tarefa que cabe numa rotina de manutenção e suporte do site, junto com atualização e backup.
Indexação mobile-first já é regra desde 2023. A experiência da página entra como um entre vários sinais que os sistemas de classificação do Google avaliam, e essa experiência é medida com base em condições reais de rede e aparelho, não no ambiente ideal de quem constrói o site. Um site que já nasce pensando nesse recorte evita boa parte do retrabalho de otimizar depois.
Quer saber como seu site se sai no celular, com dado real de campo e de laboratório, e o que priorizar primeiro?
Perguntas frequentes
O celular realmente define o ranking do meu site no Google?
Não sozinho. O Google usa a versão mobile do conteúdo para indexação e classificação, mas a própria documentação de experiência de página diz que não existe um sinal único: os sistemas de classificação avaliam vários sinais, entre eles os Core Web Vitals, o HTTPS e a usabilidade em dispositivos móveis. Bons números não garantem topo de ranking, e conteúdo relevante continua acima disso.
O que é indexação mobile-first, na prática?
É o Google usar a versão para dispositivos móveis do conteúdo de um site, rastreada com o agente de smartphones, para indexar e classificar esse conteúdo. Segundo o blog oficial do Google Search Central, essa transição terminou em 31 de outubro de 2023, com exceção de um conjunto pequeno de sites que não funcionam em celular e continuam no rastreador de desktop legado.
Quais Core Web Vitals o Google mede hoje e quais os limites de bom?
Três: Largest Contentful Paint (LCP), até 2,5 segundos; Interaction to Next Paint (INP), até 200 milissegundos; e Cumulative Layout Shift (CLS), até 0,1. O web.dev recomenda medir essas métricas no percentil 75 dos carregamentos reais, separando sempre dispositivos móveis de desktop, porque a experiência dos dois grupos costuma ser bem diferente.
Meu site é rápido no wifi do escritório. Isso já garante uma boa experiência no celular?
Não garante. O PageSpeed Insights testa o lado de laboratório simulando um aparelho de nível intermediário (Moto G4) numa rede mobile, não o celular mais rápido de quem construiu o site. O dado de campo, vindo do CrUX, mostra a experiência real dos últimos 28 dias, incluindo visitantes com rede e aparelho bem mais limitados que os de um teste feito no escritório.
Onde eu vejo se meu site tem problema de velocidade especificamente no celular?
No PageSpeed Insights, que mostra abas separadas para celular e computador, e no relatório de Core Web Vitals do Search Console, que agrupa o dado de campo por dispositivo (celular ou computador) e por status (bom, precisa de melhorias ou ruim). O status de uma página segue sempre a pior das três métricas.
Quer um projeto assim na sua empresa?
Me conta o que você precisa e eu te respondo em até 48h com um caminho claro, sem compromisso.
Falar no WhatsApp
