El equipo web de Zalando descubrió que integrar la CI de Lighthouse permitió un enfoque proactivo del rendimiento, con verificaciones de estado automatizadas que pueden 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é comenzamos 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 del catálogo afectaba 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 del tiempo de carga de la página
0.7%
Aumento en los ingresos por sesión
El compromiso de la empresa no siempre se traduce en rendimiento
A pesar de que la empresa esté muy comprometida con el rendimiento, si no se establece como un criterio de entrega de productos, puede pasar desapercibido fácilmente. Cuando rediseñamos el sitio web de Zalando en 2020, nos enfocamos en ofrecer funciones nuevas, a la vez que mantuvimos una excelente experiencia del usuario y le aplicamos un cambio de imagen al sitio web con fuentes personalizadas y colores más vibrantes. Sin embargo, cuando el sitio web y la aplicación rediseñados estaban listos para el lanzamiento, las métricas de los usuarios pioneros revelaron que la versión nueva era más lenta. El primer procesamiento de imagen con contenido fue hasta un 53% más lento, y nuestro tiempo de carga se midió hasta un 59% más lento.
La Web en Zalando
El sitio web de Zalando fue creado por un equipo principal que desarrolla un framework, con más de 15 equipos de funciones que contribuyen con microservicios de frontend. Mientras admitíamos la nueva versión, también migramos 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, fue difícil comparar las métricas de rendimiento antes del lanzamiento a usuarios reales, ya que carecíamos de herramientas internas de supervisión del rendimiento del lab. A pesar de que se implementaba todos los días, había 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 estábamos del todo conformes con nuestras métricas internas, ya que no se adaptaban 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 proporcionan un conjunto de métricas condensadas, pero integrales y centradas en el usuario.
Para mejorar el rendimiento antes del lanzamiento, debíamos 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 trabajan en mejoras de rendimiento saben dónde enfocar sus esfuerzos para lograr 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 nodos de Lighthouse, en el que se podían probar los cambios desde nuestro entorno de pruebas. Esto nos proporcionó un ciclo de retroalimentación de rendimiento confiable de alrededor de una hora, que nos permitió mejorar el rendimiento y salvar nuestro lanzamiento.
Cómo enviar comentarios sobre el rendimiento a los desarrolladores en las solicitudes de extracción
No queríamos detenernos allí, ya que queríamos aprovechar la oportunidad para no solo ser reactivos en cuanto al rendimiento, sino también proactivos. No fue muy difícil dar el salto del módulo de nodo de Lighthouse al servidor de Lighthouse CI (LHCI). Elegimos la solución alojada por el cliente para lograr una mejor integración con nuestros servicios existentes de la empresa. Nuestra aplicación de servidor de LHCI se compila como una imagen de Docker, que luego se implementa en nuestro clúster de Kubernetes junto con una base de datos de PostgreSQL y se informa a nuestro GitHub.
Nuestro framework ya proporcionaba algunos comentarios de rendimiento a los desarrolladores, ya que los tamaños de los paquetes de componentes se comparaban con los valores de 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 cumple con los umbrales de rendimiento, con un vínculo a los informes detallados de Lighthouse, como se muestra en las siguientes imágenes.
Cómo ampliar la cobertura de rendimiento
Comenzamos con un enfoque muy pragmático. Actualmente, Lighthouse solo se ejecuta en dos de nuestras páginas más importantes: la página principal y la página de detalles del producto. Por suerte, 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 esto implementado, estamos seguros de que aumentará nuestra cobertura de rendimiento.
Ahora tenemos mucha más confianza cuando compilamos versiones más grandes, y los desarrolladores pueden disfrutar de un ciclo de retroalimentación mucho más corto sobre el rendimiento de su código.