Interaction to Next Paint (INP)

Jeremy Wagner

Barry Pollard

Fecha de publicación: 6 de mayo de 2022; última actualización: 9 de septiembre de 2025

Los datos de uso de Chrome muestran que el 90% del tiempo que un usuario pasa en una página se dedica después de que se carga. Por lo tanto, es importante medir cuidadosamente la capacidad de respuesta durante todo el ciclo de vida de la página. Esto es lo que evalúa la métrica del INP.

Una buena capacidad de respuesta significa que una página responde rápidamente a las interacciones. Cuando una página responde a una interacción, el navegador presenta comentarios visuales en el siguiente fotograma que renderiza. Los comentarios visuales te indican si, por ejemplo, se está agregando un elemento que agregas a un carrito de compras en línea, si se abrió un menú de navegación para dispositivos móviles, si el servidor está autenticando el contenido de un formulario de acceso, etcétera.

Algunas interacciones tardan más que otras de forma natural, pero, en el caso de las interacciones especialmente complejas, es importante presentar rápidamente algunos comentarios visuales iniciales para indicarle al usuario que algo está sucediendo. El próximo fotograma que pintará el navegador es la oportunidad más temprana para hacerlo.

Por lo tanto, el objetivo del INP no es medir todos los efectos eventuales de una interacción (como las recuperaciones de red y las actualizaciones de la IU de otras operaciones asíncronas), sino el tiempo durante el que se bloquea la siguiente pintura. Si se retrasa la respuesta visual, es posible que los usuarios tengan la impresión de que la página no responde lo suficientemente rápido, por lo que se desarrolló el INP para ayudar a los desarrolladores a medir esta parte de la experiencia del usuario.

En el siguiente video, el ejemplo de la derecha proporciona comentarios visuales inmediatos que indican que se está abriendo un acordeón. En el ejemplo de la izquierda, se muestra una mala capacidad de respuesta y cómo puede generar experiencias negativas para los usuarios.

En esta guía, se explica cómo funciona el INP, cómo medirlo y se proporcionan recursos para mejorarlo.

¿Qué es el INP?

El INP es una métrica que evalúa la capacidad de respuesta general de una página ante las interacciones del usuario observando la latencia de todas las interacciones de clic, presión y teclado que se producen durante la visita del usuario a la página. El valor final de la INP es la interacción más larga observada, sin tener en cuenta los valores atípicos.

Una interacción es un grupo de controladores de eventos que se activan durante el mismo gesto lógico del usuario. Por ejemplo, las interacciones de "toque" en un dispositivo con pantalla táctil incluyen varios eventos, como pointerup, pointerdown y click. Una interacción puede estar impulsada por JavaScript, CSS, controles integrados del navegador (como elementos de formulario) o una combinación de estos.

La latencia de una interacción consta de la duración más larga de un grupo de controladores de eventos que impulsan la interacción, desde el momento en que el usuario comienza la interacción hasta el momento en que el navegador puede volver a pintar un fotograma. En casos excepcionales, es posible que no haya ningún fotograma para pintar, pero la interacción finaliza cuando el navegador podría pintar un fotograma.

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

Es difícil asignar etiquetas como "buena" o "mala" a una métrica de capacidad de respuesta. Por un lado, quieres fomentar prácticas de desarrollo que prioricen una buena capacidad de respuesta. Por otro lado, debes tener en cuenta que existe una variabilidad considerable en las capacidades de los dispositivos que usan las personas para establecer expectativas de desarrollo alcanzables.

Para asegurarte de ofrecer experiencias del usuario con buena capacidad de respuesta, un buen umbral para medir es el percentil 75 de las cargas de páginas registradas en el campo, segmentadas entre los dispositivos móviles y las computadoras de escritorio:

• Un INP inferior o igual a 200 milisegundos significa que una página tiene una buena capacidad de respuesta.
• Un INP superior a 200 milisegundos y menor o igual a 500 milisegundos significa que la capacidad de respuesta de una página necesita mejorar.
• Un INP superior a 500 milisegundos significa que la página tiene una capacidad de respuesta deficiente.

¿Qué incluye una interacción?

El principal impulsor de la interactividad suele ser JavaScript, aunque los navegadores proporcionan interactividad a través de controles no potenciados por JavaScript, como casillas de verificación, botones de selección y controles potenciados por CSS.

Como objetivos del INP, solo se observan los siguientes tipos de interacciones:

• Hacer clic con un mouse
• Presionar un dispositivo con pantalla táctil
• Presionar una tecla en un teclado físico o en pantalla

Las interacciones se producen en el documento principal o en los elementos iframe incorporados en el documento, por ejemplo, cuando se hace clic en reproducir en un video incorporado. Los usuarios finales no sabrán qué hay en un iframe o no, por lo que se necesita el INP dentro de los iframes para medir la experiencia del usuario en la página de nivel superior. Dado que las APIs web de JavaScript no tienen acceso al contenido de los elementos iframe, esto puede mostrar una diferencia entre CrUX y RUM.

