Corrija o INP com um agente de IA: a métrica que as ferramentas de laboratório não conseguem medir

O Interaction to Next Paint é a Core Web Vital mais difícil para agentes de IA. Não pode ser simulado. O Lighthouse não tem pontuação de INP. Um agente de IA sem dados reais de utilizadores não consegue dizer que interação é lenta, quem a experiencia nem em que momento do ciclo de vida da página acontece. É assim que se corrige o INP quando tem field data.

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

Porque é que o INP é diferente para agentes de IA

O INP mede a rapidez com que o site responde às interações do utilizador: cliques, toques, teclas premidas. Seleciona a pior interação de toda a sessão. A palavra-chave é real. Um utilizador clica num dropdown de filtros na página de produto enquanto um script de analytics de terceiros está a executar. Esse atraso de 380ms torna-se o INP dessa sessão.

Nenhuma ferramenta de laboratório consegue reproduzir isto. O Lighthouse usa o Total Blocking Time como proxy, mas o TBT mede o bloqueio da main thread 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 pode continuar a ter um INP terrível se um timer em segundo plano disparar no momento errado. Um agente sem field data está cego a isto. Otimiza o TBT e declara vitória enquanto utilizadores reais esperam 400ms para que os cliques sejam registados.

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

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

Input Delay: A main thread estava ocupada quando o utilizador interagiu. No estado loading, as causas habituais são bundles grandes de JavaScript a executar, scripts de analytics a inicializar ou a hidratação da framework. No estado complete (página totalmente carregada), a culpa é de timers em segundo plano, scripts de terceiros a fazer polling de atualizações ou atividade do service worker.

Processing: O próprio event handler é demasiado lento. Layout thrashing (ler o DOM, escrever no DOM, ler o DOM em loop), queries síncronas ao DOM dentro do handler, re-renders pesados ou simplesmente demasiado trabalho numa única tarefa sem fazer yielding.

Presentation: O browser demora demasiado tempo a fazer o paint depois de o handler terminar. Árvores de DOM extensas (milhares de nós que precisam de recálculo de estilos), falta de CSS containment ou operações de paint pesadas desencadeadas pelas alterações do handler no DOM.

Que script está a bloquear a página

O CoreDash captura a atribuição de Long Animation Frames (LoAF) a partir de sessões de utilizadores reais. É isto que permite ao agente corrigir o INP em vez de tentar adivinhar.

O LoAF identifica o ficheiro JavaScript exato, a função e a duração. O agente não adivinha que script está a bloquear a main thread. O CoreDash diz-lhe: gtm-container.js bloqueou a main thread durante 280ms na interação com o filtro da página de checkout.

Em vez de "a página está lenta", tem "este ficheiro, esta função, esta duração". Compare com o Lighthouse, que diz que o Total Blocking Time é de 450ms e deixa-o a tentar descobrir qual dos 30 scripts foi a causa.

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

Loading vs loaded: dois problemas diferentes

Saber se a interação aconteceu no estado loading ou complete muda a correção por completo.

Se o INP for mau apenas no estado loading, o problema é a ordem de carregamento dos scripts. Demasiado JavaScript a executar antes de a página estar interativa. A correção passa pelo adiamento de scripts: adiar scripts não críticos, fazer code-split e reduzir o JavaScript parser-blocking.

Se o INP for mau no estado complete, tem um problema de JavaScript em runtime. Há algo a correr em segundo plano numa página totalmente carregada. Scripts de terceiros a fazer polling de atualizações, analytics a enviar beacons ou código próprio a executar operações pesadas num timer.

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

Raciocínio proporcional para o INP

O INP é de 350ms na página de checkout. A distribuição das fases a partir de field data:

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

A Presentation é o bottleneck. Isoladamente, 200ms não parecem alarmantes. Mas representam 57% do total. Corrigir a Presentation tem muito mais impacto do que otimizar o Input Delay ou o Processing juntos.

Sem as percentagens, um agente vai atrás do Input Delay só porque 70ms ultrapassam um determinado limiar. Mostre-lhe a distribuição e ele vai direto aos 57%. O resultado: uma única correção que faz o INP descer abaixo dos 200ms, em vez de três correções dispersas que mal mexem no valor.

Correções típicas por fase

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

Input Delay no complete: Faça uma auditoria aos scripts de terceiros que correm após o carregamento da página. Use os dados de LoAF do CoreDash para encontrar o script problemático. Adie-o para momentos de inatividade com requestIdleCallback.

Processing: Faça yield à main thread com scheduler.yield() ou setTimeout(0). Divida event handlers longos em tarefas mais pequenas. Evite forced layouts (ler propriedades de layout imediatamente a seguir a escrever no DOM).

Presentation: Use content-visibility: auto em secções grandes do DOM below the fold (compatível com todos os principais browsers desde setembro de 2025). Reduza o número de nós do DOM afetados pelas alterações do handler. Use CSS containment para isolar o repaint a uma área mais pequena.

Verificação com field data

As melhorias no INP surgem no CoreDash ao fim de um ou dois dias de tráfego real. Consulte a mesma página e segmento de dispositivos. O p75 deve descer e a distribuição das fases deve mudar.

Acompanhe também a divisão por estado de carregamento. Se a correção visava o INP no estado loading, confirme que os valores no estado loading melhoraram sem agravar os números no estado complete. A field data dá-lhe esta granularidade. A lab data não.