Cómo mejorar el INP de una web y conseguir una navegación más rápida

Una página puede cargar rápidamente y, aun así, ofrecer una experiencia lenta.

El contenido aparece, las imágenes se muestran y el usuario empieza a navegar. Sin embargo, al abrir el menú, seleccionar un filtro o añadir un producto al carrito, la interfaz tarda en reaccionar.

Durante ese breve intervalo parece que no ocurre nada.

El usuario puede volver a pulsar el botón, pensar que la función está rota o abandonar el proceso. En una tienda online, una aplicación o una página con formularios, estos retrasos afectan directamente a la facilidad de uso y pueden reducir las conversiones.

Interaction to Next Paint, conocido como INP, es la métrica que permite evaluar esta capacidad de respuesta.

A diferencia de otras mediciones centradas en la carga inicial, INP observa las interacciones realizadas durante toda la visita. Analiza cuánto tiempo transcurre desde que una persona pulsa, toca o utiliza el teclado hasta que el navegador muestra una respuesta visual.

Google considera bueno un INP de 200 milisegundos o menos. Los valores situados entre 200 y 500 milisegundos necesitan mejoras, mientras que un resultado superior a 500 milisegundos se considera deficiente. La evaluación se realiza sobre el percentil 75 de las visitas, separando móvil y escritorio.

Mejorar el INP exige descubrir qué interacciones son lentas, comprender por qué bloquean la interfaz y reducir el trabajo que el navegador debe realizar antes de mostrar el siguiente fotograma.

Qué mide exactamente el INP

INP evalúa la capacidad de respuesta general de una página.

Observa interacciones como:

• Clics con el ratón.
• Toques en una pantalla.
• Pulsaciones de teclado.

No mide acciones como desplazar la página o ampliar el contenido.

Durante una visita pueden producirse muchas interacciones. El navegador registra su latencia y utiliza una de las más lentas para calcular el resultado final, aplicando un mecanismo que evita que determinados valores aislados distorsionen excesivamente las páginas con una gran cantidad de acciones.

Esto significa que no basta con que el primer botón responda correctamente.

Una página puede comenzar siendo rápida y bloquearse después cuando el usuario abre un filtro, cambia una variante o completa un formulario.

Las tres partes de una interacción

Para mejorar el INP conviene entender qué ocurre desde que el usuario realiza una acción hasta que ve el resultado.

La duración total se divide en tres partes.

Retraso de entrada

Comienza cuando el usuario interactúa y termina cuando el navegador empieza a ejecutar el código correspondiente.

Puede existir retraso porque el hilo principal está ocupado con otras tareas.

Por ejemplo, el navegador podría estar:

• Procesando JavaScript.
• Renderizando componentes.
• Analizando un script publicitario.
• Ejecutando una extensión.
• Actualizando una parte compleja de la página.

Aunque el usuario ya haya pulsado, la acción debe esperar hasta que el navegador termine el trabajo anterior.

Duración del procesamiento

Es el tiempo que necesitan los controladores del evento para ejecutarse.

Cuando se pulsa un botón, el código puede validar datos, realizar cálculos, actualizar estados, consultar elementos o preparar una nueva interfaz.

Si el proceso ejecuta demasiadas operaciones de forma consecutiva, la respuesta se retrasa.

Retraso de presentación

Comienza cuando termina el código de la interacción y finaliza cuando el navegador muestra el siguiente fotograma.

En esta fase pueden producirse cálculos de estilos, reorganización de elementos y renderizado.

Una interacción puede tener un JavaScript relativamente rápido y seguir ofreciendo un INP deficiente si obliga al navegador a actualizar una gran parte de la página.

La suma de estas tres fases constituye la latencia total de la interacción. Por eso, la optimización debe identificar cuál de ellas está generando el problema.

Por qué es importante para la experiencia de usuario

Los usuarios esperan que la web confirme inmediatamente sus acciones.

Cuando pulsan un elemento, necesitan una señal visual que indique que el sistema ha respondido.

Los retrasos afectan especialmente a:

• Menús.
• Buscadores.
• Filtros de productos.
• Selectores de fechas.
• Formularios.
• Carritos.
• Botones de compra.
• Áreas privadas.
• Aplicaciones web.
• Editores online.