Las interacciones pueden constar de varios eventos. Por ejemplo, una pulsación de tecla incluye los eventos keydown, keypress y keyup. Las interacciones de presión contienen eventos pointerup y pointerdown. El evento con la duración más larga dentro de la interacción es el que contribuye a la latencia total de la interacción.

Como se muestra en el diagrama, la duración del procesamiento del INP incluye todas las devoluciones de llamada del controlador de eventos dentro de ese fotograma. Esto hace que la demora de entrada sea el tiempo anterior a que se controle cualquier devolución de llamada para una interacción, la duración del procesamiento el tiempo para que se ejecuten todas las devoluciones de llamada y la demora de presentación el tiempo posterior a que se ejecutan las devoluciones de llamada hasta que se presenta el fotograma en la pantalla del usuario.

El INP de la página se calcula cuando el usuario la abandona. El resultado es un solo valor que representa la capacidad de respuesta general de la página a lo largo de su ciclo de vida. Un INP bajo significa que una página respondió de forma confiable a las entradas del usuario.

¿En qué se diferencia el INP del First Input Delay (FID)?

El INP es la métrica sucesora del retraso de primera entrada (FID). Si bien ambas son métricas de capacidad de respuesta, el FID solo medía el retraso de entrada de la primera interacción en una página. El INP mejora el FID, ya que observa todas las interacciones en una página, desde el retraso de entrada hasta el tiempo que se tarda en ejecutar los controladores de eventos y, finalmente, hasta que el navegador pinta el siguiente fotograma.

Estas diferencias significan que el INP y el FID son diferentes tipos de métricas de respuesta. Mientras que el FID era una métrica de capacidad de respuesta de carga diseñada para evaluar la primera impresión de la página en el usuario, el INP es un indicador más confiable de la capacidad de respuesta general, independientemente del momento en que se producen las interacciones en la vida útil de una página.

¿Qué sucede si no se informa ningún valor del INP?

Es posible que una página no muestre ningún valor del INP. Esto puede suceder por varios motivos, entre los que se incluyen los siguientes:

• La página se cargó, pero el usuario nunca hizo clic, presionó ni tocó una tecla en su teclado.
• Se cargó la página, pero el usuario interactuó con ella usando gestos que no se miden, como desplazarse o colocar el cursor sobre los elementos.
• Un bot, como un rastreador de búsqueda o un navegador sin interfaz gráfica, accede a la página sin que se haya creado una secuencia de comandos para interactuar con ella.

Cómo medir el INP

El INP se puede medir tanto en el campo como en el laboratorio, en la medida en que puedas simular interacciones realistas del usuario.

En el campo

Lo ideal es que tu recorrido para optimizar el INP comience con los datos de campo. En el mejor de los casos, los datos de campo del Monitoreo de usuarios reales (RUM) te proporcionarán no solo el valor del INP de una página, sino también datos contextuales que destacan qué interacción específica fue responsable del valor del INP, si la interacción ocurrió durante la carga de la página o después, el tipo de interacción (clic, presión de tecla o presión) y otros tiempos valiosos que pueden ayudarte a identificar qué parte de la interacción afectaba la capacidad de respuesta.

Si tu sitio web cumple con los requisitos para incluirse en el Informe sobre la experiencia del usuario en Chrome (CrUX), puedes obtener rápidamente datos de campo sobre el INP a través de CrUX en PageSpeed Insights (y otras Métricas web esenciales). Como mínimo, puedes obtener una imagen a nivel del origen del INP de tu sitio web, pero, en algunos casos, también puedes obtener datos a nivel de la URL.

Sin embargo, si bien CrUX puede indicarte si hay un problema, no puede decirte qué lo causó. Una solución de RUM puede ayudarte a descubrir más detalles sobre las páginas, los usuarios o las interacciones de los usuarios que experimentan problemas de capacidad de respuesta. Poder atribuir el INP a interacciones individuales evita las conjeturas y el desperdicio de esfuerzos.

En el laboratorio

Lo ideal es que comiences a realizar pruebas en el laboratorio una vez que tengas datos de campo que sugieran que una página tiene interacciones lentas. Los datos de campo harán que el trabajo de reproducir interacciones problemáticas en el lab sea una tarea mucho más sencilla.

Sin embargo, es muy posible que no tengas datos de campo. Si bien la INP se puede medir en algunas herramientas de laboratorio, el valor de INP resultante para una página durante las pruebas de laboratorio dependerá de las interacciones que se realicen durante el período de medición. Los comportamientos de los usuarios pueden ser impredecibles y muy variables, lo que significa que las pruebas en el laboratorio pueden no revelar interacciones problemáticas de la misma manera que los datos de campo. Además, algunas herramientas de Lab no informarán el INP de una página porque solo observan la carga de una página sin ninguna interacción. En esos casos, el Tiempo de bloqueo total (TBT) puede ser una métrica de proxy razonable para el INP, pero no es un sustituto del INP en sí.

