Il team web di Zalando ha riscontrato che l'integrazione di Lighthouse CI ha consentito un approccio proattivo al rendimento, con controlli automatici dello stato in grado di confrontare l'attuale commit con il ramo principale per evitare regressioni delle prestazioni.
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.
In Zalando, conosciamo il rapporto tra il rendimento del sito web e le entrate. In passato, abbiamo testato in che modo l'aumento artificiale del tempo di caricamento delle pagine del catalogo influisce sulle frequenze di rimbalzo, sui tassi di conversione e sulle entrate per utente. I risultati sono stati chiari. Un miglioramento del tempo di caricamento delle pagine di 100 millisecondi ha portato a un aumento del coinvolgimento con una frequenza di rimbalzo inferiore e un aumento dello 0,7% delle entrate per sessione.
100ms
Miglioramento del tempo di caricamento della pagina
0,7%
Aumento delle entrate per sessione
L'impegno dell'azienda non si traduce sempre in rendimento
Nonostante l'elevato contributo in termini di rendimento all'interno dell'azienda, se le prestazioni non sono impostate come criterio di distribuzione del prodotto, possono facilmente sfuggire. Quando abbiamo riprogettato il sito web di Zalando nel 2020, ci siamo concentrati sull'offerta di nuove funzionalità, mantenendo al contempo un'esperienza utente eccellente e applicando un restyling del sito web con caratteri personalizzati e colori più vivaci. Tuttavia, quando l'app e il sito web rinnovati erano pronti per il rilascio, le metriche degli early adopter hanno rivelato che la nuova versione era più lenta. First Contentful Paint è più lento del 53% e il tempo misurato all'interattività ha riportato una velocità fino al 59% più lenta.
Il web su Zalando
Il sito web di Zalando è creato da un team principale che sviluppa un framework, con più di 15 team delle funzionalità che contribuiscono ai microservizi di frontend. Pur supportando la nuova release, abbiamo anche trasferito parte del nostro sito web a un'architettura più centralizzata.
L'architettura precedente, denominata Mosaico, includeva un modo per misurare le prestazioni delle pagine con metriche interne. Tuttavia, era difficile confrontare le metriche delle prestazioni prima dell'implementazione per utenti reali, perché mancavano gli strumenti di monitoraggio delle prestazioni dei lab interni. Nonostante il deployment venga eseguito ogni giorno, gli sviluppatori avevano un ciclo di feedback di circa un giorno che lavorava ai miglioramenti delle prestazioni.
Web Vitals e Lighthouse in soccorso
Non siamo del tutto soddisfatti delle nostre metriche interne, che non si sono adattate bene alla nuova configurazione. Ancora più importante, non erano incentrati sulla customer experience. Siamo passati ai Segnali web essenziali, che forniscono un insieme di metriche condensato, ma completo e incentrato sull'utente.
Per migliorare le prestazioni prima del rilascio, dovevamo creare un ambiente di lab adeguato. Ciò ha fornito misurazioni riproducibili, oltre alle condizioni di test che rappresentavano il nostro 90° percentile di dati sul campo. Gli ingegneri che lavoravano al miglioramento delle prestazioni sapevano dove concentrare i loro sforzi per ottenere il massimo impatto. Usavamo già i report di controllo Lighthouse a livello locale. La nostra prima iterazione è stata lo sviluppo di un servizio basato sul modulo nodo Lighthouse, in cui le modifiche potevano essere testate dal nostro ambiente di gestione temporanea. In questo modo, abbiamo generato un ciclo di feedback delle prestazioni affidabile di circa un'ora che ci ha consentito di mantenere le prestazioni alla pari e salvare la release.
Dare agli sviluppatori feedback sulle prestazioni in merito alle richieste pull
Volevamo fermarci qui, perché abbiamo voluto cogliere l'occasione non solo per reagire in modo reattivo al rendimento, ma anche per essere proattivi. Passare dal modulo del nodo Lighthouse al server Lighthouse CI (LHCI) non è stato troppo difficile. Abbiamo optato per la soluzione in hosting autonomo per migliorare l'integrazione con i servizi aziendali esistenti. L'applicazione server LHCI viene creata come immagine Docker, di cui viene eseguito il deployment nel cluster Kubernetes insieme a un database PostgreSQL e poi viene generato report su GitHub.
Il nostro framework forniva già agli sviluppatori un feedback sulle prestazioni: le dimensioni dei bundle dei componenti venivano confrontate con i valori di soglia per ogni commit. Ora possiamo segnalare le metriche di Lighthouse come controlli dello stato di GitHub. Questo causa un errore della pipeline CI se non soddisfa le soglie di prestazioni, con un link ai report Lighthouse dettagliati come mostrato nelle immagini seguenti.
Estensione della copertura del rendimento
Abbiamo iniziato con un approccio molto pragmatico. Al momento Lighthouse funziona solo su due delle nostre pagine più importanti: la home page e la pagina dei dettagli del prodotto. Fortunatamente, Lighthouse CI semplifica l'estensione delle configurazioni di esecuzione. I team incaricati della funzionalità che lavorano su pagine specifiche del nostro sito web sono in grado di impostare asserzioni e pattern URL corrispondenti. Con questa impostazione, siamo abbastanza sicuri che la nostra copertura del rendimento aumenterà.
Ora siamo molto più sicuri quando creiamo release più grandi e gli sviluppatori possono avere un ciclo di feedback molto più breve sulle prestazioni del loro codice.