Corrige el INP con un agente de IA: la métrica que las herramientas de laboratorio no pueden medir

Interaction to Next Paint es el Core Web Vital más difícil para los agentes de IA. No se puede simular. Lighthouse no tiene puntuación de INP. Un agente de IA sin datos de usuarios reales no puede decirte qué interacción es lenta, quién la experimenta ni en qué momento del ciclo de vida de la página ocurre. Así se corrige el INP cuando tienes field data.

Última revisión por Arjen Karel en marzo de 2026

Por qué el INP es diferente para los agentes de IA

El INP mide la rapidez con la que el sitio responde a las interacciones del usuario: clics, toques, pulsaciones de teclas. Selecciona la peor interacción de toda la sesión. La palabra clave es real. Un usuario hace clic en un desplegable de filtros de la página de producto mientras se ejecuta un script de analítica de terceros. Ese retraso de 380 ms se convierte en el INP de esa sesión.

Ninguna herramienta de laboratorio puede reproducir esto. Lighthouse usa Total Blocking Time como proxy, pero el TBT mide el bloqueo del main thread durante la carga de la página. El INP mide el tiempo de respuesta a interacciones que ocurren en momentos impredecibles a lo largo de la sesión. Una página con cero TBT puede tener un INP pésimo si un timer en segundo plano se activa en el momento equivocado. Un agente sin field data está ciego ante esto. Optimiza el TBT y canta victoria mientras los usuarios reales esperan 400 ms a que se registren sus clics.

Tres fases, tres fixes distintos

El INP se divide en tres fases. Cada una requiere un fix distinto.

Input Delay: El main thread estaba ocupado cuando el usuario interactuó. Durante el estado loading, las causas habituales son la ejecución de bundles de JavaScript grandes, la inicialización de scripts de analítica o la hidratación del framework. En el estado complete (con la página totalmente cargada), los culpables suelen ser timers en segundo plano, scripts de terceros haciendo polling para buscar actualizaciones o la actividad del service worker.

Processing: El propio event handler es demasiado lento. Layout thrashing (leer el DOM, escribir en el DOM, leer el DOM en bucle), consultas síncronas al DOM dentro del handler, re-renders costosos o simplemente hacer demasiado trabajo en una sola tarea sin yielding.

Presentation: El navegador tarda demasiado en pintar después de que termina el handler. Árboles DOM grandes (miles de nodos que necesitan recalcular estilos), falta de CSS containment u operaciones de pintura costosas provocadas por los cambios del handler en el DOM.

Qué script bloquea la página

CoreDash captura la atribución de Long Animation Frames (LoAF) de sesiones de usuarios reales. Esto es lo que permite al agente corregir el INP en lugar de adivinar.

LoAF indica el archivo JavaScript exacto, la función y la duración. El agente no tiene que adivinar qué script está bloqueando el main thread. CoreDash se lo dice: gtm-container.js bloqueó el main thread durante 280 ms en la interacción con el filtro de la página de checkout.

En lugar de "tu página es lenta", obtienes "este archivo, esta función, esta duración". Compáralo con Lighthouse, que te dice que el Total Blocking Time es de 450 ms y te deja averiguar cuál de tus 30 scripts lo provocó.

El agente abre el archivo, lee el código y escribe el fix: diferirlo, dividirlo en tareas más pequeñas o eliminarlo si nadie lo necesita.

Loading frente a loaded: dos problemas distintos

Que la interacción haya ocurrido durante el estado loading o complete cambia el fix por completo.

Si el INP solo es malo durante el estado loading, el problema es el orden de carga de los scripts. Hay demasiado JavaScript ejecutándose antes de que la página sea interactiva. El fix está en diferir scripts: diferir scripts no críticos, aplicar code-splitting y reducir el JavaScript que bloquea el parser.

Si el INP es malo en estado complete, tienes un problema de JavaScript en tiempo de ejecución. Hay algo ejecutándose en segundo plano en una página totalmente cargada: scripts de terceros haciendo polling para buscar actualizaciones, analítica enviando beacons o tu propio código ejecutando operaciones costosas con un timer.

CoreDash registra el estado de carga de la página en cada medición de INP. CWV Superpowers usa esto para descartar la mitad de las causas antes de mirar los scripts.

Razonamiento proporcional para el INP

El INP es de 350 ms en la página de checkout. El desglose de fases a partir de field data:

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

Presentation es el cuello de botella. Por sí solos, 200 ms no parecen alarmantes. Pero suponen el 57 % del total. Corregir Presentation tiene mucho más impacto que optimizar Input Delay y Processing juntos.

Sin los porcentajes, un agente va a por el Input Delay porque 70 ms superan algún umbral. Muéstrale el desglose e irá directo a ese 57 %. El resultado: un solo fix que baja el INP por debajo de 200 ms frente a tres fixes dispersos que apenas consiguen moverlo.

Fixes típicos por fase

Input Delay durante loading: Difiere los scripts no críticos. Elimina el JavaScript no utilizado. Aplica code-splitting para que solo se cargue el código de la página actual.

Input Delay en complete: Audita los scripts de terceros que se ejecutan tras la carga de la página. Usa los datos LoAF de CoreDash para encontrar el script causante. Difiérelo al tiempo de inactividad con requestIdleCallback.

Processing: Haz yield al main thread con scheduler.yield() o setTimeout(0). Divide los event handlers largos en tareas más pequeñas. Evita los forced layouts (leer propiedades de layout justo después de escribir en el DOM).

Presentation: Usa content-visibility: auto en secciones grandes del DOM below the fold (compatible con todos los navegadores principales desde septiembre de 2025). Reduce el número de nodos del DOM afectados por los cambios del handler. Usa CSS containment para aislar el repaint a un área más pequeña.

Cómo verificar con field data

Las mejoras en el INP se reflejan en CoreDash tras uno o dos días de tráfico real. Consulta la misma página y el mismo segmento de dispositivos. El p75 debería bajar y la distribución de fases debería cambiar.

Fíjate también en el desglose por estado de carga. Si el fix apuntaba al INP en estado loading, confirma que los números en loading mejoraron sin empeorar los del estado complete. El field data te da esta granularidad. El lab data, no.