Cómo Interaction to Next Paint puntúa tu peor clic

¿Qué es INP (Interaction to Next Paint)?

Chrome mide Interaction to Next Paint como la duración de la peor interacción de una página, cronometrada desde el momento en que un visitante hace clic, toca o pulsa una tecla hasta el momento en que el navegador pinta el frame que muestra el resultado. La métrica cubre el viaje completo: la espera antes de que arranque un manejador de eventos, el tiempo de ejecución del propio manejador y el trabajo de renderizado que viene después. Instruméntala con la librería web-vitals o cualquier colector de campo, y luego léela por ruta.

Chrome cuenta clics de ratón, toques en pantalla táctil y pulsaciones de teclas en teclados físicos o en pantalla, y el scroll, el hover y el zoom no producen ninguna muestra de INP, según la definición de la métrica publicada por el equipo de Chrome en web.dev (consultada en septiembre de 2026). INP es la única de las tres Core Web Vitals que puntúa la capacidad de respuesta después de que la página haya cargado, y no reporta nada hasta que personas reales hacen clic en cosas, así que el número sobre el que actúa Google sale del real user monitoring, la medición sobre usuarios reales, en p75.

¿Cuáles son las tres fases de una interacción?

Cada interacción se divide en input delay (la espera antes del manejador), processing duration (la ejecución del manejador) y presentation delay (el renderizado hasta el frame), e INP es la suma de las tres. Cada fase tiene un dueño distinto dentro del navegador, así que un número de INP no te dice nada hasta que lo separas.

Fase	Empieza cuando	Termina cuando	Qué está quemando el tiempo
Input delay	El visitante hace clic, toca o pulsa una tecla	El primer callback del evento empieza a ejecutarse	Hilo principal ya ocupado con evaluación de scripts, timers, otros manejadores
Processing duration	El primer callback del evento empieza	El último callback termina	Tu propio código de manejador, actualizaciones de estado del framework, trabajo síncrono
Presentation delay	El último callback termina	El navegador pinta el siguiente frame	Recálculo de estilos, layout, paint, tamaño del DOM

La fórmula es una suma directa:

INP = input delay + processing duration + presentation delay

Un ejemplo resuelto. Un visitante toca un chip de filtro en un listado de productos y espera 620ms a que cambie la rejilla:

620ms = 180ms input delay + 90ms processing duration + 350ms presentation delay

El instinto es optimizar el manejador, y el manejador es la porción más pequeña con 90ms. El presentation delay se lleva el 56 por ciento de la interacción, así que el arreglo está en el renderizado: el filtro vuelve a renderizar 3.000 nodos de la rejilla y fuerza un recálculo de estilos completo. Recorta el DOM que toca la interacción y esos 350ms se desploman. Reescribir el manejador ahorra 90ms como mucho y por sí solo no baja de 200ms.

Un toque, tres retrasos

Retraso de entrada180ms

Duración de procesamiento90ms

Retraso de presentación350ms

¿Qué es una buena puntuación de INP?

Los umbrales de Chrome ponen bueno en 200ms o menos y malo por encima de 500ms, medidos en el percentil 75 de las páginas vistas y separados por móvil y escritorio. El equipo de Chrome publica estos cortes en web.dev, sin cambios a septiembre de 2026.

INP en p75	Veredicto
200ms o menos	Bueno
Por encima de 200ms hasta 500ms	Necesita mejorar
Por encima de 500ms	Malo

Doscientos milisegundos son un presupuesto ajustado en cuanto lo divides en tres, y la fase que revienta su parte primero es la que hay que atacar. Mide el reparto antes de tocar código: una caja de búsqueda falla en el processing, una rejilla con scroll infinito falla en la presentation.

¿Por qué INP sustituyó a FID, y por qué FID favorecía a los sitios?

Google convirtió INP en Core Web Vital el 12 de marzo de 2024, en sustitución de First Input Delay, y el soporte de FID terminó el 9 de septiembre de 2024 (web.dev, equipo de Chrome). FID medía una sola cosa estrecha: el retraso de entrada antes de que el primer manejador de eventos de la página pudiera empezar. Nunca cronometró el manejador, y nunca cronometró el paint que venía después.

	First Input Delay	Interaction to Next Paint
