Métrica Interaction to Next Paint (INP): cómo abordar interacciones lentas

Desarrolladores y propietarios de sitios web, atención. Si aún no lo saben, Google introduce una nueva métrica, Interaction to Next Paint (INP), que en marzo de 2024 reemplazará a First Input Delay (FID) como una de las tres métricas principales de Core Web Vitals.

Interaction to Next Paint es más exigente y refleja mejor la experiencia del usuario en la web. Se trata de una métrica de interactividad, es decir, la rapidez con la que el sitio responde a la acción de un usuario después de que la página se ha cargado y el usuario interactúa con componentes como carruseles, acordeones o añadiendo productos al carrito.

Optimizar esta métrica puede llevar varios meses de trabajo, por lo que es el mejor momento para abordarla.

¿Qué es la métrica INP?#

INP responde a la pregunta: ¿Qué tan rápido reacciona?

Interaction to Next Paint mide la respuesta total de las páginas a las interacciones del usuario al monitorear el retraso de todos los eventos que ocurren durante la visita a las páginas.

El valor recomendado para cumplir con la métrica es de 200 ms. Entre 200 y 500 ms necesita mejoras, y por encima de 500 ms la métrica se considera mala.

Métrica INP

Con este cambio, Google intenta resolver las deficiencias de FID. La innovación radica en que INP mide todas las interacciones (toque, clic, pulsación de tecla) que como usuario realiza mientras navega por las páginas.

Además, mide un tramo ligeramente más largo de la actividad del navegador. Se trata de la parte desde la interacción hasta el repintado de la página.

Métrica INP vs FID

Un sutil contraste con su predecesora FID nos puede ayudar a entender mejor:

First Input Delay	Interaction to Next Paint
primera interacción	todas las interacciones en la página
tiempo desde la interacción hasta el procesamiento	tiempo desde la interacción hasta el repintado de la página
límite 100 ms	límite 200 ms

Si frecuentemente experimentas interacciones en tu web a las cuales no responde o responde tarde, ahí tienes un problema con la métrica INP.

La causa principal de altos valores de INP suele ser JavaScript y las tareas largas (Long Tasks) en curso (medibles con la métrica JS Long Tasks (JSLT)), que impiden el renderizado del nuevo estado de la pantalla ("frame") en el navegador. Otro culpable puede ser la carga lenta de datos tras una solicitud AJAX. Abordaremos su optimización más adelante en el artículo.

Visualiza la conferencia de Zuzka sobre la métrica INP en FrontKon 2023:

¿Cómo se calcula la métrica INP?#

Ahora algunos detalles interesantes sobre el cálculo de la métrica. INP se mide en función de todas las interacciones realizadas en la página. La interacción con el peor desempeño se considera como el valor de la métrica. No se cuentan interacciones como el desplazamiento o el hover, pero sí la respuesta a clics o entradas por teclado.

En caso de un gran número de interacciones, el cálculo es diferente: por cada 50 interacciones en la página se ignora el valor más alto. Google intenta así refinar la métrica y eliminar la influencia de diferentes pausas aleatorias en aplicaciones web donde se hace mucho clic, como pueden ser diversas interfaces de juego.

Medimos INP#

Como explicamos arriba, la fuente de los valores para la métrica INP es el Chrome UX Report (CrUX). Este contiene datos tanto para todo el dominio como para URLs individuales. Para facilitar el trabajo, utiliza alguna de las herramientas disponibles que pueden trabajar con los datos de CrUX y mostrarlos. Se trata, por ejemplo, de nuestra prueba de velocidad de sitios web o de PageSpeed Insights de Google. La distribución de valores de INP en el dominio se muestra en un histograma.

PageSpeed Insights te mostrará las métricas actuales de Core Web Vitals tanto para móviles como para escritorio. También puedes ver datos de una URL específica y de todo el dominio. La segunda línea en el medio es la que más nos interesa, ya que es el valor de la métrica INP.

Medimos INP

Sin embargo, el desarrollo a largo plazo y los cambios regulares en el sitio requieren un enfoque diferente, que nuevamente ofrece nuestra prueba de velocidad de sitios web. Puedes seguir los valores de las métricas a largo plazo.

Métrica INP en nuestro probador

Una herramienta muy útil para monitorear Core Web Vitals es también Google Search Console, donde puedes encontrar URLs reportadas con métricas "defectuosas". Así se pueden identificar relativamente fácilmente URLs potencialmente problemáticas.

Google Search Console

Si la limitación a usuarios de Google Chrome te resulta demasiado restrictiva, siempre puedes usar la medición mediante RUM (Real User Monitoring), o escribir tu propia recolección de datos usando JavaScript y el Performance Observer API.

Otra opción son las mediciones sintéticas, que puedes asegurar mediante herramientas como PageSpeed.ONE, Google Lighthouse, WebPageTest y similares. Aquí solo obtendrás valores de métricas similares (como JS Long Tasks), no INP en sí, ya que esta solo se puede obtener de los usuarios.

