Se optimizó la interactividad de las páginas de detalles del producto para lograr una reducción del 90% en el FID potencial máximo en Lighthouse y una mejora del 9% en el FID en el Informe sobre la experiencia del usuario en Chrome.
Mercado Libre es el ecosistema de comercio electrónico y pagos más grande de América Latina. Está presente en 18 países y es líder del mercado en Brasil, México y Argentina (en función de los visitantes únicos y las vistas de página).
El rendimiento web ha sido un objetivo de la empresa durante mucho tiempo, pero hace poco formaron un equipo para supervisar el rendimiento y aplicar optimizaciones en diferentes partes del sitio.
En este artículo, se resume el trabajo que realizaron Guille Paz, Pablo Carminatti y Oleh Burrkhay, del equipo de arquitectura de frontend de Mercado Libre, para optimizar una de las Métricas web esenciales: Retraso de primera entrada (FID) y su proxy de lab, el Tiempo de bloqueo total (TBT).
El 90%
Reducción del FID potencial máximo en Lighthouse
9%
Más usuarios perciben el FID como "rápido" en CrUX
Tareas largas, retraso de primera entrada y tiempo de bloqueo total
La ejecución de código JavaScript costoso puede generar tareas largas, que son aquellas que se ejecutan durante más de 50 ms en el subproceso principal del navegador.
El FID (retraso de primera entrada) mide el tiempo que transcurre desde que un usuario interactúa por primera vez con una página (p.ej., cuando hace clic en un vínculo) hasta el momento en que el navegador puede comenzar a procesar controladores de eventos en respuesta a esa interacción. Es probable que un sitio que ejecuta código JavaScript costoso tenga varias tareas largas, lo que generará un impacto negativo en el FID.
Para brindar una buena experiencia del usuario, los sitios deben esforzarse por tener un retraso de primera entrada de menos de 100 milisegundos:
Si bien el sitio de Mercado Libre tenía un buen rendimiento en la mayoría de las secciones, en el Informe de experiencia del usuario de Chrome, las páginas de detalles de los productos tenían un FID deficiente. A partir de esa información, decidieron centrar sus esfuerzos en mejorar la interactividad de las páginas de productos del sitio.
Estas páginas permiten al usuario realizar interacciones complejas, por lo que el objetivo era la optimización de la interactividad, sin interferir en una funcionalidad valiosa.
Mide la interactividad de las páginas de detalles de productos
FID requiere un usuario real y, por lo tanto, no se puede medir en el lab. Sin embargo, la métrica Tiempo de bloqueo total (TBT) se puede medir en función de labs, se correlaciona bien con los FID en el campo y también capta los problemas que afectan la interactividad.
Por ejemplo, en el siguiente seguimiento, si bien el tiempo total dedicado a la ejecución de tareas en el subproceso principal es de 560 ms, solo 345 ms de ese tiempo se consideran tiempo de bloqueo total (la suma de las partes de cada tarea que supera los 50 ms):
Mercado Libre tomó TBT como métrica proxy en el lab para medir y mejorar la interactividad de las páginas de detalles de productos en el mundo real.
Este es el enfoque general que adoptaron:
- Usa WebPageTest para determinar con exactitud qué secuencias de comandos mantenían el subproceso principal ocupado en un dispositivo real.
- Usa Lighthouse para determinar el impacto de los cambios en Posible retraso de primera entrada máximo (FID potencial máximo).
Cómo usar WebPageTest para visualizar tareas largas
WebPageTest (WPT) es una herramienta de rendimiento web que te permite ejecutar pruebas en dispositivos reales en diferentes ubicaciones de todo el mundo.
Mercado Libre usó WPT para reproducir la experiencia de sus usuarios eligiendo un tipo de dispositivo y una ubicación similares a los de los usuarios reales. Específicamente, eligió un dispositivo Moto 4G y Dulles, Virginia, porque querían acercarse a la experiencia de los usuarios de Mercado Libre en México. Al observar la vista de subprocesos principal de WPT, Mercado Libre descubrió que había varias tareas largas consecutivas que bloqueaban el subproceso principal durante 2 segundos:
Cuando analizaron la cascada correspondiente, descubrieron que una parte considerable de esos dos segundos provenía del módulo de estadísticas. El tamaño del paquete principal de la aplicación era grande (950 KB) y tardó mucho tiempo en analizar, compilar y ejecutar.
Usa Lighthouse para determinar el FID potencial máximo
Lighthouse no permite elegir entre diferentes dispositivos y ubicaciones, pero es una herramienta muy útil para diagnosticar sitios y obtener recomendaciones de rendimiento.
Cuando se ejecutaba Lighthouse en las páginas de detalles del producto, Mercado Libre descubrió que el FID potencial máximo era la única métrica marcada en rojo, con un valor de 1,710 ms.
En función de esto, Mercado Libre estableció el objetivo de mejorar su puntuación máxima de FID potencial en una herramienta de laboratorio como Lighthouse y WebPageTest, bajo el supuesto de que estas mejoras afectarían a sus usuarios reales y, por lo tanto, aparecerán en herramientas de supervisión de usuarios reales como el Informe sobre la experiencia del usuario de Chrome.
Optimiza las tareas largas
Primera iteración
En función del seguimiento del subproceso principal, Mercado Libre estableció el objetivo de optimizar los dos módulos que ejecutaban código costoso.
Comenzaron a optimizar el rendimiento del módulo de seguimiento interno. Este módulo contenía una tarea con mucha CPU que no era fundamental para que el módulo funcionara y, por lo tanto, podía quitarse de forma segura. Esto llevó a una reducción del 2% en JavaScript para todo el sitio.
Luego, comenzaron a trabajar en la mejora del tamaño general del paquete:
Mercado Libre usó webpack-bundle-analyzer para detectar oportunidades de optimización:
- Inicialmente, necesitaban el módulo de Lodash completo. Se reemplazó por un requerimiento por método para cargar solo un subconjunto de Lodash en lugar de la biblioteca completa, y se usó junto con lodash-webpack-plugin para reducir Lodash aún más.
También se aplicaron las siguientes optimizaciones de Babel:
- Cómo usar @babel/plugin-transform-runtime para volver a usar los asistentes de Babel en todo el código y reducir considerablemente el tamaño del paquete.
- Usar babel-plugin-search-and-replace para reemplazar tokens en el tiempo de compilación a fin de quitar un archivo de configuración grande dentro del paquete principal
- Agregar babel-plugin-transform-react-remove-prop-types para ahorrar algunos bytes adicionales mediante la eliminación de los tipos de prop
Como resultado de estas optimizaciones, el tamaño del paquete se redujo aproximadamente un 16%.
Mide el impacto
Los cambios disminuyeron las tareas largas consecutivas de Mercado Libre de dos segundos a un segundo:
Lighthouse mostró una reducción del 57% en el potencial de retraso de primera entrada máximo:
Segunda iteración
El equipo siguió indagando en tareas largas para encontrar mejoras posteriores.
En función de esa información, decidieron implementar los siguientes cambios:
- Sigue reduciendo el tamaño del paquete principal para optimizar el tiempo de compilación y análisis (p.ej., quita las dependencias duplicadas en los diferentes módulos).
- Aplica la división de código a nivel de cada componente para dividir JavaScript en fragmentos más pequeños y permitir una carga más inteligente de los diferentes componentes.
- Aplaza la hidratación de los componentes para permitir un uso más inteligente del subproceso principal. Por lo general, esta técnica se conoce como hidratación parcial.
Mide el impacto
El seguimiento resultante de WebPageTest mostró fragmentos aún más pequeños de la ejecución de JS:
Además, el tiempo máximo de FID potencial en Lighthouse se redujo en un 60%adicional:
Visualiza el progreso de usuarios reales
Si bien las herramientas de pruebas de laboratorio, como WebPageTest y Lighthouse, son ideales para iterar soluciones durante el desarrollo, el verdadero objetivo es mejorar la experiencia de los usuarios reales.
El Informe sobre la experiencia del usuario en Chrome proporciona métricas sobre cómo los usuarios de Chrome en el mundo real experimentan los destinos populares de la Web. Los datos del informe se pueden obtener mediante la ejecución de consultas en BigQuery, PageSpeedInsights o la API de CrUX.
El panel de CrUX es una manera fácil de visualizar el progreso de las métricas principales:
Próximos pasos
El rendimiento web nunca es una tarea terminada, y Mercado Libre comprende el valor que estas optimizaciones brindan a los usuarios. Mientras siguen aplicando varias optimizaciones en el sitio, incluida la carga previa en las páginas de fichas de productos, las optimizaciones de imágenes y otras, siguen agregando mejoras a las páginas de fichas de productos para reducir el tiempo de bloqueo total (TBT) y por FID del proxy, incluso más. Estas optimizaciones incluyen lo siguiente:
- Iterar sobre la solución de división de código
- Mejorar la ejecución de secuencias de comandos de terceros
- Mejoras continuas en la agrupación de elementos a nivel del agrupador (webpack)
Mercado Libre tiene una visión integral del rendimiento por lo que, mientras siguen optimizando la interactividad en el sitio, también comenzaron a evaluar oportunidades de mejora en las otras dos Métricas web esenciales actuales: LCP (Largest Contentful Paint) y CLS (Cambio de diseño acumulado) aún más.