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