Cómo redBus mejoró la métrica Interaction to Next Paint (INP) de su sitio web y aumentó sus ventas un 7%

Las optimizaciones de INP ayudaron a redBus a aumentar las ventas en aproximadamente un 7%

Saurabh Rajpal
Saurabh Rajpal

La Web y sus capacidades evolucionan a un ritmo acelerado. Ahora puedes crear experiencias enriquecidas y con funciones completas en la Web, que te permitirán lograr gran parte de lo que hacen las aplicaciones nativas en términos de capacidades.

JavaScript es uno de los impulsores principales de la interactividad en toda la Web. Sin embargo, si no se usa con cuidado, las interacciones pueden resultar lentas y hacer que los usuarios perciban que tu sitio web no es receptivo o que no funciona por completo. Afortunadamente, se creó la métrica Interacción a la siguiente pintura (INP) para abordar este problema específico de la experiencia del usuario.

INP mide todas las interacciones realizadas con una página durante su ciclo de vida y registra un solo valor que representa la velocidad de un sitio web para responder a las entradas del usuario. En pocas palabras, si el INP de una página está en o por debajo del umbral aceptable, se puede decir que todas las interacciones realizadas con una página son rápidas y confiables.

redBus, un sitio web de reserva y venta de boletos de autobús con sede en India, realizó un gran esfuerzo para mejorar el INP de su sitio web, incluso durante el tiempo en que aún se consideraba una métrica experimental. Como resultado de sus esfuerzos, pudieron aumentar las ventas en un 7%, lo que demuestra una vez más la relación entre el rendimiento web y el estado de la empresa. Esto es lo que hizo redBus para mejorar el INP de su sitio web.

Objetivos principales

Cuando redBus se propuso optimizar el INP de su sitio web, tenía tres objetivos en mente:

  1. Enfócate en la latencia de interacción, independientemente de la velocidad de la red y de las capacidades del dispositivo, para proporcionar una mejor experiencia a los usuarios.
  2. Optimizar su sitio web para mantener las interacciones lo más rápidas posible
  3. Garantizar que las respuestas de su API sean lo más ligeras posible para garantizar una transferencia de datos rápida al frontend

El viaje

redBus categorizó la latencia de interacción de las siguientes dos maneras:

  1. Latencia de interacción causada por el bloqueo de JavaScript en el cliente. Cuando las interacciones usan una cantidad excesiva de JavaScript que bloquea el subproceso principal, el procesamiento se retrasa, lo que afecta el INP de la página.
  2. Latencia de red causada por las llamadas a la API. Si bien la actividad de la red no es algo que INP mide, una interacción que depende de una llamada a una API remota puede resultar lenta en redes más lentas o si las solicitudes generan respuestas de gran tamaño.

En un principio, redBus estaba bastante seguro de que el INP para su sitio web sería bueno, pero los datos de monitoreo de usuario real (RUM) para esta métrica en el percentil 95 eran de una historia diferente.

Cómo redBus midió INP

redBus dependía de la biblioteca de JavaScript de web-vitals creada por Google para realizar un seguimiento no solo de INP, sino de todas las métricas importantes de la experiencia del usuario de todas las páginas de su sitio web. Además de la biblioteca JavaScript de web-vitals, redBus usó ELK para analizar los datos del INP que se recopilaron en el frontend.

Sin embargo, la manera de hacer un seguimiento del INP de tu sitio web en el campo puede ser muy diferente de la manera en que redBus abordó el problema. Te recomendamos que leas cómo encontrar interacciones lentas en el campo para aprender cuál es la mejor manera de hacer un seguimiento de INP en tus sitios web y, luego, reproducirlas en el lab antes de comenzar a optimizar las interacciones.

Una vez que redBus implementó un sistema de seguimiento de INP, pudieron analizar los datos para comprender mejor dónde había interactividad lenta.

Captura de pantalla del sistema de registro ELK que informa los valores de INP para su análisis.
Una captura de pantalla del sistema de registro que usa redBus para analizar los valores de INP recopilados del campo. (Haz clic para obtener una versión de mayor resolución de esta imagen).

casos de uso

Cuando los usuarios buscan tarifas en el sitio web de redBus, pueden cambiar la fecha en la página de búsqueda para filtrar las tarifas seleccionadas para el destino que desean. La interacción para cambiar la fecha en esta página fue lenta y fue la causa de un INP deficiente.

Además, cuando un usuario se desplaza por las tarifas, se cargan de forma diferida tarifas adicionales desde la API. Si bien el desplazamiento no tiene en cuenta la forma en que se mide el INP, el objeto de escucha de eventos scroll programa mucho trabajo que debe ejecutarse en el subproceso principal. Este trabajo generaba conflictos en el subproceso principal que aumentaba la latencia de la interacción, lo que generaba un INP deficiente en la página de búsqueda.

