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

Ú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 tu sitio responde 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 filtros en tu 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 utiliza el Total Blocking Time como proxy, pero el TBT mide el bloqueo del hilo principal durante la carga de la página. El INP mide el tiempo de respuesta a las 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 ante esto. Optimiza el TBT y canta victoria mientras los usuarios reales esperan 400 ms para que se registren sus clics.

Tres fases, tres soluciones diferentes

El INP se divide 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, las causas habituales son la ejecución de grandes paquetes de JavaScript, la inicialización de scripts de analítica o la hidratación del framework. En el estado completo (página totalmente cargada), los culpables son 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. Layout thrashing (leer el DOM, escribir en el DOM, leer el DOM en un bucle), consultas síncronas al DOM dentro del manejador, renderizados costosos o simplemente hacer demasiado trabajo en una sola tarea sin hacer yield.

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

Qué script está bloqueando tu página

CoreDash captura la atribución de Long Animation Frames (LoAF) de las sesiones de usuarios reales. Esto es lo que permite al agente solucionar el INP de verdad 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 280 ms durante la interacción en 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 450 ms y te deja a ti averiguar cuál de tus 30 scripts lo causó.

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

Cargando vs cargado: dos problemas diferentes

El hecho de que la interacción haya ocurrido durante el estado loading o complete cambia la solución por completo.

Si el 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 el aplazamiento de scripts: diferir scripts no críticos, dividir el código, reducir el JavaScript que bloquea el analizador.

Si el 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 balizas o tu propio código ejecutando operaciones costosas en 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 mirar los scripts.

Razonamiento proporcional para el INP

El INP es de 350 ms en la página de pago. El desglose de fases según los datos de campo:

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

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

Sin los porcentajes, un agente persigue el Input Delay porque 70 ms supera 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 los 200 ms frente a tres soluciones dispersas que apenas lo mueven.

Soluciones típicas por fase

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

Input Delay en estado completo: Audita los scripts de terceros que se ejecutan después de la carga de la página. Utiliza los datos de LoAF de CoreDash para encontrar el script problemático. Difiérelo al 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 layouts forzados (leer propiedades de diseño inmediatamente después de escribir en el DOM).

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

Verificando con datos de campo

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

Observa también la división del estado de carga. Si tu solución se enfocó en el INP del estado de carga, confirma que los números del estado de carga mejoraron sin hacer retroceder los números del estado completo. Los datos de campo te dan esta granularidad. Los datos de laboratorio no.