Il team web di Zalando ha scoperto che l'integrazione di Lighthouse CI ha consentito un approccio proattivo al rendimento, con controlli automatici dello stato in grado di confrontare il commit corrente con il ramo principale per evitare regressioni del rendimento.
Con oltre 35 milioni di clienti attivi, Zalando è la piattaforma di moda online leader in Europa. In questo post spieghiamo perché abbiamo iniziato a utilizzare Lighthouse CI, la facilità di implementazione e i vantaggi per il nostro team.
Zalando conosce la relazione tra il rendimento del sito web e le entrate. In passato, abbiamo testato in che modo l'aumento artificiale del tempo di caricamento sulle pagine del catalogo ha influito sulle frequenze di rimbalzo, sui tassi di conversione e sulle entrate per utente. I risultati sono stati chiari. Un miglioramento del tempo di caricamento della pagina di 100 millisecondi ha aumentato il coinvolgimento con una frequenza di rimbalzo inferiore e un aumento delle entrate per sessione dello 0,7%.
100ms
Miglioramento del tempo di caricamento della pagina
0,7%
Aumento delle entrate per sessione
Il coinvolgimento dell'azienda non si traduce sempre in un buon rendimento
Nonostante il forte sostegno del rendimento all'interno dell'azienda, se il rendimento non è impostato come criterio di invio del prodotto puoi facilmente perderlo di vista. Quando abbiamo ridisegnato il sito web di Zalando nel 2020, abbiamo puntato su nuove funzionalità, mantenendo un'esperienza utente eccellente e rinnovando il sito web con caratteri personalizzati e colori più vivaci. Tuttavia, quando il sito web e l'app riprogettati erano pronti per il lancio, le metriche relative agli early adopter hanno rivelato che la nuova versione era più lenta. First Contentful Paint era fino al 53% più lento, mentre il tempo di interattività misurato era fino al 59% più lento.
Il web su Zalando
Il sito web di Zalando è creato da un team di base che sviluppa un framework, con oltre 15 team di funzionalità che contribuiscono con microservizi frontend. Oltre a supportare la nuova release, abbiamo anche eseguito la transizione di parte del nostro sito web a un'architettura più centralizzata.
L'architettura precedente, chiamata Mosaic, includeva un modo per misurare il rendimento delle pagine con metriche interne. Tuttavia, era difficile confrontare le metriche sul rendimento prima dell'implementazione per gli utenti reali, poiché non disponevamo di strumenti di monitoraggio del rendimento interni al laboratorio. Nonostante il deployment giornaliero, è stato necessario un ciclo di feedback di circa un giorno per gli sviluppatori che si occupano di miglioramenti del rendimento.
Web Vitals e Lighthouse in soccorso
Non eravamo del tutto soddisfatti delle nostre metriche interne, in quanto non si adattavano bene alla nuova configurazione. Ancora più importante, non erano incentrate sull'esperienza dei clienti. Abbiamo adottato Core Web Vitals poiché forniscono un insieme di metriche condensate, ma complete e incentrate sull'utente.
Per migliorare le prestazioni prima del rilascio, abbiamo dovuto creare un adeguato ambiente di laboratorio. Ciò ha fornito misurazioni riproducibili, oltre a condizioni di test che rappresentano il 90° percentile dei dati sul campo. Ora gli ingegneri che si occupano di miglioramenti delle prestazioni sanno su cosa concentrare i loro sforzi per ottenere il massimo impatto. Utilizzavamo già i report di controllo di Lighthouse a livello locale. Pertanto, la nostra prima iterazione è stata sviluppare un servizio basato sul modulo del nodo Lighthouse, in cui le modifiche potevano essere testate dal nostro ambiente di gestione temporanea. Questo ci ha fornito un ciclo di feedback sul rendimento affidabile di circa un'ora, che ci ha permesso di migliorare il rendimento e salvare la nostra release.
Fornire feedback sul rendimento agli sviluppatori sulle richieste pull
Non volevamo fermarci qui, poiché volevamo cogliere l'opportunità di non essere solo reattivi nei confronti del rendimento, ma anche proattivi. Il passaggio dal modulo del nodo Lighthouse al server Lighthouse CI (LHCI) non è stato troppo difficile. Abbiamo optato per la soluzione self-hosted per ottenere una migliore integrazione con i nostri servizi aziendali esistenti. La nostra applicazione server LHCI viene creata come immagine Docker, che viene poi implementata nel nostro cluster Kubernetes insieme a un database PostgreSQL e genera report sul nostro GitHub.
Il nostro framework forniva già agli sviluppatori alcuni feedback sul rendimento: le dimensioni dei bundle di componenti venivano confrontate con i valori di soglia a ogni commit. Ora siamo in grado di generare report sulle metriche di Lighthouse come controlli dello stato di GitHub. Questi valori causano il fallimento della pipeline CI se non soddisfano le soglie di rendimento, con un link ai report dettagliati di Lighthouse, come mostrato nelle immagini seguenti.
Estensione della copertura del rendimento
Abbiamo iniziato con un approccio molto pragmatico. Al momento Lighthouse viene eseguito solo su due delle nostre pagine più importanti: la home page e la pagina dei dettagli prodotto. Fortunatamente, Lighthouse CI semplifica l'estensione delle configurazioni di esecuzione. I team di funzionalità che lavorano su pagine specifiche del nostro sito web sono in grado di configurare il pattern URL e le asserzioni corrispondenti. Con queste misure in atto, siamo abbastanza certi che la nostra copertura del rendimento aumenterà.
Ora siamo molto più sicuri quando creiamo release più grandi e gli sviluppatori possono usufruire di un ciclo di feedback molto più breve sul rendimento del loro codice.