Corrigir INP com um Agente de IA: A Métrica que as Ferramentas de Lab 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 no ciclo de vida da página ela acontece. É 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 o quão rápido seu site responde às interações do usuário: cliques, toques, pressionamento de teclas. Ele escolhe a única pior interação de toda a sessão. A palavra-chave é real. Um usuário clica em um menu suspenso de filtro na sua página de produto enquanto um script de analytics de terceiros está sendo executado. Esse atraso de 380ms se torna o INP para aquela sessão.

Nenhuma ferramenta de lab 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 temporizador em segundo plano for acionado 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 (loading), as causas comuns são grandes pacotes JavaScript sendo executados, scripts de analytics sendo inicializados ou hidratação de framework. No estado completo (complete - página totalmente carregada), a culpa é de temporizadores em segundo plano, scripts de terceiros consultando atualizações ou atividade de service worker.

Processing: O próprio manipulador de eventos (event handler) é muito lento. Layout thrashing (ler DOM, escrever no 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 fazer yield.

Presentation: O navegador demora muito para pintar (paint) depois que o manipulador termina. Grandes árvores DOM (milhares de nós que precisam de recálculo de estilo), falta de contenção CSS ou operações de pintura custosas acionadas pelas mudanças no DOM feitas pelo manipulador.

Qual script está bloqueando sua página

O CoreDash captura a atribuição de Long Animation Frames (LoAF) de sessões de usuários reais. É isso que permite que o agente realmente corrija 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ê recebe "este arquivo, esta função, esta duração". Compare isso com o Lighthouse, que diz que o Total Blocking Time é de 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: faça o defer disso, quebre-o em tarefas menores ou remova-o se ninguém precisar dele.

Loading vs loaded: dois problemas diferentes

Se a interação aconteceu durante o estado de loading ou complete, isso muda a correção completamente.

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

Se o INP for ruim no estado complete, 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 custosas em um temporizador.

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

Raciocínio proporcional para o INP

O INP é de 350ms na página de checkout. A divisão de fases dos dados de campo:

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

Presentation é o gargalo. 200ms não soa alarmante isoladamente. Mas é 57% do total. Corrigir Presentation move o ponteiro mais do que otimizar Input Delay ou Processing combinados.

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

Correções típicas por fase

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

Input Delay no estado complete: Audite scripts de terceiros rodando após o carregamento da página. Use os dados LOAF do CoreDash para encontrar o script ofensor. Faça defer 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 layouts forçados (ler propriedades de layout imediatamente após escrever no DOM).

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

Verificando com dados de campo

As melhorias de INP aparecem no CoreDash dentro de 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 focou no INP do estado de loading, confirme que os números do estado de loading melhoraram sem regredir os números do estado complete. Dados de campo fornecem essa granularidade. Dados de lab não.