En una tienda, el usuario puede pulsar varias veces “añadir al carrito” y terminar incorporando unidades duplicadas; en un formulario, puede creer que el botón de envío no funciona; y en una aplicación, una interfaz lenta transmite una sensación de poca calidad incluso cuando la operación termina correctamente.

INP se convirtió oficialmente en una Core Web Vital estable el 12 de marzo de 2024, sustituyendo a First Input Delay. El cambio permitió evaluar la capacidad de respuesta durante toda la visita y no únicamente ante la primera interacción.

Empezar con datos de usuarios reales

El primer paso no debería ser instalar un plugin de optimización al azar.

Hay que identificar qué páginas e interacciones están generando retrasos.

Los datos de campo reflejan la experiencia real de personas que utilizan diferentes dispositivos, conexiones y navegadores.

Pueden consultarse mediante:

• Google Search Console.
• PageSpeed Insights.
• Chrome User Experience Report.
• Sistemas de monitorización de usuarios reales.
• Herramientas propias de analítica de rendimiento.

Search Console permite identificar grupos de páginas con problemas de Core Web Vitals. PageSpeed Insights puede mostrar datos reales cuando existe suficiente información en Chrome.

Sin embargo, estas herramientas no siempre indican qué botón o interacción concreta produjo el INP.

Para conseguir ese nivel de detalle puede utilizarse una solución de Real User Monitoring, conocida como RUM. Este tipo de medición puede registrar la página, el elemento, el tipo de interacción y las diferentes partes de su latencia. Google recomienda comenzar con datos de campo y utilizar RUM cuando sea posible para obtener contexto adicional.

Reproducir las interacciones en un entorno de prueba

Una vez identificadas las páginas problemáticas, hay que intentar reproducir el retraso.

Chrome DevTools permite grabar el rendimiento mientras se utiliza la web.

Conviene probar recorridos reales:

• Abrir el menú durante la carga.
• Seleccionar filtros.
• Cambiar variantes.
• Añadir productos al carrito.
• Abrir ventanas.
• Escribir en formularios.
• Navegar entre pestañas.
• Enviar una solicitud.

Las pruebas deberían realizarse en condiciones exigentes.

Un ordenador potente puede ocultar problemas que aparecen en teléfonos con menos capacidad. También conviene interactuar mientras la página todavía se está cargando, ya que el hilo principal suele estar más ocupado durante ese periodo.

El análisis debe centrarse primero en los recorridos más frecuentes y comerciales, no en acciones excepcionales que apenas utiliza nadie.

Reducir las tareas largas de JavaScript

Una de las causas más habituales de un INP deficiente es la ejecución de tareas largas en el hilo principal.

Mientras el navegador procesa una tarea, no puede responder inmediatamente a nuevas interacciones.

El problema puede aparecer al:

• Inicializar componentes.
• Procesar grandes cantidades de datos.
• Ejecutar filtros.
• Validar formularios.
• Renderizar listados.
• Cargar herramientas externas.
• Actualizar numerosos elementos.

La solución consiste en reducir la cantidad de trabajo o dividirla.

En lugar de ejecutar un bloque grande sin interrupciones, puede separarse en tareas más pequeñas para permitir que el navegador atienda acciones pendientes entre ellas.

También conviene eliminar cálculos duplicados y evitar operaciones que no son necesarias para producir la primera respuesta visual.

Google recomienda hacer el mínimo trabajo posible durante cada interacción, evitar bloques largos de JavaScript y reducir las actualizaciones de renderizado innecesarias.

Dar prioridad a la respuesta visual

En algunas interacciones no es necesario completar todo el proceso antes de mostrar una señal.

Al pulsar “añadir al carrito”, la interfaz puede cambiar inmediatamente el estado del botón y ejecutar después las tareas secundarias.

Este enfoque permite ofrecer una respuesta visual rápida mientras continúan otros procesos.

Por ejemplo:

1. El usuario pulsa el botón.
2. La interfaz muestra un estado de carga.
3. El navegador presenta el siguiente fotograma.
4. Se actualiza el carrito.
5. Se muestra la confirmación final.

La prioridad inicial debe ser comunicar que la acción ha sido recibida.

No conviene dejar la interfaz inmóvil mientras se ejecutan analítica, recomendaciones, animaciones o tareas que pueden realizarse posteriormente.

