O Google disse que nosso site não era eficiente no celular. A culpa era dos contadores
O Search Console sinalizou 102 endereços não eficientes no celular em nosso próprio site, e os mesmos 102 apareciam em verde no desktop. A primeira hipótese, uma animação de fundo, não sobreviveu à medição. Os culpados foram as tags de anúncios, e o detalhe mais caro, uma segunda cópia da mesma biblioteca de 189 KB. Um passo a passo completo com números e um guia de seis etapas.
O Search Console acendeu o alerta para o nosso próprio site: 102 URLs "ineficazes" no mobile, e as mesmas 102 em verde no desktop. Um site, um layout, dois veredictos. Fomos investigar, a primeira hipótese óbvia estava errada, e o culpado era algo que está em quase todo site e que os donos raramente consideram parte dele. Abaixo está a investigação completa, com medições, e um passo a passo para verificar e corrigir o seu.
O que o Google realmente mede
A métrica é o INP, Interaction to Next Paint. O Google a descreve assim:
"O INP é uma métrica que avalia a capacidade de resposta geral de uma página às interações do usuário, observando a latência de todos os cliques, toques e interações de teclado que ocorrem durante o tempo de vida de uma visita do usuário à página."
Limites: bom é 200 ms ou menos, precisa melhorar é de 200 a 500 ms, ruim é acima de 500 ms.
web.dev, documentação do INPO ponto-chave para o dono do site entender: o INP não mede a velocidade de carregamento. Ele mede quanto tempo passa entre um toque e a resposta visível na tela. Uma página pode abrir em um segundo e ainda assim ser "ineficaz" se, depois de aberta, estiver ocupada consigo mesma e não conseguir responder a um dedo.
E o segundo ponto importante: esta é uma métrica de campo. O Google a coleta de visitantes reais, não de um teste de laboratório. Por isso o relatório é atualizado com atraso e em uma janela móvel: não haverá verde instantâneo depois de uma correção.
Por que o mobile está vermelho e o desktop está verde
A resposta é sem graça e explica toda a diferença: o processador de um celular é de quatro a oito vezes mais lento que o de um desktop. O mesmo trecho de trabalho que leva 60 ms em um notebook e passa despercebido se estica para 300–500 ms em um celular, e a pessoa já vê o botão "travando". O layout não tem nada a ver com isso: o código é idêntico, só muda a velocidade de execução.
A primeira hipótese estava errada
A nossa página inicial tem uma animação de fundo, e a suspeita recaiu sobre ela imediatamente, como acontecerá com a maioria dos donos: "algo no site está se mexendo, então é isso que está deixando lento." Em vez de desativá-la e torcer, medimos três variantes da mesma tela: como está, com a animação desligada e com as tags de terceiros bloqueadas.
O que medimos não foi uma sensação, e sim uma grandeza específica: o tempo de bloqueio da thread principal, a soma de quanto as tarefas longas excedem 50 ms. Enquanto uma tarefa assim é executada, o navegador não consegue responder a um toque, e é exatamente disso que o INP é feito.
O resultado resolveu a questão. Desligar a animação não adiantou nada: 1840 ms contra 1782 ms como está, uma diferença dentro do ruído e, formalmente, até pior. Já o bloqueio das tags de terceiros reduziu o tempo de bloqueio de 1782 para 378 ms. 79% do tempo em que a página não conseguia responder ao toque não foi criado nem pelo nosso código, nem pela animação.
O verdadeiro culpado
Havia quatro tags no <head>, todas as quatro do tipo padrão que o proprietário instala e esquece: um contador de analytics, uma tag de plataforma de anúncios e dois pixels de redes sociais. Todas com o atributo async, todas "não bloqueantes". Cerca de 600 KB de JavaScript de terceiros no total.
Então veio o que torna esta seção digna de leitura. Uma biblioteca de contador de 189 KB foi baixada e executada duas vezes.
O motivo é banal. Temos dois identificadores: o de analytics e o de publicidade. Para cada um, a plataforma gera um snippet pronto com a sua própria linha de carregamento, e o proprietário cola os dois obedientemente. Mas a biblioteca contida neles é uma só: ela atende a todos os identificadores por meio de chamadas de configuração separadas. A segunda cópia não acrescenta nada: ela é apenas baixada de novo, analisada de novo e executada de novo no mesmo processador móvel lento.
Se você tem analytics e uma conta de anúncios da mesma plataforma, há uma boa chance de ter o mesmo cenário. Verificar leva um minuto: o método está no passo 3 abaixo.
Por que o "async" não salva você
Este é o segundo ponto em que a intuição engana. O atributo async significa: "não interrompa a análise do HTML, baixe em paralelo." Ele cumpre honestamente o seu papel: a página é renderizada sem esperar pela tag.
Mas, depois que o arquivo é baixado, ele ainda precisa ser executado, e é executado na mesma thread principal única que responde aos toques. O async remove o bloqueio de parsing, mas não a ocupação da thread, e o INP mede exatamente isso. Daí a situação familiar: a página apareceu rápido, todo contador é "assíncrono" e a métrica está vermelha.
Mais uma armadilha: só adiar não muda nada
A correção óbvia é adiar as tags até o navegador ficar livre. Foi o que fizemos. E medimos.
O tempo de bloqueio só com o adiamento foi de 2101 ms, contra 2026 ms antes, ou seja, um pouco pior. A lógica é simples: adiar move o trabalho no tempo, não o elimina. O trabalho não foi a lugar nenhum, apenas roda depois, às vezes justamente quando a pessoa já começou a tocar na tela.
O que funcionou foi outra coisa: remover a segunda cópia da biblioteca. Depois disso, o tempo de bloqueio caiu para 1775 ms, e todo o resto veio em seguida: a primeira renderização foi de 1128 para 824 ms, e a resposta do servidor, de 669 para 335 ms.
O que fazer no seu site: seis passos
Abaixo está uma ordem em que cada passo faz sentido depois do anterior. Cada um vem com uma verificação que mostra que você o concluiu.
Confirme que o problema é seu
Abra a seção Core Web Vitals no Search Console e veja a aba mobile separada da aba desktop. Separada é o ponto: "celular vermelho, desktop verde" é a forma mais comum desse problema, e olhar só o resumo facilita não perceber.
Se a aba mobile estiver verde, pode parar de ler: você não tem esse problema.
Meça em vez de adivinhar
O principal erro nesta etapa é começar a desligar tudo o que parece pesado. Quase desligamos uma animação que não tinha nada a ver com o problema. Meça três variações da mesma página: como está, sem o suspeito e sem tags de terceiros.
O jeito mais acessível é o Chrome DevTools: aba Performance, CPU throttling em 4× com emulação de dispositivo móvel, grave de 10 a 15 segundos da vida da página e observe as long tasks. Elas ficam destacadas, e cada uma mostra qual arquivo a gerou.
Verifique se alguma biblioteca é carregada duas vezes
Este é o ganho mais barato da lista. Abra a aba Network no DevTools, filtre por js e percorra a lista: o mesmo nome de arquivo aparece duas vezes, com parâmetros diferentes no endereço?
O caso típico é um contador de análise e uma tag de anúncios da mesma plataforma: snippets diferentes, um único arquivo. Mantenha uma só linha de carregamento e configure o segundo identificador como uma chamada de configuração separada. Nada se perde: a biblioteca atende aos dois.
<!-- before: two snippets, the same library twice -->
<script async src="…/tag.js?id=ID-1"></script>
<script async src="…/tag.js?id=ID-2"></script>
<!-- after: one library, as many identifiers as you need -->
<script async src="…/tag.js?id=ID-1"></script>
<script>
config('ID-1');
config('ID-2');
</script>
Adie as tags sem perder nenhum evento
Só depois da etapa 3, porque o adiamento sozinho não ajuda, como medimos. Em combinação, porém, ele libera os primeiros segundos críticos.
A ideia: tire os arquivos externos do <head> e carregue-os no primeiro de três eventos: a thread principal ficar ociosa, um timeout de 3 segundos ou o primeiro toque na tela. O toque é obrigatório nessa lista: se a pessoa já está interagindo com a página, a tag é necessária imediatamente, senão você perde justamente a sessão ativa.
Os eventos não se perdem no processo, e esse é o detalhe-chave. Pequenas funções stub ficam no <head> e enfileiram cada chamada; quando a biblioteca finalmente carrega, ela reproduz a fila completa. É assim que esses snippets foram projetados: a fila é prevista pelos próprios autores.
Meça de novo e não espere o verde instantâneo
Após o lançamento, repita a medição da etapa 2: você deve ver o tempo de bloqueio cair. O relatório do Search Console, porém, não ficará verde de imediato: ele é baseado em dados de visitantes reais em uma janela móvel e é atualizado com atraso de semanas.
Isso é normal e não é motivo para reverter a correção nem para empilhar uma segunda por cima. A medição de laboratório diz que melhorou, então os dados de campo vão confirmar depois.
Se não ajudou: a reserva
Com as tags de terceiros em ordem e a métrica ainda fora do ideal, os próximos passos, em ordem decrescente de retorno: contadores redundantes que duplicam a finalidade uns dos outros; CSS não utilizado (na nossa página inicial, 92% das regras nunca são aplicadas); cache de HTML, se a página é servida sem nenhum cache.
À parte, vale se perguntar com honestidade se você precisa de todos os contadores que conectou. Cada um é código de outra pessoa rodando no celular do seu visitante enquanto ele espera um toque ser registrado.
O que não fazer
Resumindo
"Ineficaz no mobile enquanto o desktop está verde" quase sempre significa uma coisa: a página está ocupada executando o código de outra pessoa no processador lento de um celular. No nosso caso, as tags de terceiros responderam por 79% do tempo de bloqueio, e o detalhe pequeno mais caro foi uma segunda cópia da mesma biblioteca de 189 KB, carregada simplesmente porque o snippet é copiado uma vez por conta.
Se você fizer só uma coisa agora: abra a aba Network no seu próprio site e veja se algum arquivo de contador está sendo baixado duas vezes. É uma verificação de um minuto e é grátis.
O rastreamento aponta páginas pesadas, scripts bloqueantes e os demais achados técnicos, divididos por gravidade.
Perguntas frequentes
O que é INP, em palavras simples?
É o tempo entre tocar na tela e o momento em que a página responde visivelmente. O Google considera 200 ms ou menos como bom e mais de 500 ms como ruim. A métrica avalia a capacidade de resposta, não a velocidade de carregamento: uma página pode abrir rápido e ainda assim demorar para responder a um toque.
Por que um site é ineficaz no mobile, mas eficaz no desktop?
Porque o processador de um celular é de quatro a oito vezes mais lento que o de um desktop. O mesmo script que roda sem ser notado em 60 ms no computador chega a 300–500 ms no celular, e a pessoa percebe o atraso. O código é idêntico: só muda a velocidade de execução.
É verdade que o analytics deixa o site lento?
Na nossa medição, as tags de terceiros responderam por 79% do tempo de bloqueio da thread principal: 1782 ms com elas contra 378 ms sem elas. Isso não é motivo para remover o analytics por completo, mas é motivo para verificar quantas tags você tem, se elas se duplicam e quando exatamente são carregadas.
O async ajuda em um script de analytics?
Em parte. O atributo async elimina o bloqueio do parsing do HTML, então a página é renderizada mais cedo. Mas o arquivo baixado ainda é executado na thread principal, e o INP mede o quanto essa thread está ocupada. Um script async pode prejudicar a métrica tanto quanto um script comum.
É possível adiar contadores sem perder conversões?
Sim, se você deixar no head funções stub que enfileiram as chamadas até a biblioteca carregar: é assim que esses snippets foram projetados. Inclua o primeiro toque entre os eventos que disparam o carregamento, caso contrário você pode perder uma sessão ativa. Depois da publicação, confirme que os eventos estão chegando.
Quanto tempo leva para o relatório do Search Console ficar verde após a correção?
Não é imediato. A métrica é coletada de visitantes reais em uma janela móvel e é atualizada com um atraso de semanas. Confie na sua própria medição de laboratório: se o tempo de bloqueio caiu, os dados de campo vão confirmar isso mais tarde.
Fontes
Medição própria da PromoPilot, 28 de agosto de 2026: emulação do Pixel 5 com a CPU limitada em 4×, observação de tarefas longas e da latência de toque no site em produção.
web.dev, documentação do INP: a definição, os limites de bom / precisa melhorar / ruim e a natureza de campo da medição.
Google Search Console, relatório Core Web Vitals: abas separadas para dispositivos móveis e desktop.
