Interaction to Next Paint (INP) es una métrica de Core Web Vitals que mide la capacidad de respuesta general de un sitio web a las interacciones del usuario, como clics, toques y entradas de teclado durante una sesión. Una buena puntuación de INP es de 200 milisegundos o menos. Mejorar el INP requiere dividir las tareas largas en el hilo principal, reducir los scripts de terceros, ceder el control al hilo principal durante operaciones de renderizado pesadas y optimizar los manejadores de eventos para garantizar una respuesta visual instantánea.
¿Qué causa una alta latencia en Interaction to Next Paint?
Los navegadores web ejecutan JavaScript en un solo hilo llamado hilo principal (main thread). Cuando un usuario hace clic en un botón o abre un menú móvil, el navegador debe poner en cola el manejador de eventos de JavaScript correspondiente, ejecutar el código y recalcular el diseño para pintar el fotograma actualizado. Si el hilo principal está ocupado por un bloque de ejecución que dura más de 50 milisegundos —conocido como tarea larga (long task)—, la interacción del usuario se retrasa. El tiempo total dedicado a esperar la ejecución, ejecutar el manejador y renderizar la actualización forma la duración total del INP.
En una cuenta típica o estructura de sitio, la alta latencia suele provenir de tres fases distintas: retraso de entrada, tiempo de procesamiento y retraso de presentación. El retraso de entrada ocurre cuando tareas anteriores bloquean el hilo principal antes de que siquiera comience tu manejador de eventos. El tiempo de procesamiento representa la duración del código del manejador de eventos en sí. El retraso de presentación es el tiempo dedicado a recalcular estilos, actualizar árboles de diseño y renderizar píxeles en la pantalla. Los árboles DOM complejos con miles de nodos amplían significativamente el retraso de presentación.
¿Cómo mides el INP en Chrome DevTools?
Diagnosticar el retraso de interacción requiere capturar datos de rendimiento mientras se interactúa activamente con la página. Abre Chrome DevTools, selecciona el panel Performance e inicia una grabación manual mientras haces clic en elementos, escribes en campos o alternas menús interactivos. Una vez que detengas la grabación, observa la pista Interactions en la parte superior de la línea de tiempo. Las interacciones largas se resaltan con indicadores rojos, mostrando la duración exacta del retraso de entrada, la duración del procesamiento y el retraso de presentación.
Para imitar dispositivos móviles del mundo real, habilita la limitación de CPU (CPU throttling) en la configuración de rendimiento de DevTools. Establecer una ralentización de CPU 4x revela cuellos de botella que podrían permanecer invisibles en hardware de desarrollo de escritorio potente. Las herramientas de pruebas sintéticas como Lighthouse proporcionan datos de laboratorio, pero los datos de campo recopilados a través de Google Search Console o herramientas de monitoreo de usuarios reales reflejan las experiencias reales de los visitantes en diversas velocidades de red y capacidades de hardware.
¿Por qué los scripts de terceros están arruinando tu puntuación de INP?
Los scripts de terceros agregados a través de administradores de etiquetas a menudo ejecutan JavaScript no coordinado durante la actividad máxima del usuario. Los rastreadores de análisis, las herramientas de mapas de calor, los widgets de chat y los píxeles publicitarios procesan continuamente los eventos entrantes o consultan la red. Cuando un usuario hace clic en un elemento interactivo mientras una etiqueta de marketing de terceros evalúa reglas en segundo plano, la acción del usuario se pone en cola detrás de la ejecución del seguimiento, empujando la latencia más allá del objetivo de 200 ms.
Auditar scripts de terceros requiere evaluar tanto el tiempo de carga como el costo de ejecución. Consolida las funciones de seguimiento dentro de Google Tag Manager y elimina las etiquetas redundantes que recopilan datos superpuestos. Configura las condiciones de activación para que las etiquetas de marketing no esenciales se ejecuten después de la interacción inicial del usuario o durante los períodos de inactividad utilizando métodos requestIdleCallback. Reducir la competencia del hilo principal de los scripts externos crea un margen inmediato para los eventos iniciados por el usuario.
División de tareas largas en el hilo principal
Las tareas largas bloquean el hilo principal yevitan que el navegador responda con prontitud a las entradas del usuario. Para resolver esto, los desarrolladores pueden dividir manualmente las funciones monolíticas en fragmentos asíncronos más pequeños. Ceder el control al hilo principal le da al navegador una breve ventana para procesar las interacciones de usuario en cola y renderizar los fotogramas visuales actualizados antes de reanudar la computación pesada en segundo plano.
Las API de navegadores modernos ofrecen patrones claros para ceder la ejecución sin interrumpir la lógica de funciones. La inserción de puntos de cesión dentro de bucles largos o cálculos de varios pasos permite al hilo principal manejar los eventos de entrada entrantes de inmediato.
- Usa scheduler.yield() en navegadores compatibles para devolver el control al hilo principal preservando la prioridad de ejecución.
- Vuelve a setTimeout con un parámetro de retraso cero para poner en cola el trabajo restante en una nueva macro-tarea.
- Envuelve transformaciones de datos intensivas en CPU dentro de Web Workers para trasladar el procesamiento fuera del hilo principal por completo.
- Divide las actualizaciones masivas del DOM en operaciones por lotes usando requestAnimationFrame para alinear los cambios con las actualizaciones de fotogramas.
¿Cómo debes optimizar los manejadores de eventos pesados?
Los manejadores de eventos vinculados a las entradas del usuario a menudo intentan realizar demasiadas tareas en un solo bloque síncrono. Por ejemplo, un botón de filtro en una plataforma de comercio electrónico podría actualizar los parámetros de URL, filtrar colecciones de productos, recalcular rangos de precios y activar píxeles de seguimiento dentro de un solo evento de clic. Ejecutar todas estas operaciones sincrónicamente detiene el renderizado, dejando al usuario con una interfaz congelada durante varios cientos de milisegundos.
Para arreglar los manejadores de eventos pesados, prioriza la retroalimentación visual inmediata sobre la finalización computacional completa. Cambia el estado de la UI al instante —como mostrar un indicador de carga o actualizar los estados de los botones— antes de ejecutar la lógica de filtrado pesado. Mueve los efectos secundarios no críticos, como el envío de pings analíticos o la guardia de estados temporales de usuario en localStorage, fuera del bucle de renderizado principal.
Alien Road recomienda revisar los escuchas de eventos de entrada en los componentes interactivos para separar los cambios de estado visual del procesamiento en segundo plano. La refactorización de manejadores garantiza que los gestos del usuario produzcan confirmaciones visuales inmediatas, manteniendo la latencia de interacción percibida y medida muy por debajo de los 200 ms.
- Proporciona retroalimentación visual inmediata en el manejador de eventos para reconocer la acción del usuario al instante.
- Aplica debounce a los eventos de entrada continuos como el redimensionamiento de la ventana, el desplazamiento o la escritura en entradas de búsqueda.
- Separa las actualizaciones visuales del DOM del procesamiento de datos en segundo plano utilizando microtareas o trabajadores asíncronos.
- Elimina los escuchas de eventos obsoletos o duplicados registrados en elementos contenedores padres.
Gestión de estructuras DOM complejas y retraso de presentación
El retraso de presentación forma el componente final de la latencia de Interaction to Next Paint. Una vez que se completa la ejecución de JavaScript, el navegador debe calcular los estilos calculados, diseñar la geometría de la página y pintar los píxeles. Los árboles DOM grandes que contienen miles de elementos escalan la complejidad del renderizado, haciendo que incluso los cambios DOM simples sean costosos de calcular.
Mantén el tamaño del DOM manejable eliminando elementos ocultos, renderizando de forma perezosa (lazy) listas fuera de la pantalla y aplicando propiedades modernas de contención CSS. Las propiedades CSS como contain-intrinsic-size y content-visibility: auto permiten a los navegadores omitir los cálculos de estilo y diseño para los componentes fuera de la pantalla hasta que se desplacen a la vista. Reducir el tiempo de recálculo del diseño disminuye directamente el retraso de presentación durante los clics del usuario.
Dónde empezar a mejorar el INP esta semana
Mejorar la capacidad de respuesta de las interacciones requiere un enfoque metódico que aborde primero los cuellos de botella de alto impacto. Comienza auditando tus datos de campo de usuarios reales en Google Search Console bajo Core Web Vitals para identificar las URL específicas que experimentan interacciones lentas.
A continuación, reproduce esos retrasos de interacción utilizando el panel Performance de Chrome DevTools bajo una limitación de CPU 4x. Enfoca tus esfuerzos de ingeniería en dividir las tareas largas que se ejecutan durante los clics del usuario, limpiar etiquetas de terceros innecesarias y ceder la ejecución del hilo principal. Al mantener las puntuaciones de INP en 200 ms o menos, tu sitio ofrece una experiencia receptiva que mantiene a los visitantes comprometidos.
Sigue leyendo: Diseño y desarrollo web · Diseño web