Reducir JavaScript innecesario

Cuanto más código carga y ejecuta una página, mayor es la probabilidad de bloquear el hilo principal.

Conviene revisar:

• Constructores visuales.
• Plugins.
• Scripts publicitarios.
• Chats.
• Mapas.
• Carruseles.
• Sistemas de personalización.
• Herramientas de analítica.
• Etiquetas duplicadas.
• Funciones antiguas.

Cada script debería justificar su presencia.

Una herramienta utilizada únicamente en una sección no necesita cargarse en toda la web.

También pueden aplicarse técnicas como:

• División del código.
• Carga diferida.
• Importación bajo demanda.
• Eliminación de dependencias.
• Sustitución de librerías pesadas.
• Reducción de componentes.

El objetivo no consiste en eliminar JavaScript, sino en utilizar únicamente el necesario y ejecutarlo en el momento adecuado.

Controlar los scripts de terceros

Los scripts externos pueden consumir una parte importante del tiempo de procesamiento.

La empresa puede necesitar herramientas de publicidad, analítica, consentimiento o atención al cliente, pero debería revisar cómo afectan a la capacidad de respuesta.

Conviene analizar:

• Qué proveedor añade cada script.
• En qué páginas se carga.
• Cuándo se ejecuta.
• Cuánto tiempo bloquea.
• Si existe una alternativa más ligera.
• Si puede activarse después de una interacción.
• Si duplica otra herramienta.

Un chat que solo utiliza una parte reducida de los visitantes puede cargarse cuando se abre, en lugar de inicializarse completamente durante la carga de todas las páginas.

La misma lógica puede aplicarse a mapas, vídeos o widgets externos.

Evitar diseños demasiado complejos

El INP no depende únicamente de JavaScript.

Después de ejecutar una interacción, el navegador puede necesitar recalcular estilos y reorganizar una gran cantidad de elementos.

Esto ocurre con mayor frecuencia cuando la página tiene:

• Un DOM excesivamente grande.
• Selectores CSS complejos.
• Componentes muy anidados.
• Listados extensos.
• Elementos ocultos que siguen presentes.
• Cambios que afectan a toda la estructura.
• Animaciones costosas.

Un catálogo que muestra cientos de productos al mismo tiempo puede obligar al navegador a actualizar demasiados nodos al aplicar un filtro.

Puede ser más eficiente utilizar paginación, carga progresiva o virtualización.

La guía oficial de optimización de INP incluye la complejidad del diseño, el tamaño del DOM y el coste de los cálculos de estilo entre las áreas que deben revisarse cuando el retraso aparece durante la presentación.

Evitar el layout thrashing

El navegador calcula la posición y el tamaño de los elementos antes de mostrarlos.

El problema aparece cuando el código alterna repetidamente entre leer medidas y modificar estilos.

Por ejemplo:

1. Consulta la altura de un elemento.
2. Modifica su anchura.
3. Consulta de nuevo su posición.
4. Cambia otro estilo.
5. Repite el proceso.

Cada lectura puede obligar al navegador a recalcular el diseño antes de tiempo.

Este comportamiento se conoce como layout thrashing y puede generar retrasos importantes.

Conviene agrupar las lecturas y las escrituras:

• Primero obtener las medidas necesarias.
• Después aplicar todos los cambios.

También deben evitarse modificaciones individuales sobre cientos de elementos cuando puede actualizarse un contenedor o utilizarse una clase común.

Mover cálculos a Web Workers

Algunas operaciones intensivas no necesitan ejecutarse en el hilo principal.

Los Web Workers permiten procesar JavaScript en un hilo separado.

Pueden ser útiles para:

• Cálculos complejos.
• Procesamiento de datos.
• Transformaciones.
• Búsquedas locales.
• Generación de resultados.
• Análisis de archivos.

No pueden modificar directamente el DOM, por lo que deben enviar el resultado al hilo principal para actualizar la interfaz.

Esta técnica no resulta necesaria para cualquier función. Sin embargo, puede mejorar significativamente la capacidad de respuesta cuando la aplicación realiza operaciones pesadas.

Optimizar formularios

Los formularios pueden generar un INP elevado cuando validan demasiados campos en cada pulsación.

Conviene evitar que cada tecla active:

