Las optimizaciones de INP ayudaron a redBus a aumentar las ventas en aproximadamente un 7%
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:
- 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.
- Optimizar su sitio web para mantener las interacciones lo más rápidas posible
- 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:
- 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.
- 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.
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.
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
scrollpara 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 eventoscroll, 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.requestAnimationFramele indica al navegador que el trabajo en la devolución de llamada se debe realizar antes del siguiente fotograma.
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.
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.
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.
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.