El equipo web de Zalando descubrió que la integración de Lighthouse CI habilitaba un enfoque proactivo del rendimiento, con verificaciones de estado automatizadas capaces de comparar la confirmación actual con la rama principal para evitar regresiones de rendimiento.
Con más de 35 millones de clientes activos, Zalando es la plataforma de moda en línea líder de Europa. En esta publicación, explicamos por qué empezamos a usar Lighthouse CI, la facilidad de implementación y las ventajas para nuestro equipo.
En Zalando, conocemos la relación entre el rendimiento del sitio web y los ingresos. En el pasado, probamos cómo el aumento artificial del tiempo de carga en las páginas de catálogo afecta los porcentajes de rebote, los porcentajes de conversiones y los ingresos por usuario. Los resultados fueron claros. Una mejora de 100 milisegundos en el tiempo de carga de la página generó una mayor participación con un porcentaje de rebote más bajo y un aumento del 0.7% en los ingresos por sesión.
100ms
Mejora en el tiempo de carga de la página
0,7%
Aumento de los ingresos por sesión
La aceptación de la empresa no siempre se traduce en rendimiento
A pesar de la sólida aceptación del rendimiento dentro de la empresa, si el rendimiento no se establece como un criterio de entrega de productos, puede perderse con facilidad. Cuando rediseñamos el sitio web de Zalando en 2020, nos enfocamos en ofrecer funciones nuevas y, al mismo tiempo, mantener una excelente experiencia del usuario y renovar el sitio web con fuentes personalizadas y colores más intensos. Sin embargo, cuando el sitio web y la app rediseñados estuvieron listos para su lanzamiento, las métricas de usuarios pioneros revelaron que la versión nueva era más lenta. El primer procesamiento de imagen con contenido tuvo una velocidad de hasta un 53% más lenta, y el tiempo de carga de la medición generó un informe de hasta un 59% más lento.
La Web en Zalando
El sitio web de Zalando es creado por un equipo central que desarrolla un framework, con más de 15 equipos de funciones que contribuyen con microservicios de frontend. Además de admitir el nuevo lanzamiento, también pasamos parte de nuestro sitio web a una arquitectura más centralizada.
La arquitectura anterior, llamada Mosaic, incluía una forma de medir el rendimiento de la página con métricas internas. Sin embargo, era difícil comparar las métricas de rendimiento antes del lanzamiento con los usuarios reales, ya que nos faltaban herramientas internas de supervisión del rendimiento del lab. A pesar de realizar implementaciones todos los días, hubo un ciclo de retroalimentación de alrededor de un día para los desarrolladores que trabajaban en mejoras de rendimiento.
Métricas web y Lighthouse al rescate
No estamos completamente satisfechos con nuestras métricas internas, ya que no se adaptaron bien a nuestra nueva configuración. Lo más importante es que no se centraban en la experiencia del cliente. Cambiamos a las Métricas web esenciales, ya que nos proporcionan un conjunto de métricas resumido, pero integral y centrado en el usuario.
Para mejorar el rendimiento antes del lanzamiento, tuvimos que crear un entorno de lab adecuado. Esto proporcionó mediciones reproducibles, además de condiciones de prueba que representan nuestro percentil 90 de datos de campo. Ahora, los ingenieros que trabajaban en mejoras de rendimiento sabían dónde enfocar sus esfuerzos para tener el mayor impacto. Ya usábamos los informes de auditoría de Lighthouse de forma local. Por lo tanto, nuestra primera iteración fue desarrollar un servicio basado en el módulo de nodo de Lighthouse, en el que se podían probar los cambios desde nuestro entorno de etapa de pruebas. Esto nos proporcionó un ciclo de reacción confiable de alrededor de una hora, lo que nos permitió mantener el rendimiento a la par y guardar la versión.
Proporciona comentarios sobre el rendimiento a los desarrolladores sobre las solicitudes de extracción
No queríamos detenernos allí, ya que queríamos aprovechar la oportunidad no solo para reaccionar de forma proactiva con respecto al rendimiento, sino también ser proactivos. Pasar del módulo de nodos de Lighthouse al servidor de Lighthouse CI (LHCI) no fue demasiado difícil. Optamos por la solución autoalojada para poder darnos una mejor integración con los servicios existentes de nuestra empresa. Nuestra aplicación del servidor LHCI se compila como una imagen de Docker, que luego se implementa en el clúster de Kubernetes junto con una base de datos de PostgreSQL y, luego, se informa a nuestro GitHub.
Nuestro framework ya proporcionaba comentarios sobre el rendimiento a los desarrolladores: se comparaban los tamaños de los paquetes de componentes con los valores del umbral en cada confirmación. Ahora podemos informar las métricas de Lighthouse como verificaciones de estado de GitHub. Estos hacen que la canalización de CI falle si no cumplen con los umbrales de rendimiento, con un vínculo a los informes detallados de Lighthouse, como se muestra en las siguientes imágenes.
Extiende la cobertura del rendimiento
Comenzamos con un enfoque muy pragmático. En la actualidad, Lighthouse solo se ejecuta en dos de nuestras páginas más importantes: la página principal y la de detalles del producto. Afortunadamente, Lighthouse CI facilita la extensión de las configuraciones de ejecución. Los equipos de funciones que trabajan en páginas específicas de nuestro sitio web pueden configurar sus aserciones y patrones de URL coincidentes. Con esta implementación, estamos bastante seguros de que nuestra cobertura de rendimiento aumentará.
Ahora tenemos más confianza a la hora de compilar versiones más grandes, y los desarrolladores pueden disfrutar de un ciclo de comentarios mucho más corto sobre el rendimiento de su código.