• Consultas al servidor.
• Validación completa.
• Recalculo de todo el formulario.
• Actualización de múltiples componentes.
• Búsquedas sin espera.

Puede utilizarse un pequeño retraso controlado antes de ejecutar búsquedas o validaciones que no necesitan ser instantáneas.

También es recomendable validar primero los campos relacionados con la acción actual, en lugar de revisar todo el formulario continuamente.

Los mensajes de error deben aparecer sin reconstruir innecesariamente grandes partes de la página.

Optimizar filtros y buscadores

Los filtros de ecommerce suelen ser una fuente importante de retrasos.

Al seleccionar una opción, el sistema puede:

• Actualizar la URL.
• Consultar el servidor.
• Procesar productos.
• Modificar contadores.
• Renderizar resultados.
• Actualizar recomendaciones.
• Registrar analítica.

No todas estas operaciones tienen que ejecutarse antes de mostrar una señal.

El filtro puede cambiar de estado inmediatamente y cargar los resultados a continuación.

También conviene limitar el número de productos renderizados y evitar recalcular elementos que no han cambiado.

No depender únicamente de PageSpeed Insights

PageSpeed Insights es útil para detectar tendencias y revisar los datos disponibles, pero no identifica por sí solo todos los problemas de interacción.

INP se mide durante toda la visita. Una prueba automatizada puede no ejecutar el menú, el carrito o el formulario concreto que provoca el retraso.

Por eso, la metodología debe combinar:

• Datos reales.
• Recorridos manuales.
• Chrome DevTools.
• Monitorización.
• Análisis del código.
• Pruebas en dispositivos modestos.

También es importante comparar la versión móvil y la de escritorio por separado.

Medir después de cada cambio

Las mejoras deben comprobarse antes de publicarse y seguirse después en producción.

Puede ocurrir que una modificación reduzca el tiempo de una interacción, pero empeore la carga inicial o introduzca un error.

Conviene registrar:

• INP anterior.
• Interacción problemática.
• Cambios aplicados.
• Resultado en laboratorio.
• Resultado con usuarios reales.
• Impacto en conversiones.
• Errores detectados.

Los datos de campo necesitan tiempo para reflejar las nuevas visitas. Por eso, las pruebas de laboratorio sirven para validar rápidamente el cambio, mientras que la monitorización confirma su impacto real.

Priorizar las interacciones que afectan al negocio

No todas las acciones tienen el mismo valor.

La optimización debería comenzar por aquellas que participan directamente en procesos importantes:

• Abrir el menú móvil.
• Utilizar el buscador.
• Aplicar filtros.
• Seleccionar una variante.
• Añadir al carrito.
• Avanzar en el checkout.
• Enviar un formulario.
• Reservar una cita.
• Acceder a una cuenta.

Una mejora pequeña en un proceso utilizado miles de veces puede aportar más valor que una gran optimización en una función secundaria.

Mantener el INP bajo control

Una web puede mejorar su INP y volver a empeorar meses después.

Cada nuevo plugin, campaña, herramienta o componente añade trabajo al navegador.

Conviene establecer revisiones periódicas y presupuestos de rendimiento.

La empresa puede definir límites para:

• Cantidad de JavaScript.
• Duración de tareas largas.
• Tamaño del DOM.
• INP en móvil.
• Tiempo de funciones críticas.
• Número de scripts externos.

Antes de publicar una nueva funcionalidad, debería comprobarse que no perjudica los recorridos principales.

Una respuesta rápida mejora toda la percepción de la web

Mejorar el INP significa reducir el tiempo que transcurre entre una acción y su respuesta visual.

Para lograrlo es necesario analizar las tres fases de la interacción: retraso de entrada, procesamiento y presentación.

Las soluciones pueden incluir dividir tareas largas, reducir JavaScript, simplificar el DOM, controlar scripts externos y priorizar la respuesta visual.

No existe una optimización universal.

Cada página puede presentar una interacción lenta diferente. Por eso, el trabajo debe comenzar con datos reales, continuar con una reproducción controlada y terminar con la medición de los resultados.

En Calltek analizamos el INP y el resto de Core Web Vitals en webs corporativas, tiendas online y aplicaciones. Identificamos las interacciones que están bloqueando la navegación y aplicamos mejoras en código, arquitectura e infraestructura para conseguir una experiencia más rápida y orientada a conversión.