Qué interacción	Solo la primera	La peor de la página
Qué fases	Solo input delay	Input delay, processing, presentation
Bueno en p75	100ms o menos	200ms o menos
Estado	Retirado el 9 de septiembre de 2024	Core Web Vital desde el 12 de marzo de 2024

FID favorecía a los sitios por dos razones. La primera interacción de una página es barata para la mayoría de los visitantes: cerrar un aviso de cookies, poner el foco en un campo de búsqueda, tocar aceptar en un diálogo de consentimiento. Las interacciones caras llegan después, una vez que el visitante se ha comprometido con la página, y FID nunca las miró.

FID además paraba su cronómetro antes de que tu código se ejecutara, así que un manejador de filtro que bloqueaba el hilo principal durante 900ms sacaba un FID perfecto mientras el navegador pudiera entrar rápido en el manejador. web.dev dice explícitamente que contar el tiempo de procesamiento en FID podría haber empujado a los desarrolladores a envolver la lógica del manejador en un callback asíncrono, sacándola de la tarea medida sin ayudar a la persona que espera. INP cierra los dos agujeros.

¿Qué interacción reporta INP cuando una página tiene cientos?

Chrome reporta la peor interacción de la página, con un margen para los valores atípicos en páginas con mucha actividad. En páginas con 50 interacciones o menos, la más alta se convierte en el INP de la página. Por encima de 50, Chrome aparta una interacción alta por cada 50 registradas, así que una sesión con 130 interacciones descarta las dos más altas y reporta la siguiente.

Aquí se apilan dos agregaciones, y confundirlas es un error de diagnóstico habitual: la regla de la peor interacción elige un número por página vista, y luego el percentil 75 entre páginas vistas elige un número por URL. Lee esa distribución como lees Largest Contentful Paint, con p75 al lado de p90 y el recuento de muestras.

¿Qué causa un INP lento, y qué arregla cada causa?

Un INP lento tiene tres familias de causas, una por fase, y cada una pide un arreglo distinto.

El input delay viene de un hilo principal que ya está ocupado cuando llega el clic: evaluación de scripts durante la carga, timers y manejadores de fetch compitiendo por el mismo hilo. Recorta la cantidad de JavaScript que llega a ejecutarse, y parte cualquier long task, o tarea larga, por encima de 50ms para que el navegador tenga un hueco donde aceptar la entrada.

La processing duration viene de manejadores que hacen demasiado de una vez. Cede el hilo principal con scheduler.yield() o setTimeout() para que el navegador pueda pintar un frame intermedio, y aplaza todo lo que el visitante no necesita de inmediato detrás de requestAnimationFrame() más una cesión. Pinta primero la respuesta, luego haz el trabajo.

El presentation delay viene del renderizado. Los DOM grandes cuestan más de renderizar que los pequeños, así que aplana el árbol y añade elementos durante la interacción en lugar de enviarlos por adelantado. Reduce el alcance del recálculo de estilos y usa content-visibility para saltarte el trabajo fuera de pantalla. Caza primero el layout thrashing: escribir un estilo y volver a leerlo en la misma tarea fuerza un layout síncrono, y agrupar todas las lecturas antes de todas las escrituras lo elimina. El mismo trabajo de renderizado mueve Cumulative Layout Shift, así que revisa las dos después del arreglo.

¿Cómo encuentras la interacción que hunde tu INP?

Mira las sesiones donde un visitante hizo clic y no pasó nada. Un INP de 640ms en p75 dice que la página es lenta; no dice qué control, qué ruta ni qué dispositivo.

Flowsery graba la sesión y marca rage clicks, dead clicks y errores de JavaScript automáticamente, que es a lo que se parece una interacción atascada desde el lado del visitante: el mismo botón pulsado cuatro veces porque nunca se pintó ningún frame. Las sesiones que coinciden se agrupan en un problema, los problemas se ordenan por cuántos usuarios los sufren, y cada uno llega a Slack, Linear o Jira con la grabación y los pasos para reproducirlo. La recogida corre sobre un script de menos de 10 KB, sin cookies y alojado en la UE, sin muestreo de datos, así que las interacciones lentas no son las que se caen de la muestra.

