O que o INP no mobile mede de fato e por que o PageSpeed engana
O monitoramento de Core Web Vitals para e-commerce no mobile exige atenção ao abismo que existe entre a nota exibida nas ferramentas de teste sintético e a experiência real da sua base de clientes. Quando a equipe técnica envia um relatório do PageSpeed Insights mostrando nota 85 para a página de produto, a tentação é dar a otimização por encerrada. O problema é que o PageSpeed roda uma simulação em ambiente controlado, com conexões de baixa variação de latência e um perfil de hardware padronizado.
A métrica real que define a experiência do usuário vem do Chrome User Experience Report (CrUX), que coleta dados contínuos de navegadores de usuários reais navegando em condições do mundo físico. É nessa camada que o Interaction to Next Paint (INP) expõe as falhas da operação.
O INP avalia o tempo decorrido entre o toque do cliente na tela — ao selecionar uma variação de cor, abrir a tabela de medidas ou clicar no botão de compra — e a resposta visual confirmada na interface. Enquanto o antigo First Input Delay (FID) mediante apenas a latência da primeira interação, o INP registra todas as interações da sessão e reporta a pior latência observada (ignorando pequenos desvios pontuais em sessões muito longas).
No uso cotidiano sob redes 4G no Brasil, os aparelhos móveis enfrentam oscilações de sinal, perda de pacotes e limitação de processamento nos chips de entrada e intermediários.
Um teste sintético feito no escritório sob conexão Wi-Fi corporativa processa scripts de JavaScript em milissegundos. Na rua, sob uma conexão móvel instável, esse mesmo script trava a thread principal do processador do smartphone por centenas de milissegundos enquanto o cliente tenta clicar no checkout.
A métrica isolada que leva a decisões erradas na loja própria
Olhar para relatórios consolidados da loja sem separar o tráfego por dispositivo é um erro operacional clássico. O tráfego de computador, beneficiado por processadores mais potentes e conexões fixas, puxa as métricas médias globais para cima e mascaram falhas graves na navegação celular.
Navegação Desktop: Conexão Estável + Alto Processamento CPU = Baixo Tempo de Bloqueio (TBT)
Navegação Mobile: Oscilação 4G + Processador Limitado + Scripts em Fila = INP Elevado (> 200ms)
Uma página de produto pode apresentar um Largest Contentful Paint (LCP) aceitável de 2,2 segundos no laboratório, mas entregar um INP de 450 milissegundos para 25% dos usuários em dispositivos móveis. Para a operação, essa métrica oculta significa um travamento perceptível de quase meio segundo a cada clique no botão de alteração de tamanho ou no cálculo de frete.
Essa latência invisível nos testes laboratoriais é causada, na maioria das vezes, pela execução desordenada de scripts de terceiros.
Píxeis de rastreamento de redes sociais, tags de remarketing, widgets de chat ao vivo, buscadores inteligentes e aplicativos de avaliações disputam a mesma thread principal do processador do celular. Quando o cliente toca na tela para fechar um pop-up ou selecionar uma variação, o evento de toque entra na fila atrás da execução pesada de scripts de rastreamento.
O resultado comercial é mensurável: a cada atraso no feedback visual de uma ação de compra, a taxa de rejeição da página aumenta e a conversão do mobile cai, sem que nenhum erro seja registrado nos logs do servidor.
O recorte de dados que revela gargalos de renderização e scripts
Para localizar o gargalo técnico onde a conversão é perdida, a análise precisa ser filtrada diretamente no Google Search Console, acessando a aba "Core Web Vitals" e isolando o relatório de dispositivos móveis por tipo de URL.
As páginas de um e-commerce têm comportamentos de carga distintos:
- Página Inicial (Home): Ponderada por múltiplos banners, seletores de ofertas e scripts de vitrine dinâmica.
- Página de Categoria (PLP): Sobrecarregada por requisições de filtros, paginação assíncrona e lazy loading de imagens.
- Página de Produto (PDP): Crítica para a conversão; concentra scripts de precificação, cálculo de frete, estoque por variação e pixels de conversão.
- Carrinho e Checkout: Alta exigência de processamento local para cálculo de descontos, validações de formulário e chamadas de gateway de pagamento.
A análise isolada das URLs de produto revela o impacto direto das tags no tempo de resposta. Quando uma PDP acumula mais de 15 tags de mídia e rastreamento rodando de forma síncrona, a thread principal do processador mobile registra tarefas longas (Long Tasks), definidas como qualquer execução de JavaScript superior a 50 milissegundos.
Durante a execução de uma tarefa longa, o navegador não consegue responder a nenhum toque na tela. Se o usuário clica em "Adicionar ao Carrinho" enquanto uma tag de analytics está processando dados em background, a tela permanece congelada.
O cliente supõe que a loja travou, clica repetidas vezes no botão — o que gera requisições duplicadas — ou abandona a navegação antes que o item seja adicionado ao carrinho.
Painel mínimo de acompanhamento semanal para a operação
A gestão técnica da loja deve acompanhar os indicadores de campo extraídos da API do CrUX ou do relatório do Google Search Console.
A medição oficial considera o percentil 75 (P75) dos acessos dos últimos 28 dias. Isso significa que, para uma página ser considerada rápida, 75% das visitas reais precisam registrar métricas dentro da faixa classificada como "Boa".
A tabela abaixo estabelece as métricas oficiais de Core Web Vitals e os limites aceitáveis para operações de e-commerce no mobile:
| Métrica | Sigla | Faixa Ideal (Bom) | Precisa de Melhoria | Ruim | O que mede na operação mobile |
|---|---|---|---|---|---|
| Interaction to Next Paint | INP | ≤ 200 ms | 201 ms a 500 ms | > 500 ms | Atraso na resposta visual a cliques e toques no celular |
| Largest Contentful Paint | LCP | ≤ 2,5 s | 2,6 s a 4,0 s | > 4,0 s | Tempo de carregamento da imagem principal do produto |
| Cumulative Layout Shift | CLS | ≤ 0,10 | 0,11 a 0,25 | > 0,25 | Deslocamentos inesperados de botões durante o carregamento |
| Time to First Byte | TTFB | ≤ 0,8 s | 0,9 s a 1,8 s | > 1,8 s | Tempo de resposta inicial do servidor da plataforma |
| Total Blocking Time | TBT | ≤ 200 ms | 201 ms a 600 ms | > 600 ms | Indicador laboratorial de bloqueio da thread principal |
Se o P75 do INP mobile ultrapassa 200 milissegundos, 25% do seu tráfego celular está enfrentando uma interface lenta e travada. Esse número é o sinal de alerta para auditoria técnica na execução de scripts.
Auditoria item a item de uma página de produto no mobile
A correção dos problemas de desempenho na página de produto precisa seguir uma ordem estrita de prioridades técnicas para liberar a thread principal do celular e garantir respostas visuais imediatas aos toques do usuário.
1. Otimização do LCP e carregamento de imagem
- Identifique a imagem principal da galeria do produto (elemento LCP na maioria das lojas).
- Remova o atributo
loading="lazy"da primeira imagem da galeria. Imagens que aparecem na dobra superior nunca devem ser carregadas de forma diferida. - Adicione a tag
<link rel="preload" as="image">para a imagem principal no cabeçalho do código HTML. - Aplique a propriedade
fetchpriority="high"diretamente na tag<img>do produto. - Sirva imagens em formatos de última geração (WebP ou AVIF) dimensionadas para telas móbile (largura máxima de 800px no arquivo de origem).
2. Eliminação de gargalos de INP e processamento de scripts
- Mapeie todas as tags ativas via Google Tag Manager ou pela plataforma de e-commerce.
- Adie a execução de scripts não essenciais (como chats ao vivo, widgets de avaliação e pixels secundários) usando estratégias de atraso de carga (delay script) até a primeira interação do usuário ou após o disparo do evento
DOMContentLoaded. - Configure o carregamento assíncrono (
async) ou diferido (defer) para todos os scripts de terceiros mantidos no topo da página. - Mova o processamento de rastreamento pesados para integrações Server-Side (como GTM Server-Side ou Conversion API do Meta), retirando do processador do celular o trabalho de disparar múltiplas requisições HTTP para redes de anúncios.
- Reduza o tamanho total da árvore DOM da página de produto para menos de 1.500 nós HTML, evitando estruturas aninhadas em excesso geradas por construtores visuais de temas.
3. Zerar o deslocamento de layout (CLS) na área de conversão
- Defina atributos explícitos de altura e largura (
widtheheight) ou especifique a propriedade CSSaspect-ratioem todas as imagens e contêineres de banners. - Reserve espaço fixo em pixels para blocos dinâmicos que carregam com atraso, como seletores de variações de cor/tamanho, calculadoras de frete e avisos de frete grátis.
- Evite injetar pop-ups, barras fixas de aviso ou banners promocionais no topo da página após o início da renderização, pois esses elementos empurram o botão de compra para baixo enquanto o usuário tenta tocar na tela.
Perguntas frequentes
Por que o Google Analytics mostra páginas rápidas enquanto o Search Console aponta alertas no mobile?
O Google Analytics mede o tempo total de carregamento da página por meio de APIs do navegador, enquanto o Search Console exibe dados reais do CrUX baseados em percentis (P75) específicos de experiência do usuário. Se uma fatia relevante dos seus clientes navega em celulares intermediários ou sob redes 4G instáveis, o Search Console capturará o travamento real do INP e do LCP, mesmo que a média simples calculada no Analytics pareça saudável.
Usar um gerenciador de tags como o Google Tag Manager resolve o problema de latência do INP?
O Google Tag Manager apenas organiza a inserção dos scripts na página, mas não impede que os códigos disparados por ele consumam o processamento do celular. Se o GTM injetar dez tags pesadas de terceiros simultaneamente na dobra inicial, a thread principal do navegador móbile continuará sendo bloqueada da mesma forma, elevando o tempo de resposta do INP.
A otimização de imagens de produto é suficiente para melhorar a nota de INP?
A otimização de imagens afeta diretamente a métrica de LCP (carregamento visual), mas tem impacto mínimo sobre o INP. O INP é afetado quase exclusivamente pelo tempo de execução de scripts JavaScript no navegador do cliente; portanto, reduzir o peso de imagens melhora a velocidade visual de abertura da página, mas não corrige travamentos ao clicar em botões, abas ou seletores de variações.