INP alto? Como encontrar o clique lento sem sacrificar o design
Aprenda a localizar interações lentas em dados reais, separar as causas do atraso e melhorar a resposta da interface sem perder a identidade visual.

O site abre rápido, mas o menu demora a reagir ao toque. Ou a pessoa clica em “Adicionar ao carrinho” e, por um instante, não sabe se aconteceu alguma coisa. Esse intervalo é uma falha de experiência que uma fotografia bonita não compensa. Interaction to Next Paint, ou INP, ajuda a localizar a lentidão percebida durante cliques, toques e uso do teclado.
O objetivo não é remover animações nem simplificar a interface até ela perder identidade. É descobrir qual interação atrasa, o que ocupa o navegador naquele momento e como devolver uma resposta visual sem espera desnecessária.
Entenda o que o número realmente representa
Segundo a definição do web.dev, INP observa interações ao longo da visita e resume a latência até o próximo quadro visual. O limiar considerado bom é de 200 milissegundos ou menos no percentil 75 das visitas reais, analisando celular e computador separadamente. Entre mais de 200 e 500 milissegundos há espaço para melhorar; acima de 500, a resposta é considerada ruim.
INP não mede quanto tempo uma requisição de rede demora para terminar, nem a velocidade de carregamento inteira da página. Um botão pode mostrar imediatamente que está processando e concluir a operação mais tarde. Essa resposta inicial já melhora a compreensão do usuário. Se ninguém interagir com a página, pode não haver valor de INP para aquela visita.
Não confunda também as três Core Web Vitals: LCP olha o carregamento do conteúdo principal, INP a resposta às interações e CLS a estabilidade visual. O resumo do Google Search Central recomenda acompanhar as três para a experiência real.
Procure a interação antes de mexer no código
Abra o relatório de Core Web Vitals no Search Console e o PageSpeed Insights para encontrar grupos de URLs que precisam de atenção. Esses dados de campo mostram o que visitantes reais experimentaram, mas nem sempre identificam qual botão causou a demora. O guia de otimização do INP recomenda começar por dados de campo e, quando possível, complementá-los com monitoramento de usuários reais que indique a interação responsável.
Escolha um fluxo importante e reproduza-o em um aparelho comum: abrir o menu no celular, enviar o formulário de orçamento ou acrescentar um produto ao carrinho. Teste enquanto a página ainda carrega e depois de pronta. Anote o controle usado, o instante em que o toque ocorreu e quando apareceu a primeira mudança visível. Esse roteiro é mais informativo que rodar uma análise de carregamento sem clicar em nada.
Se a medição local parece boa e a de campo ruim, compare dispositivos, conexão, scripts de terceiros e o percurso feito pela pessoa. Uma ferramenta de laboratório só observa as ações executadas durante o teste; ela não reproduz automaticamente toda a diversidade de visitas. O material técnico sobre INP alerta para essa diferença.
Divida a espera em três partes
O atraso de entrada acontece antes de o navegador começar a tratar o gesto: outra tarefa pode estar ocupando a thread principal. A duração de processamento é o trabalho dos manipuladores do evento. O atraso de apresentação ocorre depois, até o próximo quadro aparecer na tela. Essa divisão, descrita no roteiro do web.dev, evita que a equipe otimize a etapa errada.
Se o atraso vem antes do evento, investigue tarefas longas de JavaScript e scripts carregados no mesmo momento. Se vem do processamento, examine cálculos, atualização de muitos componentes e operações síncronas disparadas por um clique. Se vem da apresentação, observe mudanças extensas no layout ou no DOM. Faça uma alteração por vez e confirme no mesmo fluxo que mostrou o problema.

Preserve o desenho, alivie o trabalho
Uma interface editorial pode continuar rica sem fazer tudo no instante do clique. O menu precisa abrir e comunicar estado; análises secundárias podem esperar. Um formulário pode mostrar envio em andamento antes da resposta do servidor. Um filtro de catálogo pode atualizar o controle selecionado e executar a atualização pesada em etapas. A decisão deve partir do comportamento observado e de requisitos de acessibilidade, não de uma regra genérica para cortar efeitos visuais.
Revise scripts que não servem à tarefa principal, componentes que recalculam mais do que precisam e elementos visuais que provocam reposicionamento custoso. O guia sobre otimização de interações recomenda reduzir atraso de entrada, processamento e apresentação conforme o diagnóstico. Para uma base de navegação e conteúdo legível no celular, veja também site responsivo e sua relação com vendas e SEO.
Verifique o efeito na experiência e no negócio
Guarde a medição anterior, o URL, o aparelho, o fluxo testado e a data da mudança. Repita a sequência após o ajuste e acompanhe a evolução dos dados reais à medida que novas visitas entram no relatório. Observe junto sinais de uso, como conclusão de formulário ou avanço no carrinho, sem atribuir toda variação ao INP.
Uma landing page com resposta rápida ainda precisa de oferta clara e conteúdo confiável. O Google lembra que uma boa pontuação de Core Web Vitals não garante posições no topo. Ela ajuda a construir uma página agradável, mas não substitui relevância. Se o diagnóstico envolver várias rotas e componentes, os serviços de performance e SEO podem organizar uma revisão por impacto.
O melhor primeiro passo é simples: encontre o clique que mais importa ao visitante e meça sua resposta. Corrigir esse momento mantém a elegância do site e torna a interface mais confiável para quem está tentando agir.
Sobre o autor
Tiago F SantiagoComentários
Ainda sem comentários
Compartilhe uma dúvida ou experiência relacionada ao artigo.