Si bien las herramientas de laboratorio tienen limitaciones a la hora de evaluar el INP de una página, existen algunas estrategias para reproducir interacciones lentas en el laboratorio. Las estrategias incluyen seguir los flujos de usuarios comunes y probar las interacciones a lo largo del proceso, así como interactuar con la página a medida que se carga (cuando el subproceso principal suele estar más ocupado) para identificar las interacciones lentas durante esa parte crucial de la experiencia del usuario.

Cómo medir el INP en JavaScript

Para medir el INP en JavaScript, debes medir los tiempos de los eventos de todas las interacciones y, luego, tomar el percentil 98 de todas estas interacciones en la descarga de la página. Puedes consultar el código fuente de la biblioteca de JavaScript de web vitals, que contiene una implementación de referencia sobre cómo se calcula el INP.

En la mayoría de los casos, el valor actual del INP en el momento en que se descarga la página es el valor final del INP para esa página, pero hay algunas excepciones importantes, como se indica en la siguiente sección. La biblioteca de JavaScript de web vitals tiene en cuenta estos factores en la mayor medida posible, dentro de las limitaciones de las APIs web.

Diferencias entre la métrica y la API

• Las entradas de event inferiores a 104 milisegundos no se registran de forma predeterminada con los observadores de rendimiento. Este valor predeterminado se puede cambiar cuando se registra un observador de rendimiento con el parámetro durationThreshold, pero incluso este tiene un valor mínimo de 16 milisegundos. Por este motivo, se recomienda observar también la entrada first-input, que también es una entrada de Event Timing, pero se garantiza que se puede observar incluso cuando su duración es inferior a durationThreshold. Esto ayuda a garantizar que las páginas con interacciones siempre registren algún valor del INP.
• Técnicamente, para calcular los percentiles de forma perfecta, es necesario mantener todas las muestras en la memoria, lo que puede resultar costoso. Sin embargo, puedes aproximar los percentiles, especialmente los muy altos, como el p98, con solo mantener una pequeña lista de las peores N interacciones. 10 es una opción común.
• Si se restablece una página desde la caché atrás/adelante, su valor del INP debe restablecerse a cero, ya que los usuarios experimentan esto como una visita a la página distinta.
• La API no registra entradas de event para las interacciones que ocurren dentro de los iframes, pero la métrica sí lo hace, ya que forman parte de la experiencia del usuario en la página. Esto puede mostrarse como una diferencia entre CrUX y RUM. Para medir correctamente el INP, debes tenerlos en cuenta. Los subframes pueden usar la API para informar sus entradas de event-timing al frame principal.

Además de estas excepciones, el INP tiene cierta complejidad adicional debido a que mide todo el ciclo de vida de una página:

• Es posible que los usuarios mantengan una pestaña abierta durante un tiempo muy prolongado: días, semanas o meses. De hecho, es posible que un usuario nunca cierre una pestaña.
• En los sistemas operativos para dispositivos móviles, los navegadores no suelen ejecutar devoluciones de llamada de descarga de página para las pestañas en segundo plano, lo que dificulta informar el valor "final".

Para controlar estos casos, el INP se debe informar cada vez que una página se ejecute en segundo plano, además de cada vez que se descargue (el evento visibilitychange abarca ambos casos). Luego, los sistemas de análisis que reciban estos datos deberán calcular el valor final del INP en el backend.

En lugar de memorizar y analizar todos estos casos por tu cuenta, los desarrolladores pueden usar la biblioteca de JavaScript web-vitals para medir el INP, que tiene en cuenta todo lo mencionado anteriormente, excepto el caso de iframe:

import {onINP} from 'web-vitals';

// Measure and log INP in all situations
// where it needs to be reported.
onINP(console.log);

Cómo mejorar el INP

Hay disponible una colección de guías para optimizar el INP que te ayudarán a identificar las interacciones lentas en el campo y a usar los datos del lab para identificar las causas y optimizarlas.

Registro de cambios

En ocasiones, se descubren errores en las APIs que se usan para medir las métricas y, a veces, en las definiciones de las métricas mismas. Como resultado, a veces se deben realizar cambios, y estos pueden aparecer como mejoras o regresiones en tus informes y paneles internos.

Para ayudarte a administrar esto, todos los cambios en la implementación o la definición de estas métricas se mostrarán en este Registro de cambios.

Si tienes comentarios sobre estas métricas, envíalos al grupo de Google web-vitals-feedback.

Ponga a prueba sus conocimientos