Preguntas frecuentes

¿INP mide el scroll?

No. Chrome cuenta clics de ratón, toques en pantalla táctil y pulsaciones de teclas, y excluye el scroll, el hover y el zoom. Un scroll con tirones es una queja real que no produce ninguna muestra de INP, así que diagnostícalo con frame timing y long tasks.

¿Por qué mi INP es bueno en Lighthouse y malo en campo?

Lighthouse ejecuta una interacción guionizada en un dispositivo configurado, e INP puntúa la peor interacción que hicieron visitantes reales con su propio hardware. Tu prueba de laboratorio pulsa el botón que le dijiste que pulsara; tus visitantes pulsan el filtro caro en un Android de hace cuatro años. Trata el laboratorio como control de regresión y el campo como veredicto.

¿Debería seguir midiendo First Input Delay?

No. FID dejó de ser Core Web Vital el 12 de marzo de 2024, y el soporte terminó el 9 de septiembre de 2024, así que ya no aparece en Search Console y no pesa en la evaluación. Cambia el panel del dashboard a INP y guarda la serie de FID solo para leer incidentes antiguos.

¿Puede un solo clic lento suspender toda la página?

Por sí solo no. La peor interacción se convierte en el INP de esa página vista, y luego Google lee el percentil 75 de esos valores en todas las páginas vistas de la URL. Un clic de 3 segundos en una sesión no mueve nada; el mismo control lento que golpea a un cuarto de tus sesiones suspende la URL.

¿Cómo se mide INP en una single-page app?

INP se acumula durante toda la vida de la página, así que las interacciones de una ruta se quedan en la misma ventana de medición que la siguiente hasta que una navegación dura la reinicia. Un clic lento en una pantalla de ajustes puede reportarse contra la URL en la que aterrizó el visitante. El soporte de soft navigations de Chrome para partir esas ventanas es experimental, así que segmenta por ruta en tus propios datos de campo.

¿Qué presupuesto por fase mantiene INP por debajo de 200ms?

Cincuenta milisegundos de input delay, 50ms de processing duration y 100ms de presentation delay es un reparto viable. Mide el reparto real por ruta antes de elegir qué arreglar, porque una caja de búsqueda cargada de manejadores y una rejilla de productos cargada de renderizado fallan el mismo umbral por razones opuestas.

¿Qué cuenta como una long task, y por qué importa para INP?

Una long task es cualquier bloque ininterrumpido de trabajo en el hilo principal de más de 50ms, el mismo umbral al que apuntan las correcciones del retraso de entrada. Mientras una long task se ejecuta, el navegador no puede iniciar un manejador de eventos, así que ese tiempo se suma directo al retraso de entrada. Dividir la long task en piezas más pequeñas le da al navegador un hueco para aceptar el clic y arrancar el manejador antes.

¿Cómo se detiene el layout thrashing que alarga el retraso de presentación?

El layout thrashing ocurre cuando el código escribe un estilo y lo vuelve a leer en la misma tarea, lo que fuerza un layout síncrono que el navegador habría aplazado. Agrupar todas las lecturas antes que las escrituras dentro de la misma tarea elimina ese layout forzado junto con el retraso que añadía. Esto se revisa primero dentro del retraso de presentación, antes que el tamaño del DOM y content-visibility.

¿Qué herramienta mide realmente el INP de tu propio sitio?

INP se instrumenta con la librería web-vitals o cualquier otro recolector de campo, leído por ruta. Como INP solo reporta algo cuando visitantes reales hacen clic, tocan o escriben, ese número tiene que venir de real user monitoring y no de una sola ejecución de Lighthouse. El resultado se lee en el percentil 75, igual que lo puntúa Chrome.

¿Por qué Chrome descarta algunas interacciones en páginas con muchos clics?

Por encima de 50 interacciones registradas, Chrome aparta un valor alto por cada 50 para que un puñado de casos atípicos no decida la puntuación de toda la página. Una página con 130 interacciones descarta las dos más altas y reporta la siguiente como su INP. Las páginas con 50 interacciones o menos se saltan este paso y usan directamente la peor interacción.