Interaction to Next Paint (INP): definición, umbrales y cómo mejorarlo

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

Interaction to Next Paint (INP) es una Core Web Vital que mide la rapidez con que una página responde a las acciones del usuario. Observa cada clic, toque y pulsación de tecla durante una visita, cronometra cada una desde la entrada hasta que el navegador pinta el siguiente fotograma e informa de la más lenta. Una página se considera buena cuando el INP es de 200 milisegundos o menos en el percentil 75 de las cargas reales.

El 12 de marzo de 2024, INP sustituyó a First Input Delay (FID) como Core Web Vital. FID solo medía el retraso antes de gestionar la primera interacción. INP abarca todas las interacciones y el tiempo completo hasta el siguiente pintado, así que refleja cómo se siente la página al usarla, no solo al cargar.

Umbrales de INP

Los umbrales se aplican a datos de campo, separados por móvil y escritorio. Una página los supera cuando al menos el 75 % de las cargas está dentro del límite.

Cómo funciona INP

Cada interacción se divide en tres fases, y un retraso en cualquiera de ellas aumenta el INP:

• Retraso de entrada: el tiempo antes de que puedan empezar los manejadores de eventos, normalmente porque el hilo principal está ocupado.
• Tiempo de procesamiento: lo que tardan en ejecutarse tus manejadores de eventos.
• Retraso de presentación: el tiempo desde que terminan los manejadores hasta que el navegador muestra el siguiente fotograma.

Solo cuentan los clics, toques y pulsaciones de tecla. Pasar el cursor, hacer zoom y desplazarse no son interacciones para INP. Se informa de la interacción más lenta, salvo que en páginas con muchas interacciones se ignora un valor atípico por cada 50. La mayoría de las páginas no llega a 50, así que en la práctica INP es la peor interacción de la visita. Después se informa del percentil 75 de todas las visitas, como en las demás Core Web Vitals.

Ejemplo

Una página de tienda carga rápido, pero el botón "Añadir al carrito" ejecuta un script síncrono grande que recalcula precios, actualiza el carrito y vuelve a renderizar toda la lista de productos. El usuario toca el botón y durante 600 ms no cambia nada visible. LCP y CLS están bien, pero el INP de esa página ronda los 600 ms y se valora como deficiente. Si se reparte el trabajo para que el botón muestre primero su nuevo estado y el resto se ejecute después, la interacción vuelve a bajar de 200 ms.

Cómo medir INP

INP necesita interacciones reales, así que es sobre todo una métrica de campo. El Chrome UX Report (CrUX) la publica para sitios con suficiente tráfico de Chrome, y la monitorización de usuarios reales (RUM) con la biblioteca de código abierto web-vitals de Google muestra qué interacción y qué elemento son lentos:

import { onINP } from 'web-vitals';
onINP((metric) => navigator.sendBeacon('/rum', JSON.stringify(metric)));

Para ver rápidamente cómo le va a una URL con usuarios reales, usa el verificador gratuito de Core Web Vitals, que lee datos de CrUX e informa de LCP, INP y CLS. En las pruebas de laboratorio normalmente no se hace ningún clic, por lo que se suele usar el Total Blocking Time (TBT) como sustituto. web.dev lo describe como un indicador de laboratorio razonable, pero no como un sustituto de medir INP en campo.

Cómo mejorar INP

• Divide las tareas largas. Cualquier tarea de más de 50 ms en el hilo principal puede retrasar la entrada. Cede el control entre bloques de trabajo para que el navegador pueda pintar.
• Haz menos en el manejador. Actualiza primero lo que el usuario debe ver y aplaza analítica, registros y estado no urgente.
• Reduce el coste de los scripts de terceros. Gestores de etiquetas, widgets de chat y anuncios se ejecutan en el mismo hilo principal que tu código.
• Saca el cálculo pesado del hilo principal con un web worker.
• Vigila la hidratación. Un clic que llega mientras el framework se hidrata tiene que esperar.
• Mantén el DOM pequeño. Los renderizados grandes tras un clic alargan el retraso de presentación.

Errores comunes

• Mirar solo la puntuación de Lighthouse. Una prueba de laboratorio en verde dice poco de las interacciones que no ocurrieron en ella.
• Probar solo en un portátil rápido. Los móviles de gama media suelen ser mucho más lentos que un portátil de desarrollo con el mismo JavaScript.
• Optimizar solo la carga. INP se decide sobre todo después de la carga, por lo que ocurre al hacer clic.
• Esperar ver la mejora de inmediato. CrUX es un conjunto de datos de campo móvil de 28 días, así que las mejoras aparecen poco a poco.

INP y monitorización del rendimiento

INP se mide con usuarios reales, así que una prueba puntual no basta. Sigue su evolución junto a LCP y CLS y detecta regresiones tras cada versión. La monitorización de velocidad de página de LoadFocus ejecuta auditorías Lighthouse programadas, incluido el TBT, desde regiones en la nube, lo que ayuda a detectar las regresiones del hilo principal que suelen anticipar un peor INP. Para una guía de optimización paso a paso, lee How to Optimize Interaction to Next Paint, y para configurar alertas, How to monitor Core Web Vitals with alerts and reports (ambos en inglés). La definición de referencia está en web.dev.

Preguntas frecuentes sobre Interaction to Next Paint

¿Qué es un buen INP?

200 milisegundos o menos en el percentil 75 de las cargas de página. Entre 200 y 500 ms necesita mejorar, y por encima de 500 ms es deficiente.

¿INP sustituyó a FID?

Sí. INP pasó a ser una Core Web Vital en lugar de First Input Delay el 12 de marzo de 2024. FID solo medía el retraso de entrada de la primera interacción.

¿Por qué mi puntuación de Lighthouse es buena pero el INP de campo es malo?

Las pruebas de laboratorio rara vez incluyen clics o pulsaciones reales, por lo que no ven las interacciones lentas. El Total Blocking Time es un indicador de laboratorio, pero solo los datos de campo de usuarios reales muestran tu INP real.

¿Qué interacciones cuentan para INP?

Clics, toques y pulsaciones de tecla. Pasar el cursor y desplazarse no cuentan, aunque un gesto de desplazamiento puede incluir un toque o una pulsación que sí cuenta.

¿Cómo encuentro la interacción lenta?

Recoge INP con la biblioteca web-vitals en tu propio RUM, que puede indicar el elemento y la fase lenta, o graba una traza en Chrome DevTools y revisa la interacción en el panel Rendimiento.

¿Afecta la hidratación al INP?

Sí. La hidratación es JavaScript en el hilo principal, así que una interacción durante ella se retrasa. Paquetes más pequeños, hidratación parcial y componentes de servidor reducen el efecto.