Um INP alto no PageSpeed Insights indica dificuldade de resposta percebida por usuários reais, mas não revela, sozinho, qual clique, toque ou tecla atrasou a interface. O diagnóstico útil começa nos dados de campo, passa pela identificação da interação responsável e só então chega ao rastreamento no Chrome DevTools. O objetivo é corrigir a etapa que mais consome tempo e voltar a medir, não perseguir uma pontuação isolada.
Entenda o INP antes de procurar o defeito
Interaction to Next Paint (INP) acompanha cliques, toques e entradas pelo teclado ao longo da visita e considera a latência da interação mais lenta, com tratamento de valores extremos quando há muitas interações. No relatório agregado de campo, a referência é o percentil 75 das visitas, analisado separadamente para dispositivos móveis e computadores. Até 200 ms é bom; acima de 200 ms e até 500 ms precisa melhorar; acima de 500 ms é ruim. O intervalo inclui a espera para processar a entrada, os manipuladores de eventos e a apresentação do próximo quadro, não a conclusão de todas as operações assíncronas posteriores. Definição oficial do INP.
Uma auditoria de carregamento pode apresentar Total Blocking Time (TBT), que ajuda a encontrar trabalho bloqueante no laboratório, mas TBT não substitui INP. Sem executar a interação problemática, um teste sintético pode não reproduzir a lentidão relatada em campo. Relação entre TBT e INP.
1. Delimite o problema com CrUX e PageSpeed
Abra o PageSpeed Insights na URL afetada e consulte primeiro os dados de usuários reais do Chrome UX Report (CrUX). Confira se o resultado é da URL ou apenas da origem, e compare celular e computador: um dado agregado do domínio não prova que aquela página específica esteja lenta. A janela de dados do PageSpeed/CrUX é móvel, de 28 dias; por isso uma correção de hoje não altera imediatamente o indicador agregado. Metodologia e ferramentas CrUX.
Registre o segmento afetado, as páginas ou modelos de página prioritários e o período observado. Se não houver amostra suficiente para a URL, use o dado de origem como sinal inicial, nunca como localização exata do problema. O número indica onde investigar, não qual função corrigir. Roteiro oficial de otimização.
2. Descubra qual interação está lenta com RUM
Implemente ou consulte monitoramento de usuários reais (RUM). A versão com atribuição da biblioteca web-vitals pode informar o elemento e tipo da interação, se ela ocorreu durante ou depois do carregamento e os tempos de input delay, processing duration e presentation delay. Dados da API Long Animation Frames (LoAF), quando disponíveis, ajudam a apontar tarefas e scripts associados. Guia de coleta e atribuição em campo.
- Agrupe registros por rota ou modelo de página, dispositivo e interação, como abrir menu, aplicar filtro ou adicionar ao carrinho.
- Compare frequência e duração das interações lentas; não investigue apenas o maior evento isolado.
- Registre a fase predominante e se o problema ocorre no carregamento ou após a página estabilizar.
- Respeite a privacidade: colete metadados técnicos necessários, sem conteúdo digitado, credenciais ou dados pessoais de formulários.
Exemplo: se o agrupamento aponta repetidamente para o botão de filtro em celulares após o carregamento, reproduza essa ação. Um INP agregado de origem, por si só, não autoriza atribuir a culpa ao filtro.
3. Reproduza a ação no Chrome DevTools
- Abra a página e a mesma rota, estado, quantidade de itens e tipo de dispositivo identificados no campo; considere extensões, scripts de terceiros e condições de rede.
- No painel Performance, observe as métricas em tempo real e a lista de interações. Execute o gesto suspeito; se ele depende do carregamento, repita enquanto a página ainda inicia.
- Grave um trace durante a ação. Use a faixa Interactions, selecione a interação lenta e confira a decomposição e o instante da ocorrência.
- Examine a faixa Main e o encadeamento de chamadas. O insight INP breakdown, quando disponível, destaca as três fases. Repita com limitação de CPU para explorar condições de aparelhos menos potentes.
- Compare o que o trace mostra com a hipótese do RUM; uma execução local rápida não invalida dados de campo de aparelhos e condições diferentes.
O DevTools marca interações acima de 200 ms na faixa Interactions. O objetivo do trace não é somente localizar uma barra comprida, mas conectá-la ao gesto e ao trabalho que impediu a próxima pintura. Referência do painel Performance; Insight INP breakdown.
4. Separe as três fases e escolha a intervenção
A interação pode ficar lenta antes, durante ou depois da execução de seus manipuladores. Use a fase dominante como hipótese técnica e confirme a causa no trace. Fases do INP.
| Fase no trace | Sinal típico | Investigação e correção possíveis |
|---|---|---|
| Input delay | O clique aguarda a thread principal. | Procure tarefas anteriores, avaliação de JavaScript, inicialização, timers ou terceiros. Reduza código inicial, adie trabalho não essencial e quebre tarefas longas. |
| Processing duration | O handler demora a terminar. | Inspecione a pilha de chamadas do evento, loops, filtros, serialização e renderização síncrona da aplicação. Reduza trabalho por evento e separe o essencial do adiável. |
| Presentation delay | O handler terminou, mas o próximo quadro demora. | Investigue recálculo de estilo, layout, pintura e DOM excessivo. Evite leituras e escritas intercaladas que forçam layout; diminua o trabalho visual da atualização. |
Não trate as fases como diagnósticos automáticos: por exemplo, um botão pode ter input delay elevado por um script que começou antes do clique, mesmo que seu próprio handler seja curto. Atribuição e trace precisam confirmar a hipótese. Leitura oficial das subpartes.
5. Corrija o fluxo, não apenas a medição
Se a thread principal está ocupada, divida tarefas longas e priorize o retorno visual. A técnica de ceder execução, como scheduler.yield() onde houver suporte e alternativa nos demais navegadores, pode abrir oportunidade para entrada e pintura entre blocos de trabalho. Não adie a mudança visual indispensável ao usuário apenas para melhorar a medição. Guia de tarefas longas.
Se o handler processa uma lista grande a cada tecla, reduza o trabalho síncrono, avalie debounce quando compatível com a interação e distribua o cálculo custoso. Se o gargalo é apresentação, simplifique alterações no DOM e o trabalho de estilo/layout. Se é um terceiro, meça seu custo e avalie carregamento e necessidade antes de removê-lo indiscriminadamente. Orientações de correção por fase.
Ofereça feedback inicial coerente para operações demoradas, como mostrar o estado do botão antes de iniciar trabalho secundário. INP mede a oportunidade de exibir o próximo quadro, não a duração total de uma requisição ao servidor. Escopo da medição.
6. Valide no laboratório e acompanhe novamente o campo
- Repita o mesmo fluxo no mesmo perfil de teste e compare a fase dominante antes e depois.
- Verifique que o resultado visual, a acessibilidade, a navegação por teclado e o comportamento funcional continuam corretos.
- Acompanhe RUM por rota, interação e dispositivo para confirmar se a melhora aparece em sessões reais e se outro gesto passou a dominar o INP.
- Observe a tendência do percentil 75 no CrUX/PageSpeed ao longo da janela móvel de 28 dias; não exija queda imediata após o deploy.
O sinal de sucesso é a redução consistente da latência da interação real sem regressão funcional. Use o PageSpeed como verificação agregada, não como substituto do diagnóstico de campo e do trace. Janela de dados CrUX.
Erros que atrasam a investigação
- Tomar o dado de origem como prova de que a URL atual é a culpada.
- Confiar somente no resultado de carregamento do Lighthouse ou confundir TBT com INP.
- Otimizar qualquer tarefa longa sem saber se ela antecede ou integra a interação problemática.
- Testar apenas em um computador rápido quando os dados ruins vêm de celulares.
- Comparar resultados de laboratório e campo sem considerar diferenças de aparelho, tráfego, interação e janela de observação.
A sequência prática é CrUX/RUM → interação → input delay, processamento ou presentation delay → trace → correção → nova medição. Ela transforma um indicador amplo em uma hipótese verificável. Fluxo recomendado pelo web.dev.
