Mobile first: o que é e por que já é o padrão do Google

Mobile first começou como recomendação de projeto: desenhe primeiro para a tela pequena, depois expanda. Era uma escolha, e havia quem discordasse dela.

Hoje não é mais escolha, e o motivo é técnico: a versão que o Google indexa é a do celular. Isso deixou de ser transição e passou a ser o estado normal do índice. O que sobrou de decisão migrou para outro lugar, e é sobre esse deslocamento que este texto trata.

O que é mobile first

Mobile first é projetar a interface partindo da tela do celular e expandir dela para telas maiores, em vez de desenhar para desktop e depois cortar o que não couber. O termo foi cunhado por Luke Wroblewski, num artigo de 2009, e desenvolvido no livro Mobile First, de 2011.

O argumento original não era sobre quantidade de usuários no celular. Era sobre a restrição como ferramenta de projeto. Numa tela de 6 polegadas cabe menos, então é preciso decidir o que é essencial. Essa decisão, tomada primeiro, produz uma interface melhor também no desktop, porque o desktop herda a hierarquia em vez de herdar o excesso.

O caminho inverso não funciona pelo mesmo motivo: quando se corta de uma tela grande para uma pequena, corta-se pelo que sobra de espaço, não pelo que importa. O resultado típico é o menu que virou três pontinhos escondendo a ação principal.

Mobile first, responsivo e adaptativo não são a mesma coisa

Os três termos aparecem como sinônimo e descrevem coisas diferentes: um é abordagem de projeto, os outros dois são técnicas de implementação.

Um site pode ser responsivo e não ser mobile first: basta ter sido desenhado no desktop e adaptado com pontos de quebra depois. Ele funciona no celular sem ser bom nele. Manter a coerência entre os tamanhos fica muito mais barato quando existe um design system, porque as decisões de espaçamento e componente valem para todas as telas de uma vez.

O que mudou: a indexação mobile-first terminou

Aqui está a atualização que muda a leitura de qualquer material escrito antes de 2023. Durante anos, textos sobre o assunto diziam que existia um mobile-first index e “uma expectativa de que, no futuro, a indexação seja feita exclusivamente pela versão mobile”. Não é mais expectativa: o Google concluiu essa migração e o rastreador visita os sites como um smartphone. O relatório de indexação mobile-first no Search Console foi desativado justamente porque não havia mais o que acompanhar.

Vale separar duas coisas que o material antigo mistura, porque a confusão leva à conclusão errada:

• Indexação é qual versão do seu site entra no índice. Hoje, a do celular.
• Ranqueamento é a posição que essa versão alcança.

A frase “quando sua plataforma se adapta aos dispositivos móveis, naturalmente o seu ranqueamento melhora” descreve o mecanismo errado. Ser responsivo não dá bônus de posição: é linha de base. O que acontece de fato é o contrário, e é pior do que perder bônus: conteúdo que só existe na versão desktop não é indexado. Descrição escondida atrás de aba que não renderiza no celular, tabela de atributos que aparece só em tela grande, avaliação carregada apenas no desktop. Nada disso entra no índice, nem para quem pesquisa no computador. Não é perda de conversão de quem usa celular, é perda de conteúdo indexável para todo mundo.

As ferramentas que o Google desligou

Boa parte dos artigos sobre o tema, inclusive a versão anterior deste, recomendava ferramentas que não existem mais. A lista atualizada:

A substituição não é equivalente, e é bom saber disso: o teste antigo dava um veredito binário (“seu site é compatível”), e o que existe hoje dá métricas contínuas. É mais informativo e menos confortável, porque não existe mais uma tela verde para declarar o assunto encerrado.

O que medir hoje no celular

O sinal técnico que o Google efetivamente usa hoje são as Core Web Vitals, e elas são medidas separadamente para celular e desktop. Três métricas, com os limites considerados bons:

• LCP, até 2,5 s: quando o maior elemento da tela termina de aparecer.
• INP, até 200 ms: quanto a página demora a responder ao toque. Substituiu o antigo FID em 2024, e é a métrica mais sensível ao celular, porque toque e processador mais lento são exatamente o cenário dela.
• CLS, até 0,1: quanto o layout pula durante o carregamento. No celular pula mais, porque banner e imagem sem dimensão reservada empurram mais conteúdo numa tela estreita.

Duas regras práticas de leitura. Primeira: decida pelos dados de campo do Search Console, que vêm de usuários reais, e não pelo teste de laboratório, que roda numa condição ideal. Segunda: compare celular com desktop na mesma página. Quando a diferença é grande, o problema é de peso de recurso ou de processamento, não de layout. A conta completa de como isso afeta receita está em SEO para e-commerce.

Como projetar começando pela tela pequena

1. Escreva a ação principal da tela antes de desenhar. Uma por tela. Se houver duas, você vai descobrir no celular que não cabiam.
2. Comece pelo conteúdo, não pelo grid. Ordene a informação por importância numa coluna única. Essa ordem é o que sobrevive em qualquer largura.
3. Mantenha a ação principal visível sem rolagem e sem menu. Ação escondida atrás de três pontinhos é ação que não existe para metade das pessoas.
4. Dimensione alvo de toque e contraste desde o começo. É onde mobile e acessibilidade se encontram, e refazer depois custa muito mais: vale ler acessibilidade em projetos digitais antes de fechar o layout.
5. Teste em aparelho real e em rede ruim. Emulador mostra layout; ele não mostra quanto tempo o seu JavaScript leva num aparelho de entrada.

Esse exercício de cortar até sobrar o essencial é o mesmo de qualquer escopo de produto, e o método está em como definir o escopo do primeiro produto digital. E se o site roda numa plataforma visual, vale conferir antes o quanto ela deixa você controlar de layout e de carregamento, porque esse limite é real: é a discussão de low code.

PWA e aplicativo: quando cada um vale

PWA, ou Progressive Web App, é um site que ganha comportamento de aplicativo: pode ser instalado na tela inicial, funciona com conexão ruim e recebe notificação. A vantagem é não precisar convencer ninguém a baixar nada de uma loja, nem manter duas bases de código.

Duas ressalvas honestas, porque material antigo apresenta PWA como solução geral:

• No iOS o suporte é parcial. Notificação push para web só passou a existir a partir do iOS 16.4, em 2023, e várias capacidades continuam limitadas em relação ao Android. Se boa parte do seu público está no iPhone, vale verificar item por item antes de decidir.
• PWA não substitui aplicativo nativo quando o requisito é de hardware ou de loja. Uso intenso de câmera, sensor, integração profunda com o sistema ou presença na loja como canal de descoberta continuam pedindo nativo.

Para a maioria das empresas que apenas precisa ser bem usada no celular, a resposta não é PWA nem aplicativo: é um site responsivo, projetado a partir da tela pequena, com as Core Web Vitals em ordem. Se a aplicação for de uso contínuo e com muita interação, aí vale avaliar arquitetura de single page application. E para o vocabulário dos tipos de aplicação, o ponto de partida é software aplicativo.

Uma última observação sobre para onde o assunto está indo. A tela pequena continua sendo o formato dominante, mas parte das respostas passou a ser entregue antes do clique, dentro da própria página de resultados, com resumo gerado por IA. Isso muda quanto tráfego um bom ranqueamento entrega, e é assunto de o que é SGE. O que não muda é o requisito de base: se a versão que o buscador lê é a do celular, é ela que precisa estar completa.

Perguntas frequentes