Las optimizaciones de INP ayudaron a redBus a aumentar las ventas en un 7% aproximadamente
La Web y sus capacidades evolucionan a un ritmo acelerado. Ahora puedes crear experiencias enriquecidas y con todas las funciones en la Web que pueden lograr mucho de lo que las aplicaciones nativas pueden hacer en términos de capacidades.
JavaScript es un impulsor principal de la interactividad en la Web, pero si no se usa con cuidado, las interacciones pueden ser lentas y hacer que los usuarios perciban que tu sitio web no responde o está completamente dañado. Por suerte, la métrica Interaction to Next Paint (INP) se creó para abordar este problema específico de la experiencia del usuario.
El INP mide todas las interacciones que se realizan con una página durante su ciclo de vida y presenta 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 el umbral bueno o por debajo de él, 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 la India, realizó un esfuerzo considerable para mejorar el INP de su sitio web, incluso durante el período 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 la 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 las capacidades del dispositivo, para brindar una mejor experiencia del usuario.
- Optimiza su sitio web para que las interacciones sean lo más rápidas posible.
- Asegúrate de que las respuestas de su API sean lo más livianas posible para garantizar una transferencia de datos rápida al frontend.
El viaje
redBus categorizó la latencia de interacción de dos maneras:
- Latencia de interacción causada por el bloqueo de JavaScript en el cliente Cuando las interacciones usan JavaScript en exceso que bloquea el subproceso principal, se retrasa la renderización, lo que afecta el INP de una página.
- Latencia de red causada por llamadas a la API. Si bien la actividad de red no es algo que mida INP, una interacción que dependa de una llamada a una API remota puede parecer lenta en redes más lentas o si las solicitudes generan respuestas grandes.
En un principio, redBus estaba bastante seguro de que el INP de su sitio web sería bueno, pero los datos de la supervisión de usuarios reales (RUM) para esta métrica en el percentil 95 contaban una historia diferente.
Cómo midió redBus la INP
redBus se basó en la biblioteca de JavaScript web-vitals creada por Google para hacer un seguimiento no solo de los INP, sino de todas las métricas importantes de la experiencia del usuario para todas las páginas de su sitio web. Además de la biblioteca de JavaScript web-vitals, redBus usó ELK para analizar los datos de INP que se recopilaron en el frontend.
Sin embargo, la forma en que realizas el seguimiento de la INP de tu sitio web en el campo puede ser muy diferente de la forma en que redBus abordó el problema. Te recomendamos que leas sobre cómo encontrar interacciones lentas en el campo para aprender a hacer un seguimiento del INP de tus sitios web y, luego, cómo reproducirlos en el lab antes de comenzar a optimizar las interacciones.
Una vez que redBus implementó un sistema para hacer un seguimiento de la INP, pudo analizar los datos para comprender mejor dónde se producía la 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 del destino deseado. La interacción para cambiar la fecha en esta página fue lenta y fue un motivo de INP baja.
Además, cuando un usuario se desplaza por las tarifas, se cargan de forma diferida tarifas adicionales desde la API. Aunque el desplazamiento en sí no se tiene en cuenta en la medición de la INP, el objeto de escucha de eventos scroll programa mucho trabajo que debe ejecutarse en el subproceso principal. Este trabajo causaba una contención en el subproceso principal que aumentaba la latencia de interacción, lo que generaba una 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 aplicó el deshabilitador al controlador de eventos
scrollpara reducir la cantidad de veces que se activaría la devolución de llamada del evento en un período determinado. Cuando se disminuyó la frecuencia con la que se ejecutaba la devolución de llamada del eventoscroll, el subproceso principal pudo responder más rápido a las interacciones de los usuarios 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 debe realizarse antes del siguiente fotograma.
Además, se realizaron las siguientes optimizaciones adicionales en la página de resultados de la búsqueda:
- Se recuperaron nuevos lotes de resultados en la penúltima tarjeta de la página de resultados de la búsqueda para mejorar la experiencia del usuario y el rendimiento visual activando la carga diferida antes.
- Se recuperaron menos resultados en cada llamada de red durante la carga diferida. Cuando se redujeron las recuperaciones de 30 a 10 resultados, se observó una reducción en los rangos de INP de 870 a 900 a 350 a 370.
Si bien estos cambios mejoraron significativamente el INP de la página de búsqueda, aún existía el problema en el que el evento change en los campos de entrada de la página de búsqueda llamaba a una función de reducer costosa para actualizar la interfaz de usuario. Esto provocó 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 administró el estado de los componentes de entrada de forma local y lo sincronizó con el almacén de Redux solo cuando se activó el evento blur de una entrada. Este cambio redujo la cantidad de renderizaciones y eliminó la renderización no deseada de la interfaz de usuario llamando al reductor con menos frecuencia.
Con este cambio, el INP de la página mejoró un 72%, lo que generó una experiencia del usuario más rápida y fluida con la que es más probable que los usuarios 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 el INP es una métrica relativamente nueva en comparación con otras Métricas web esenciales, redBus observó mejores resultados comerciales cuando se enfocó 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 describir los problemas de rendimiento del entorno de ejecución en el sitio web de redBus. Sabiendo que se debían realizar mejoras, redBus pudo observar el problema, reproducirlo y usar esa información crucial para realizar optimizaciones que fueron beneficiosas para redBus y su empresa.