Solucionar 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 INP. Un agente de IA sin datos de usuarios reales no puede decirte qué interacción es lenta, quién la experimenta o cuándo sucede en el ciclo de vida de la página. Así es como solucionas INP cuando tienes datos de campo.

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

Por qué INP es diferente para los agentes de IA

INP mide qué tan rápido responde tu sitio a las interacciones del usuario: clics, toques, pulsaciones de teclas. Elige la peor interacción de toda la sesión. La palabra clave es real. Un usuario hace clic en un menú desplegable de filtro en tu página de producto mientras se ejecuta un script de analítica de terceros. Ese retraso de 380ms se convierte en el INP de esa sesión.

Ninguna herramienta de laboratorio puede reproducir esto. Lighthouse usa el Total Blocking Time como aproximación, pero TBT mide el bloqueo del hilo principal durante la carga de la página. 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 aún puede tener un INP terrible si un temporizador en segundo plano se activa en el momento equivocado. Un agente sin datos de campo es ciego a esto. Optimiza el TBT y declara la victoria mientras los usuarios reales esperan 400ms para que se registren sus clics.

Tres fases, tres soluciones diferentes

INP se desglosa en tres fases. Cada una significa una solución diferente.

Input Delay: El hilo principal estaba ocupado cuando el usuario interactuó. Durante el estado de carga (loading), las causas habituales son la ejecución de grandes bundles de JavaScript, la inicialización de scripts de analítica o la hidratación del framework. En el estado completo (página totalmente cargada), la culpa es de los temporizadores en segundo plano, los scripts de terceros que consultan actualizaciones o la actividad del service worker.

Processing: El propio manejador de eventos es demasiado lento. El Layout thrashing (leer el DOM, escribir en el DOM, leer el DOM en bucle), las consultas síncronas del DOM dentro del manejador, los re-renders costosos o simplemente hacer demasiado trabajo en una sola tarea sin hacer yield.

Presentation: El navegador tarda demasiado en pintar después de que termina el manejador. Árboles DOM grandes (miles de nodos que necesitan recálculo de estilos), falta de contención CSS (CSS containment) u operaciones de pintura costosas desencadenadas por los cambios en el DOM del manejador.

Qué script está bloqueando tu página

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

LoAF nombra el archivo JavaScript exacto, la función y la duración. El agente no adivina qué script está bloqueando el hilo principal. CoreDash se lo dice: gtm-container.js bloqueó el hilo principal durante 280ms en la interacción con el filtro de la página de pago.

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

El agente abre el archivo, lee el código y escribe la solución: aplazarlo (defer), dividirlo en tareas más pequeñas o eliminarlo si nadie lo necesita.

Cargando vs cargado: dos problemas diferentes

Si la interacción ocurrió durante el estado loading o complete cambia la solución por completo.

Si INP es malo solo durante el estado de carga, el problema es el orden de carga de los scripts. Demasiado JavaScript ejecutándose antes de que la página sea interactiva. La solución está en aplazar los scripts: aplazar scripts no críticos, usar code-splitting, reducir el JavaScript que bloquea el parser.

Si INP es malo en el estado completo, tienes un problema de JavaScript en tiempo de ejecución. Algo se está ejecutando en segundo plano en una página completamente cargada. Scripts de terceros buscando actualizaciones, analíticas enviando beacons o tu propio código ejecutando operaciones costosas con un temporizador.

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

Razonamiento proporcional para INP

INP es de 350ms en la página de pago. El desglose de fases basado en datos de campo:

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

Presentation es el cuello de botella. 200ms no suena alarmante de forma aislada. Pero es el 57% del total. Solucionar Presentation mueve más la aguja que optimizar Input Delay o Processing combinados.

Sin los porcentajes, un agente persigue el Input Delay porque 70ms excede algún umbral. Muéstrale el desglose y va directo a por el 57%. El resultado: una solución que reduce el INP por debajo de 200ms frente a tres soluciones dispersas que apenas lo mueven.

Soluciones típicas por fase

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

Input Delay en estado completo: Audita los scripts de terceros que se ejecutan después de cargar la página. Usa los datos de LOAF de CoreDash para encontrar el script problemático. Aplázalo hasta el tiempo de inactividad con requestIdleCallback.

Processing: Haz yield al hilo principal con scheduler.yield() o setTimeout(0). Divide los manejadores de eventos largos en tareas más pequeñas. Evita los forced layouts (leer propiedades de diseño inmediatamente después de escribir en el DOM).

Presentation: Usa content-visibility: auto para secciones grandes del DOM debajo de la línea de pliegue (soportado en todos los navegadores principales desde septiembre de 2025). Reduce el número de nodos del DOM afectados por los cambios del manejador. Usa contención CSS (CSS containment) para aislar el repintado en un área más pequeña.

Verificando con datos de campo

Las mejoras en INP aparecen en CoreDash dentro de un día o dos de tráfico real. Consulta la misma página y segmento de dispositivo. El p75 debería bajar y la distribución de las fases debería cambiar.

Observa también la división del estado de carga. Si tu solución apuntaba al INP del estado de carga, confirma que los números del estado de carga mejoraron sin que los números del estado completo retrocedieran. Los datos de campo te dan esta granularidad. Los datos de laboratorio no.