El comportamiento de carga diferida que se utiliza para cargar tarifas adicionales de la API durante el desplazamiento. (Haz clic para obtener una versión de mayor resolución de este video).

Cómo redBus optimizó el INP para la página de búsqueda

Para mejorar el INP de la página de búsqueda, redBus realizó varias optimizaciones:

  • Se anuló el rebote del controlador de eventos scroll para reducir la cantidad de veces que se activaba la devolución de llamada del evento en un período determinado. Al reducir la frecuencia con la que se ejecutaba la devolución de llamada del evento scroll, el subproceso principal pudo responder con mayor rapidez a las interacciones del usuario en la página de búsqueda.
  • El trabajo de renderización resultante se priorizó mediante una devolución de llamada requestAnimationFrame. requestAnimationFrame le indica al navegador que el trabajo en la devolución de llamada se debe realizar antes del siguiente fotograma.
Captura de pantalla del panel de rendimiento en las Herramientas para desarrolladores de Chrome que muestra el sitio web de redBus que activa las devoluciones de llamada de los eventos de desplazamiento que no se rebotan. El resultado es que el subproceso principal se bloquea.
Antes: Los controladores de desplazamiento se activan sin que se aplique desunión a la devolución de llamada del evento. Hay una cantidad considerable de tareas de bloqueo en el subproceso principal, que retrasarán las interacciones.
Captura de pantalla del panel de rendimiento en las Herramientas para desarrolladores de Chrome que muestra el sitio web de redBus que activa las devoluciones de llamada de eventos de desplazamiento que dejaron de rebotar. Como resultado, el subproceso principal se bloquea menos porque los controladores del evento de desplazamiento se activan con mucha menos frecuencia.
Posterior: controladores de desplazamiento que se activan con un proceso de interrupción aplicado. Las devoluciones de llamada de eventos de desplazamiento se activan con menos frecuencia, lo que le brinda al subproceso principal más oportunidades de responder a las interacciones del usuario.

Además, se realizaron las siguientes optimizaciones adicionales en la página de resultados de búsqueda:

  • En la penúltima tarjeta, se recuperaron nuevos lotes de resultados de la página de resultados de búsqueda para mejorar la experiencia del usuario y el rendimiento visual, ya que se activó la carga diferida en un momento anterior.
  • Durante la carga diferida, se recuperaron menos resultados en cada llamada de red. Al reducir las recuperaciones de 30 a 10 resultados, se observó una reducción en los rangos del INP de 870 a 900 a 350 a 370.
El comportamiento de carga diferida que se utiliza para cargar tarifas adicionales de la API durante el desplazamiento. (Haz clic para obtener una versión de mayor resolución de este video).

Si bien estos cambios mejoraron significativamente el INP de la página de búsqueda, todavía existía el problema por el cual el evento change en los campos de entrada de la página de búsqueda llamaba a una función reductora costosa para actualizar la interfaz de usuario. Como consecuencia, se produjo una nueva renderización innecesaria de la interfaz de usuario, lo que afectó el INP de la página.

Los valores de INP se informan en la consola mientras el usuario escribe en un campo de entrada. El valor del INP resultante de 344 observado en un entorno de laboratorio está dentro de los umbrales de “necesitan mejoras”. (Haz clic para obtener una versión de mayor resolución de este video).

Para optimizar esta interacción, redBus administraba el estado de los componentes de entrada de manera local y lo sincronizó con el almacén de Redux solo cuando se activaba el evento blur de una entrada. Este cambio redujo la cantidad de repeticiones y eliminó la representación no deseada de la interfaz de usuario, ya que llamaba al reductor con menos frecuencia.

Se mejoró el INP debido a que se llama con menos frecuencia al reductor cuando se cambia el campo de entrada. (Haz clic para obtener una versión de mayor resolución de este video).

Con este cambio, el INP de la página mejoró un 72%, lo que da como resultado una experiencia del usuario más rápida y fluida, con la que es más probable que interactúen.

Impacto en el negocio

La relación entre el estado de la empresa y el rendimiento de la página es bien conocida. Si bien INP es una métrica relativamente nueva en comparación con otras Métricas web esenciales, redBus observó mejores resultados comerciales al enfocarse en mejorar esta importante métrica de rendimiento centrada en el usuario. El resultado fue un aumento general del 7% en las ventas.

En resumen, INP ayudó a representar los problemas de rendimiento durante el tiempo de ejecución en el sitio web de redBus. Con la certeza de que se debían implementar mejoras, redBus pudo observar el problema, reproducirlo y usar esa información crucial a fin de realizar optimizaciones que fueran beneficiosas para redBus y su negocio.