Escribimos sobre las diferencias entre mediciones en una página específica: synth vs. CrUX vs. RUM.

Tengo un problema con INP, ¿qué hacer ahora?#

Has revisado los datos del informe CrUX de usuarios, miraste en Google Search Console y ves grupos de URLs reportadas aquí? Ahora es el momento de encontrar el problema. Es decir, pasar a las herramientas de prueba, o probar en el navegador (lo que hacemos nosotros) e identificar los puntos problemáticos específicos.

Para una mirada rápida a las interacciones, puedes usar el INP Debugger. No es una herramienta perfecta, pero puede ayudar a identificar interacciones "largas".

Herramienta Debugbear

El INP Debugger no medirá interacciones anidadas en elementos ocultos y recomendamos realizar más pruebas con él para ver cómo se comporta la página en cuestión. El resultado es una lista de interacciones ordenadas por el tiempo de INP medido.

Un gran aliado en el trabajo es la extensión Chrome Core Web Vitals, que además de todo lo demás, puede imprimir todas las métricas en la consola. Abre DevTools, en la pestaña Performance, configura CPU: 6x slowdown y Network: Fast 3G, para ralentizar el rendimiento del dispositivo.

Extensión Chrome Core Web Vitals

En el último paso, ve a la pestaña Console y activa la extensión Core Web Vitals. Ahora puedes comenzar a probar páginas individuales. Intenta probar todos los escenarios posibles y elementos interactivos, el valor de la métrica INP se imprimirá en la consola.

Chrome Core Web Vitals - impresión en consola

Puedes desglosar interacciones específicas con la ayuda de la grabación de Timeline en la pestaña Performance. Si grabas una interacción específica, en la pestaña "Interactions" verás exactamente cuándo ocurrió.

Pestaña Performance - línea de tiempo

La pestaña "Main" representa scripts y métodos ejecutados, que nos responden a la pregunta "¿Qué está pasando ahí?".

¿Cuáles son los errores comunes y las posibilidades de optimización?#

Interaction to Next Paint es principalmente una métrica de JavaScript, pero muchas cosas se pueden resolver también ajustando la UI. Tenemos un artículo separado sobre la optimización de la métrica INP, pero aquí resumimos brevemente algunas opciones básicas.

No hagas esperar al usuario por una respuesta#

Después de la interacción del usuario, debe haber un cambio en el renderizado en la pantalla del usuario lo antes posible. Si ocurre una solicitud AJAX/Fetch, el usuario a menudo no sabe que está esperando algo. Es necesario que reciba una respuesta visual lo antes posible. Por lo tanto, reacciona con un cambio de diseño y renderizado de un indicador de carga.

No hagas esperar al usuario por una respuesta

No ejecutes código JS después de un clic que puedas posponer#

Pospone eventos como diversas mediciones y el envío de códigos de medición hasta después de que la interfaz haya reaccionado. Las tareas largas, activadas por ejemplo en GTM al hacer clic en un botón, prolongan la reacción de la interfaz y empeoran la métrica INP.

No ejecutes código JS después de un clic que puedas posponer

Elimina tareas largas (Long Tasks) en JavaScript#

El código JavaScript puede crear Long Tasks. Estas tareas deben dividirse en tareas más pequeñas que se ejecuten una tras otra y no bloqueen la respuesta. La forma más sencilla de dividir Long Tasks es envolver el código en una función setTimeout.

document.addEventListener('DOMContentLoaded', function() {
  setTimeout(() => {
    // Aquí se realizan tus funciones
  }, 0);
});

Existen muchas posibilidades interesantes para optimizar INP, recomendamos reflexionar también sobre lo siguiente:

• Optimización de la velocidad de respuesta de Fetch/Ajax.
• Minimización del DOM, uso de "lazy load para DOM" con content-visibility.
• En el futuro, será interesante en lugar de setTimeout() usar scheduler.yield(), Long Animation Frames API.

Encuentra experiencias concretas de optimización de INP en nuestro estudio de caso Innogy: Cómo la colaboración a largo plazo con PageSpeed.ONE mejoró el INP en un 38 %.

Qué debemos recordar sobre INP#

• Interaction to Next Paint (INP) mide la respuesta total de las páginas a las interacciones del usuario monitoreando el retraso de todos los eventos que ocurren durante la visita del usuario a las páginas.
• Los valores recomendados para INP son hasta 200 ms, de 200 a 500 ms necesita ajustes y por encima de 500 ms INP no es satisfactorio.
• Google planea que INP se convierta en parte de Core Web Vitals en marzo de 2024, cuando reemplazará la métrica FID.
• Al optimizar INP, enfócate en eliminar tareas largas en JavaScript (Long Tasks), no hagas esperar al usuario por una respuesta y pospone el código JS que no necesitas ejecutar inmediatamente.

La métrica INP es parte de nuestra métrica unificada de velocidad, puntaje PageSpeed.ONE (SPS).

Consulta también optimización de la métrica INP.