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

A Interaction to Next Paint é a Core Web Vital mais difícil para agentes de IA. Ela não pode ser simulada. 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 vivencia 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 a rapidez com que seu site responde às interações do usuário: cliques, toques, pressionamentos 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 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 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 disparado 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 a execução de grandes pacotes JavaScript, a inicialização de scripts de análise ou a hidratação de frameworks. No estado completo (página totalmente carregada), a culpa é de temporizadores em segundo plano, scripts de terceiros consultando atualizações ou atividade de service workers.

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

Presentation: O navegador demora muito para pintar depois que o manipulador termina. Árvores DOM grandes (milhares de nós que precisam de recálculo de estilo), falta de contenção CSS ou operações de pintura custosas acionadas pelas alterações de DOM do 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: o 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 para você descobrir qual dos seus 30 scripts o causou.

O agente abre o arquivo, lê o código e escreve a correção: adie-o, divida-o em tarefas menores ou remova-o se ninguém precisar dele.

Carregando 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 da página se tornar interativa. A correção está no adiamento de scripts: adie scripts não críticos, divida o código (code-split), reduza o JavaScript que bloqueia o analisador.

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, análises 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 mesmo de olhar para os scripts.

Raciocínio proporcional para INP

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

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

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

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

Correções típicas por fase

Input Delay durante o carregamento: Adie scripts não críticos. Remova o JavaScript não utilizado. Divida o código (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 o 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 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 alterações do manipulador. Use a contenção CSS para isolar a repintura em uma área menor.

Verificando com dados de campo

As 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 focou no INP do estado de carregamento, confirme se os números do estado de carregamento melhoraram sem regredir os números do estado completo. Os dados de campo fornecem essa granularidade. Os dados de laboratório, não.