Se optimizó la interactividad de las páginas de detalles de productos para lograr una reducción del 90% en el FID máximo potencial 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 de mercado en Brasil, México y Argentina (según la cantidad de visitantes únicos y las vistas de página).
El rendimiento web ha sido un enfoque de la empresa durante mucho tiempo, pero recientemente formó 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 Burkhay, del equipo de arquitectura de frontend de Mercado Libre, para optimizar una de las métricas web esenciales: la demora de la primera entrada (FID) y su proxy de lab, el tiempo de bloqueo total (TBT).
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
Ejecutar 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 que el navegador puede comenzar a procesar los controladores de eventos en respuesta a esa interacción. Es probable que un sitio que ejecute código JavaScript costoso tenga varias tareas largas, lo que afectará negativamente el FID.
Para proporcionar una buena experiencia del usuario, los sitios deben esforzarse por tener un retraso de primera entrada inferior a 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, se descubrió que las páginas de detalles de los productos tenían un FID bajo. En función de esa información, decidieron enfocar 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 optimizar la interactividad sin interferir en la funcionalidad valiosa.
Mide la interactividad de las páginas de detalles de los productos
El FID requiere un usuario real y, por lo tanto, no se puede medir en el lab. Sin embargo, la métrica Total Blocking Time (TBT) se puede medir en el laboratorio, se correlaciona bien con el FID en el campo y también captura los problemas que afectan la interactividad.
En el siguiente seguimiento, por ejemplo, mientras que el tiempo total dedicado a ejecutar 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 porciones de cada tarea que supera los 50 ms):
Mercado Libre tomó el TBT como métrica de proxy en el lab para medir y mejorar la interactividad de las páginas de detalles de los productos en el mundo real.
Este es el enfoque general que adoptaron:
- Usa WebPageTest para determinar exactamente qué secuencias de comandos mantenían ocupado el subproceso principal en un dispositivo real.
- Usa Lighthouse para determinar el impacto de los cambios en el máximo retraso de primera entrada posible (FID máximo).
Usa WebPageTest para visualizar tareas largas
WebPageTest (WPT) es una herramienta de rendimiento web que te permite ejecutar pruebas en dispositivos reales en diferentes ubicaciones del mundo.
Mercado Libre usó WPT para reproducir la experiencia de sus usuarios eligiendo un tipo de dispositivo y una ubicación similares a los usuarios reales. Específicamente, eligieron un dispositivo Moto 4G y Dulles, Virginia, porque querían aproximarse a la experiencia de los usuarios de Mercado Libre en México. Cuando observó la vista del subproceso principal de WPT, Mercado Libre descubrió que había varias tareas largas consecutivas que bloqueaban el subproceso principal durante 2 segundos:
Al analizar la cascada correspondiente, descubrieron que una parte considerable de esos dos segundos provenía de su módulo de análisis. El tamaño del paquete principal de la aplicación era grande (950 KB) y tardaba mucho en analizarse, compilarse y ejecutarse.
Usa Lighthouse para determinar la FID potencial máxima
Lighthouse no te permite elegir entre diferentes dispositivos y ubicaciones, pero es una herramienta muy útil para diagnosticar sitios y obtener recomendaciones de rendimiento.
Cuando ejecutó Lighthouse en las páginas de detalles de los productos, Mercado Libre descubrió que el FID máximo potencial era la única métrica marcada en rojo, con un valor de 1710 ms.
En función de esto, Mercado Libre se propuso mejorar su puntuación de FID máxima potencial en una herramienta de laboratorio como Lighthouse y WebPageTest, con la suposición de que estas mejoras afectarían a sus usuarios reales y, por lo tanto, se mostrarían en herramientas de supervisión de usuarios reales, como el Informe sobre la experiencia del usuario en 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 que consumía mucha CPU que no era fundamental para que el módulo funcionara y, por lo tanto, se podía quitar de forma segura. Esto generó una reducción del 2% en JavaScript para todo el sitio.
Después de eso, comenzaron a trabajar en mejorar el tamaño general del paquete:
Mercado Libre usó webpack-bundle-analyzer para detectar oportunidades de optimización:
- Inicialmente, requerían el módulo Lodash completo. Se reemplazó por un requisito por método para cargar solo un subconjunto de Lodash en lugar de toda la biblioteca y se usó junto con lodash-webpack-plugin para reducir Lodash aún más.
También aplicaron las siguientes optimizaciones de Babel:
- Usar @babel/plugin-transform-runtime para volver a usar los ayudantes de Babel en todo el código y reducir considerablemente el tamaño del paquete
- Usa babel-plugin-search-and-replace para reemplazar tokens en el momento de la compilación, de modo que se quite un archivo de configuración grande dentro del paquete principal.
- Se agregó babel-plugin-transform-react-remove-prop-types para ahorrar algunos bytes adicionales quitando los tipos de propiedades.
Como resultado de estas optimizaciones, el tamaño del paquete se redujo aproximadamente un 16%.
Mide el impacto
Los cambios redujeron las tareas largas consecutivas de Mercado Libre de dos segundos a uno:
Lighthouse mostró una reducción del 57% en el máximo retraso de primera entrada posible:
Segunda iteración
El equipo siguió analizando las 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., quitando dependencias duplicadas en los diferentes módulos).
- Aplica la división de código a nivel del 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 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 de WebPageTest resultante mostró fragmentos aún más pequeños de ejecución de JS:
Además, el tiempo de FID potencial máximo en Lighthouse se redujo un 60%adicional:
Visualiza el progreso de los usuarios reales
Si bien las herramientas de pruebas de laboratorio, como WebPageTest y Lighthouse, son excelentes para iterar en 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 la experiencia que tienen los usuarios de Chrome en el mundo real con los destinos populares de la Web. Para obtener los datos del informe, puedes ejecutar consultas en BigQuery, PageSpeedInsights o la API de CrUX.
El panel de CrUX es una forma 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 aportan a sus usuarios. Mientras continúan aplicando varias optimizaciones en todo el sitio, incluida la prefetching 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 aún más el tiempo de bloqueo total (TBT) y, a través de un proxy, el FID. Estas optimizaciones incluyen lo siguiente:
- Iteración en la solución de división de código
- Mejora la ejecución de secuencias de comandos de terceros.
- Se realizaron mejoras continuas en el empaquetado de recursos a nivel del empaquetador (webpack).
Mercado Libre tiene una visión integral del rendimiento, por lo que, mientras continúa optimizando la interactividad en el sitio, también comenzó a evaluar las oportunidades de mejora en las otras dos Métricas web esenciales actuales: LCP (Largest Contentful Paint) y CLS (Cumulative Layout Shift).