Corrija o INP com um Agente de IA: A Métrica que Ferramentas de Laboratório Não Conseguem Medir

Interaction to Next Paint é o Core Web Vital mais difícil para agentes de IA. Ele não pode ser simulado. O Lighthouse não tem pontuação de INP. Um agente de IA sem dados reais de usuários não consegue dizer qual interação é lenta, quem a experiencia ou quando ela acontece no ciclo de vida da página. É assim que você corrige o INP quando tem dados de campo.

Última revisão por Arjen Karel em março de 2026

Por que o INP é diferente para agentes de IA

O INP mede a rapidez com que seu site responde às interações do usuário: cliques, toques, pressionamento de teclas. Ele escolhe a pior interação única de toda a sessão. A palavra-chave é real. Um usuário clica em um menu suspenso de filtro na página do seu produto enquanto um script de análise de terceiros está em execução. Esse atraso de 380ms se torna o INP daquela sessão.

Nenhuma ferramenta de laboratório consegue reproduzir isso. O Lighthouse usa o Total Blocking Time como um proxy, mas o TBT mede o bloqueio da thread principal durante o carregamento da página. O INP mede o tempo de resposta a interações que acontecem em momentos imprevisíveis ao longo da sessão. Uma página com zero TBT ainda pode ter um INP terrível se um timer em segundo plano disparar no momento errado. Um agente sem dados de campo é cego a isso. Ele otimiza o TBT e declara vitória, enquanto usuários reais esperam 400ms para que seus cliques sejam registrados.

Três fases, três correções diferentes

O INP se divide em três fases. Cada uma significa uma correção diferente.

Input Delay: A thread principal estava ocupada quando o usuário interagiu. Durante o estado de carregamento, as causas comuns são a execução de grandes pacotes JavaScript, inicialização de scripts de análise ou hidratação de framework. No estado completo (página totalmente carregada), a culpa é de timers em segundo plano, scripts de terceiros consultando atualizações ou atividade do service worker.

Processing: O próprio manipulador de eventos é muito lento. Layout thrashing (ler DOM, escrever DOM, ler DOM em um loop), consultas síncronas ao DOM dentro do manipulador, re-renderizações custosas ou simplesmente fazer muito trabalho em uma única tarefa sem realizar yielding.

Presentation: O navegador demora muito para pintar após a conclusão do manipulador. Árvores DOM grandes (milhares de nós que precisam de recálculo de estilo), falta de contenção CSS ou operações de pintura dispendiosas acionadas pelas mudanças do manipulador no DOM.

Qual script está bloqueando sua página

O CoreDash captura a atribuição de Long Animation Frames (LoAF) a partir de sessões reais de usuários. É isso que permite ao agente realmente corrigir o INP em vez de adivinhar.

O LoAF nomeia o arquivo JavaScript exato, a função e a duração. O agente não adivinha qual script está bloqueando a thread principal. O CoreDash diz a ele: gtm-container.js bloqueou a thread principal por 280ms durante a interação no filtro da página de checkout.

Em vez de "sua página está lenta", você obtém "este arquivo, esta função, esta duração". Compare isso com o Lighthouse, que diz que o Total Blocking Time é 450ms e deixa você descobrir qual dos seus 30 scripts o causou.

O agente abre o arquivo, lê o código e escreve a correção: adiá-lo, dividi-lo em tarefas menores ou removê-lo se ninguém precisar dele.

Carregamento vs carregado: dois problemas diferentes

Se a interação aconteceu durante o estado loading ou complete muda a correção por completo.

Se o INP for ruim apenas durante o estado de carregamento, o problema é a ordem de carregamento dos scripts. Muito JavaScript sendo executado antes que a página se torne interativa. A correção está no adiamento de script: adiar scripts não críticos, fazer code-split, reduzir o JavaScript que bloqueia o parser.

Se o INP for ruim no estado completo, você tem um problema de JavaScript em tempo de execução. Algo está rodando em segundo plano em uma página totalmente carregada. Scripts de terceiros consultando atualizações, analytics enviando beacons ou seu próprio código executando operações dispendiosas em um timer.

O CoreDash rastreia o estado de carregamento da página para cada medição de INP. CWV Superpowers usa isso para descartar metade das causas antes de olhar para os scripts.

Raciocínio proporcional para INP

O INP é 350ms na página de checkout. O detalhamento das fases a partir dos dados de campo:

• Input Delay: 70ms (20%)
• Processing: 80ms (23%)
• Presentation: 200ms (57%)

O Presentation é o gargalo. 200ms não soa alarmante isoladamente. Mas representa 57% do total. Corrigir o Presentation faz mais diferença do que otimizar o Input Delay ou o Processing combinados.

Sem as porcentagens, um agente persegue o Input Delay porque 70ms excede algum limite. Mostre o detalhamento e ele vai direto para os 57%. O resultado: uma correção que reduz o INP para menos de 200ms versus três correções dispersas que mal o alteram.

Correções típicas por fase

Input Delay durante o carregamento: Adie scripts não críticos. Remova JavaScript não utilizado. Faça code-split para que apenas o código da página atual seja carregado.

Input Delay no estado completo: Audite scripts de terceiros em execução após o carregamento da página. Use os dados de LoAF do CoreDash para encontrar o script problemático. Adie-o para o tempo ocioso com requestIdleCallback.

Processing: Faça yield para a thread principal com scheduler.yield() ou setTimeout(0). Divida manipuladores de eventos longos em tarefas menores. Evite forced layouts (ler propriedades de layout imediatamente após escrever no DOM).

Presentation: Use content-visibility: auto para grandes seções do DOM abaixo da dobra (suportado em todos os principais navegadores desde setembro de 2025). Reduza o número de nós do DOM afetados pelas mudanças do manipulador. Use contenção CSS para isolar o repaint para uma área menor.

Verificando com dados de campo

Melhorias de INP aparecem no CoreDash em um ou dois dias de tráfego real. Consulte a mesma página e segmento de dispositivo. O p75 deve cair e a distribuição das fases deve mudar.

Observe também a divisão do estado de carregamento. Se a sua correção visou o INP no estado de carregamento, confirme que os números do estado de carregamento melhoraram sem regredir os números do estado completo. Dados de campo fornecem essa granularidade. Dados de laboratório não.