Mobile e performance: INP e Core Web Vitals

O Lighthouse do seu notebook marca 98 de performance. O Search Console reprova a mesma URL em Core Web Vitals. As duas medições estão corretas, e a contradição entre elas é a fonte mais comum de decisão errada nesta área.

A diferença é o denominador. O Lighthouse simula uma carga, no seu aparelho, na sua rede. O Search Console reporta o que aconteceu com visitantes reais, no aparelho e na rede que eles têm. Times que confundem os dois passam meses otimizando um número que o Google não usa para avaliar a página.

A relação entre lentidão e receita é medida há quase vinte anos. Greg Linden, engenheiro que trabalhou na Amazon nos primeiros anos do site, relatou que cada 100 milissegundos a mais de latência custavam por volta de 1% das vendas. O experimento é antigo e o resultado foi confirmado em espírito por outras grandes operações desde então, o que o tornou uma das referências mais repetidas da área. Guarde a ordem de grandeza, não o decimal: em uma operação de porte, frações de segundo movem a linha de receita.

A troca do FID pelo INP mudou o que está sendo cobrado. O FID olhava apenas o atraso até o navegador começar a processar a primeira interação, e ignorava o tempo até a resposta aparecer na tela. Uma página podia reagir rápido ao primeiro toque, travar em todas as interações seguintes e manter nota boa.

O INP olha a latência ao longo de toda a visita e considera o caminho completo até a atualização visual. Isso aproxima a métrica da experiência que faz alguém desistir, e move o alvo do trabalho de engenharia: não basta liberar a thread principal para o primeiro toque, é preciso que cada interação renda pintura rápida.

O CLS merece atenção específica de quem faz experimentação, e aqui o curso precisa apontar uma ironia que quase nenhum material comenta. Teste client-side injeta a variante depois que o HTML já renderizou, e esse rearranjo conta como deslocamento de layout. Você degrada a métrica exatamente nas páginas que está tentando melhorar, e o efeito aparece no CrUX antes de aparecer na sua consciência.

Quem opera aplicação de página única convive com um ponto cego que distorce toda a leitura de performance. As Core Web Vitals são atribuídas ao carregamento inicial: a primeira rota responde por LCP, CLS e boa parte do INP, e as transições seguintes, que no uso real concentram a maior parte da navegação, não geram medição própria. A operação exibe número confortável porque mediu apenas o primeiro passo do usuário, e o restante da sessão fica sem registro.

A Soft Navigations API trata desse caso ao permitir que o navegador reconheça a transição de rota feita em JavaScript como navegação e reinicie a atribuição das métricas a cada uma. Ela passou a estar disponível sem flag no Chrome 151, anunciada em 8 de julho de 2026, e já dá para instrumentá-la na sua própria coleta de campo.

Medir sem saber corrigir transforma o relatório de performance numa fonte de ansiedade trimestral. As técnicas abaixo cobrem a maior parte dos casos reais e são de escopo pequeno o suficiente para caber numa sprint, o que importa porque performance perde para funcionalidade toda vez que o esforço parece grande.

Uma vitrine com milhares de SKUs muda a natureza do problema. A imagem de produto passa a ser o elemento do LCP em praticamente toda página de listagem e de categoria, e decidir formato, dimensão e prioridade de carregamento deixa de ser ajuste de uma página para virar padrão de template, com efeito sobre o catálogo inteiro de uma vez. As metas de Core Web Vitals aplicadas a catálogo grande, com o peso que imagem de produto tem no LCP, estão em SEO Técnico para E-commerce.

O estudo mais citado sobre velocidade e receita é o "Milliseconds Make Millions", conduzido por Deloitte Digital e fifty-five por encomenda do Google, com dados de 2019 e 2020, 37 marcas e mais de 30 milhões de sessões mobile. O ganho de 0,1 segundo apareceu associado a 8,4% de aumento em conversão no varejo e a 10,1% em conclusão de reserva no setor de viagens.

A ressalva metodológica é obrigatória e anda junto do número. O desenho é correlacional: o estudo observou sites mais rápidos e sites mais lentos, sem manipular a velocidade em experimento controlado. Sites rápidos costumam ter times de engenharia melhores, infraestrutura melhor e produto melhor, e essas variáveis empurram a conversão sozinhas. Use o estudo para justificar investimento em performance, e prove o efeito na sua operação com um teste controlado antes de prometer 8,4% a alguém.

Sobre a participação do mobile no tráfego brasileiro, os percentuais que circulam divergem bastante entre fontes, e cada agregador usa um método e um recorte diferente. A afirmação segura é que a maior parte do tráfego brasileiro chega por celular.

O número que decide o seu roadmap está no seu analytics, não em post de blog. Abra o relatório de dispositivo com recorte por página e por etapa do funil, porque a proporção muda muito entre a home e o checkout, e é essa diferença que indica onde o mobile está falhando. Uma loja com 78% de sessões mobile e 40% da receita mobile tem um problema localizado que nenhuma média nacional aponta.