Zalando की वेब टीम को पता चला कि Lighthouse CI को इंटिग्रेट करने से, परफ़ॉर्मेंस को बेहतर बनाने के लिए पहले से तैयार रणनीति बनाई जा सकती है. साथ ही, स्थिति की अपने-आप होने वाली जांच की मदद से, मुख्य शाखा में मौजूद मौजूदा कमिट की तुलना की जा सकती है, ताकि परफ़ॉर्मेंस में गिरावट न आए.
Zalando, यूरोप का सबसे बड़ा ऑनलाइन फैशन प्लैटफ़ॉर्म है. इस पर 35 करोड़ से ज़्यादा सक्रिय ग्राहक हैं. इस पोस्ट में हमने बताया है कि हमने Lighthouse CI का इस्तेमाल क्यों शुरू किया, इसे लागू करना कितना आसान है, और हमारी टीम को इससे क्या फ़ायदे हुए.
Zalando में, हम वेबसाइट की परफ़ॉर्मेंस और आय के बीच के संबंध को जानते हैं. हमने पहले, कैटलॉग पेजों पर लोड होने में लगने वाले समय को बढ़ाकर यह जांचा था कि इससे बाउंस रेट, कन्वर्ज़न रेट, और हर उपयोगकर्ता से होने वाली आय पर क्या असर पड़ा. नतीजे साफ़ थे. पेज लोड होने में लगने वाले समय को 100 मिलीसेकंड कम करने से, बाउंस रेट में कमी आई और हर सेशन से होने वाली आय में 0.7% की बढ़ोतरी हुई.
100मि॰से॰
पेज लोड होने में लगने वाले समय को कम करना
0.7%
हर सेशन के रेवेन्यू में बढ़ोतरी
कंपनी का खरीदारी में शामिल होना, हमेशा परफ़ॉर्मेंस में बदलाव नहीं करता
कंपनी में परफ़ॉर्मेंस को लेकर ज़्यादा ध्यान देने के बावजूद, अगर परफ़ॉर्मेंस को प्रॉडक्ट डिलीवरी की शर्तों के तौर पर सेट नहीं किया जाता है, तो यह आसानी से छूट सकती है. साल 2020 में, जब हमने Zalando की वेबसाइट को फिर से डिज़ाइन किया था, तब हमने उपयोगकर्ताओं को बेहतरीन अनुभव देने के साथ-साथ, नई सुविधाएं देने पर ध्यान दिया था. साथ ही, हमने वेबसाइट को ज़्यादा आकर्षक बनाने के लिए, कस्टम फ़ॉन्ट और ज़्यादा चटकीले रंगों का इस्तेमाल किया था. हालांकि, जब फिर से डिज़ाइन की गई वेबसाइट और ऐप्लिकेशन रिलीज़ के लिए तैयार हो गए, तो शुरुआती उपयोगकर्ताओं की मेट्रिक से पता चला कि नया वर्शन धीमा था. फ़र्स्ट कॉन्टेंटफ़ुल पेंट में 53% तक ज़्यादा समय लगा. साथ ही, इंटरैक्टिव में लगने वाले समय में 59% तक की कमी आई.
Zalando का वेब वर्शन
Zalando की वेबसाइट को एक फ़्रेमवर्क बनाने वाली मुख्य टीम ने बनाया है. इसमें 15 से ज़्यादा सुविधा टीमें, फ़्रंटएंड माइक्रोसर्विस में योगदान दे रही हैं. नई रिलीज़ के साथ काम करने के साथ-साथ, हमने अपनी वेबसाइट के कुछ हिस्से को ज़्यादा सेंट्रलाइज़्ड आर्किटेक्चर पर भी ट्रांसफ़र किया है.
मोज़ेक नाम के पुराने आर्किटेक्चर में, इन-हाउस मेट्रिक की मदद से पेज की परफ़ॉर्मेंस को मेज़र करने का तरीका शामिल था. हालांकि, असल उपयोगकर्ताओं के लिए रोल आउट करने से पहले, परफ़ॉर्मेंस मेट्रिक की तुलना करना मुश्किल था, क्योंकि हमारे पास इंटरनल लैब की परफ़ॉर्मेंस मॉनिटर करने वाले टूल नहीं थे. हर दिन डिप्लॉय करने के बावजूद, परफ़ॉर्मेंस को बेहतर बनाने पर काम करने वाले डेवलपर को करीब एक दिन का फ़ीडबैक लूप मिलता था.
वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी और Lighthouse की मदद से समस्या हल करना
हम अपनी इन-हाउस मेट्रिक से पूरी तरह संतुष्ट नहीं थे, क्योंकि वे हमारे नए सेटअप के साथ अच्छी तरह काम नहीं करती थीं. सबसे अहम बात यह है कि ये विज्ञापन, ग्राहक अनुभव पर आधारित नहीं थे. हमने वेबसाइट की परफ़ॉर्मेंस की जानकारी पर स्विच किया, क्योंकि इससे मेट्रिक का एक छोटा, लेकिन बेहतर और उपयोगकर्ता के हिसाब से सेट मिलता है.
रिलीज़ से पहले परफ़ॉर्मेंस को बेहतर बनाने के लिए, हमें सही लैब एनवायरमेंट बनाना पड़ा. इससे, फ़ील्ड डेटा के 90वें पर्सेंटाइल को दिखाने वाली टेस्टिंग की स्थितियों के साथ-साथ, दोबारा इस्तेमाल किए जा सकने वाले मेज़रमेंट भी मिले. अब परफ़ॉर्मेंस को बेहतर बनाने पर काम करने वाले इंजीनियरों को पता था कि सबसे ज़्यादा असर डालने के लिए, उन्हें कहां ध्यान देना है. हम पहले से ही स्थानीय तौर पर, लाइटहाउस ऑडिट रिपोर्ट का इस्तेमाल कर रहे थे. इसलिए, हमारा पहला लक्ष्य Lighthouse node module पर आधारित एक सेवा डेवलप करना था, जहां बदलावों की जांच हमारे स्टैजिंग एनवायरमेंट से की जा सके. इससे हमें करीब एक घंटे का भरोसेमंद परफ़ॉर्मेंस फ़ीडबैक लूप मिला, जिसकी मदद से हमने परफ़ॉर्मेंस को बेहतर बनाया और रिलीज़ को बचाया!
डेवलपर को पुल के अनुरोधों पर, परफ़ॉर्मेंस के बारे में सुझाव देना
हम यहीं नहीं रुकना चाहते थे, क्योंकि हमें परफ़ॉर्मेंस को बेहतर बनाने के लिए, सिर्फ़ प्रतिक्रिया देने के बजाय, पहले से तैयार रहने का मौका चाहिए था. Lighthouse नोड मॉड्यूल से Lighthouse CI (LHCI) सर्वर पर स्विच करना बहुत मुश्किल नहीं था. हमने खुद होस्ट करने की सुविधा का विकल्प इसलिए चुना, ताकि हम अपनी मौजूदा कंपनी की सेवाओं के साथ बेहतर तरीके से इंटिग्रेट हो सकें. हमारा LHCI सर्वर ऐप्लिकेशन, Docker इमेज के तौर पर बनता है. इसके बाद, इसे PostgreSQL डेटाबेस के साथ हमारे Kubernetes क्लस्टर में डिप्लॉय किया जाता है. साथ ही, इसकी रिपोर्ट हमारे GitHub पर भेजी जाती है.
हमारा फ़्रेमवर्क, डेवलपर को परफ़ॉर्मेंस के बारे में कुछ सुझाव पहले से ही दे रहा था— हर कमिट पर कॉम्पोनेंट बंडल के साइज़ की तुलना थ्रेशोल्ड वैल्यू से की जा रही थी. अब हम Lighthouse मेट्रिक को GitHub पर स्टेटस की जांच के तौर पर रिपोर्ट कर सकते हैं. अगर ये परफ़ॉर्मेंस थ्रेशोल्ड को पूरा नहीं करते हैं, तो सीआई पाइपलाइन काम नहीं करती. साथ ही, इनमें Lighthouse की ज़्यादा जानकारी वाली रिपोर्ट का लिंक होता है, जैसा कि नीचे दी गई इमेज में दिखाया गया है.
परफ़ॉर्मेंस कवरेज को बढ़ाना
हमने बहुत ही व्यावहारिक तरीके से शुरुआत की. फ़िलहाल, लाइटहाउस सिर्फ़ हमारे दो सबसे अहम पेजों पर काम करता है: होम पेज और प्रॉडक्ट की जानकारी वाला पेज. सौभाग्य से, Lighthouse CI की मदद से, रन कॉन्फ़िगरेशन को आसानी से बढ़ाया जा सकता है. हमारी वेबसाइट के खास पेजों पर काम करने वाली सुविधा टीमें, मैच करने वाले यूआरएल पैटर्न और दावों को सेट अप कर सकती हैं. हमें पूरा भरोसा है कि इस सुविधा के लागू होने के बाद, हमारी परफ़ॉर्मेंस कवरेज बढ़ेगी.
अब हम बड़ी रिलीज़ बनाते समय ज़्यादा भरोसेमंद हैं. साथ ही, डेवलपर को अपने कोड की परफ़ॉर्मेंस के बारे में कम समय में फ़ीडबैक मिल सकता है.