INP (Interaction to Next Paint): qué es y cómo funciona

Interaction to Next Paint (INP) mide cuánto tarda una página en mostrar una respuesta visual después de que alguien hace clic, toca la pantalla o pulsa una tecla. Se convirtió en un Core Web Vital en marzo de 2024, en sustitución de First Input Delay, y responde a una pregunta sencilla: cuando hago algo, ¿reacciona la página de inmediato?

Cómo se mide

Para cada interacción, el navegador cronometra tres fases hasta el siguiente fotograma pintado:

1. Retraso de entrada — el hilo principal está ocupado con otro trabajo, así que tu controlador de eventos tiene que esperar.
2. Tiempo de procesamiento — se ejecutan tus controladores de eventos.
3. Retraso de presentación — el navegador recalcula estilos y diseño y pinta el resultado.

INP informa entonces de una de las interacciones más lentas de toda la visita; en páginas con muchas interacciones ignora un valor atípico por cada 50. Un único menú lento puede definir, por tanto, tu puntuación. El scroll y el hover no cuentan. Los detalles completos están en web.dev: INP.

Umbrales

Bueno es 200 ms o menos; deficiente, más de 500 ms, medido en el percentil 75 de las visitas reales. El umbral de FID era de 100 ms, pero solo medía la espera antes de que empezara el primer controlador, y casi todos los sitios lo superaban. INP es más estricto y se parece mucho más a lo que sienten los usuarios.

Qué hace lento al INP

• Tareas largas — cualquier JavaScript que bloquee el hilo principal durante más de 50 ms. La hidratación de frameworks, los paquetes grandes de analítica y los scripts de pruebas A/B son culpables frecuentes.
• Controladores pesados que lo hacen todo de forma síncrona —filtrar 5.000 filas o volver a renderizar una página entera— antes de dejar pintar al navegador.
• DOM muy grandes, que encarecen cada pasada de estilos y de diseño.
• Etiquetas de terceros cargadas pronto y que compiten por el hilo principal; consulta los recursos que bloquean el renderizado.

Ejemplo: responde primero, trabaja después

button.addEventListener('click', async () => {
  showSpinner();                 // primero, respuesta visible
  await scheduler.yield();       // deja que el navegador pinte
  applyFilters();                // el trabajo pesado, después
});

scheduler.yield() es compatible con los navegadores basados en Chromium; donde no lo es, await new Promise(r => setTimeout(r, 0)) crea una pausa similar. El usuario ve una respuesta al instante y el trabajo costoso se ejecuta en una tarea posterior.

Errores frecuentes

• Fiarte solo de Lighthouse. Una ejecución de laboratorio no puede pulsar tus botones, así que informa del Total Blocking Time como aproximación. El INP real procede de los datos de campo.
• Revisar solo la página de inicio, cuando las interacciones más lentas están en filtros, carritos, cajas de búsqueda y formularios.
• Cargar todos los scripts desde el principio, incluidos widgets de chat y mapas de calor que nadie usa en los primeros segundos. Cárgalos bajo demanda o cuando la página se haya estabilizado.
• Ignorar los móviles de gama media. Un controlador que tarda 40 ms en el portátil de un desarrollador puede tardar varias veces más en un Android económico.

Compruébalo

La prueba de velocidad de página muestra el INP de campo de Google PageSpeed Insights cuando la URL tiene suficiente tráfico de Chrome, además del número y el peso de los scripts de la página, que suele ser lo primero que conviene recortar.

Preguntas frecuentes