Mail.ru के होम पेज पर वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी को बेहतर बनाने के लिए कई महीनों तक मेहनत करने की वजह से, कुल लेआउट शिफ़्ट (सीएलएस) में 75वें पर्सेंटाइल में 60% की बढ़ोतरी हुई. इससे, सेशन के औसत समय में 2.7% और मुख्य सेक्शन के कन्वर्ज़न रेट में 10% से ज़्यादा की बढ़ोतरी हुई.
हमने शुरुआत कहां से की थी
Mail.ru रशियन भाषा में इंटरनेट पर सबसे अहम ई-मेल सेवाओं में से एक है. साथ ही, यह ट्रैफ़िक के मामले में रूस की टॉप पांच साइटों में से एक है. Mail.ru कई लोगों के लिए एक अहम संसाधन है. उसे हर महीने कई करोड़ विज़िट मिलती हैं और यह एक ऐसा पोर्टल है जहां से लोग ईमेल, समाचार, सोशल मीडिया, परफ़ॉर्मेंस इंटरनेट खोज वगैरह को ऐक्सेस कर सकते हैं.
Mail.ru अपनी वेबसाइट पर आने वाले लोगों को अच्छी क्वालिटी का अनुभव देना चाहता था. इसलिए, वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी को बेहतर बनाने के लिए काम किया जा रहा है. हमारी ऑप्टिमाइज़ेशन रणनीति पर चर्चा करने से पहले, Mail.ru के होम पेज की कुछ तकनीकी जानकारी पर ध्यान देना चाहिए.
यह प्रोजेक्ट काफ़ी पहले हमारे इन-हाउस टेंप्लेटिंग इंजन फ़ेस्ट का इस्तेमाल करके बनाया गया था. हालांकि, हमने 2019 में Svelte 3 पर माइग्रेट करना शुरू किया.
Svelte प्रतिक्रिया को इस तरह लागू करता है कि वर्चुअल DOM का इस्तेमाल नहीं करता. इस वजह से, साइट पर कम संसाधनों का इस्तेमाल होता है. Svelte का तरीका, इस्तेमाल नहीं किए गए फ़ंक्शन को प्रोडक्शन बंडल से हटा देता है. ऐसा इसलिए, क्योंकि फ़ंक्शन का इस्तेमाल न करने पर, उन्हें लागू करने वाला कोड कंपाइलर से जनरेट नहीं होता. कंपाइलेशन के दौरान, इस्तेमाल न किया गया कोड हटा दिया जाता है. इससे बंडल छोटे हो जाते हैं. इससे पेज शुरू होने के दौरान टोटल ब्लॉकिंग टाइम (टीबीटी) को कम करने में मदद मिल सकती है.
परफ़ॉर्मेंस मेट्रिक ट्रैक करना
वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी को ऑप्टिमाइज़ करने से पहले, फ़ील्ड में परफ़ॉर्मेंस का आकलन करना ज़रूरी है. वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी देने से पहले, हम अपने इंटरनल परफ़ॉर्मेंस डैशबोर्ड में, फ़र्स्ट कॉन्टेंटफ़ुल पेंट (एफ़सीपी) जैसी अन्य मेट्रिक को ट्रैक करते थे.
मेट्रिक कलेक्शन की स्क्रिप्ट में बदलाव किया गया, ताकि वेबसाइट की परफ़ॉर्मेंस की जानकारी इकट्ठा की जा सके और विज़ुअलाइज़ेशन के लिए उसे हमारे परफ़ॉर्मेंस डैशबोर्ड में भेजा जा सके. Google के सुझावों को ध्यान में रखते हुए, हमारी स्क्रिप्ट मेट्रिक पाने के लिए Performance तभी एपीआई इस्तेमाल करती है, जो कि Mail.ru के अंदर यूनिवर्सल फ़्रंटएंड "प्लैटफ़ॉर्म" का हिस्सा है.
डैशबोर्ड में उपयोगकर्ताओं के लिए ये मेट्रिक दिखाई गई (15-21 मार्च, 2021 के हफ़्ते के लिए औसत मान):
| मेट्रिक ग्रुप का नाम | वेबसाइट की परफ़ॉर्मेंस के बारे में जानकारी | वेबसाइट की परफ़ॉर्मेंस की अन्य जानकारी | |||||
|---|---|---|---|---|---|---|---|
| मेट्रिक का नाम | एलसीपी | एफ़आईडी | सीएलएस | एफ़सीपी | टीबीटी | टीटीआई | |
| वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी के थ्रेशोल्ड के मुताबिक उपयोगकर्ताओं का प्रतिशत | अच्छा | 52% | 92% | 33% | 35% | 42% | 43% |
| सुधार की ज़रूरत | 19% | 5% | 23% | 38% | 16% से ज़्यादा हुई | 25% | |
| कमज़ोर | 29% से ज़्यादा हुई | 3% | 44% से ज़्यादा हुई | 27% | 42% | 32% से ज़्यादा हुई | |
वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी में सुधार करना
वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी देने वाली मेट्रिक को बेहतर बनाने के लिए, बहुत सारे दिशा-निर्देश मौजूद हैं. हालांकि, हर प्रोजेक्ट की चुनौतियां अलग-अलग होती हैं. Mail.ru के होम पेज के लिए, इन अवसरों की पहचान की गई है:
- सीएलएस को कम करने के लिए, विज्ञापन बैनर के लिए प्लेसहोल्डर लागू करना.
- सबसे बड़े कॉन्टेंटफ़ुल पेंट (एलसीपी) को कम करने के लिए, सर्वर-साइड रेंडरिंग (एसएसआर) का इस्तेमाल करना.
- एलसीपी और फ़र्स्ट इनपुट डिले (एफ़आईडी) को कम करने के लिए, कोड को अलग-अलग हिस्सों में बांटना.
सीएलएस में सुधार के लिए कंकाल
Mail.ru के होम पेज के लिए सीएलएस, सबसे खराब परफ़ॉर्मेंस वाली फ़ील्ड मेट्रिक में से एक थी. Chrome के DevTools के परफ़ॉर्मेंस पैनल में इस पेज की प्रोफ़ाइल से यह पता चला कि समस्या विज्ञापनों के सोर्स से आई थी. लेआउट को बेहतर बनाने के लिए, हमारी टीम ने प्लेसहोल्डर का इस्तेमाल करने का फ़ैसला लिया, ताकि विज्ञापनों के लोड होने से पहले ही उनके लिए जगह बनाई जा सके.
प्लेसहोल्डर लागू करते समय, पहला चरण उस कॉन्टेंट के डाइमेंशन तय करना है जो उनकी जगह लेगा. अच्छी बात यह है कि Mail.ru के होम पेज के डेस्कटॉप वर्शन में, विज्ञापनों के लिए साइज़ का पूरी जानकारी मौजूद है. डिज़ाइन टीम से बात करने के बाद, SVG-ऐनिमेट किए गए यूज़र इंटरफ़ेस (यूआई) के कंकाल, प्लेसहोल्डर के तौर पर इस्तेमाल किए गए. ऐसा इसलिए किया गया, क्योंकि इनकी मदद से, कॉन्टेंट लोड होने में लगने वाला अनुमानित समय कम हो जाता है.
एसएसआर की वापसी
फ़ेस्ट से Svelte तक के ट्रांज़िशन की प्रोसेस को आसान बनाने के लिए, हमने फिर से शुरू करने के बजाय, मौजूदा प्रोजेक्ट को बार-बार दोहराया. मार्च 2021 तक, हमने ज़्यादातर फ़्रंटएंड को Svelte पर माइग्रेट कर दिया था. आखिर में, हमने बैकएंड परफ़ॉर्मेंस से जुड़ी समस्याओं की जांच करके, उन्हें ठीक करके, एसएसआर को प्रोडक्शन ऐप्लिकेशन में शामिल कर दिया.
एसएसआर को लागू करने के बाद, टीम को सीएलएस रिग्रेशन की वजह का पता चला, लेकिन शुरुआत में उस पर नज़र नहीं पड़ी: पेज पर पहली कॉन्टेंट को रेंडर करते समय, खबर वाले सेक्शन को शामिल नहीं किया गया था. सर्वर से मिले पेज मार्कअप की शुरुआती पेंटिंग और क्लाइंट पर समाचार सेक्शन शामिल करने में देरी हुई. इस व्यवहार की वजह से, विज्ञापन में उतार-चढ़ाव हुआ, जिससे सीएलएस की स्थिति खराब हो गई.
हालांकि, Chrome के DevTools में लेआउट शिफ़्ट इवेंट दिखाए गए हैं, लेकिन पहले हमें इसकी वजह नहीं मिली. हालांकि, एसएसआर खुद समस्या नहीं थी, लेकिन बाद में समाधान खोजने में इससे मदद मिली. पेंटिंग में देरी के लिए ज़िम्मेदार कोड को ठीक करने से, समाचार कॉम्पोनेंट का लेआउट बेहतर तरीके से काम करता है.
एसएसआर का सीएलएस पर असर पड़ सकता है. वह है हाइड्रेशन से पहले और बाद में कॉम्पोनेंट की मूवमेंट, जिससे लेआउट शिफ़्ट हो सकते हैं. हमें खास तौर पर मोबाइल वर्शन पर यह समस्या मिली. इसके लिए, हाइड्रेटेड कॉम्पोनेंट के मार्कअप पर खास ध्यान देने की ज़रूरत थी. इस समस्या का एक अच्छा हल यह था कि ज़रूरत पड़ने पर, ज़्यादा से ज़्यादा डिसप्ले लॉजिक को JavaScript से सीएसएस में ट्रांसफ़र कर दिया जाए.
कोड को बांटना और इस्तेमाल न किए गए पॉलीफ़िल
पेज लोड होने की अनुमानित स्पीड को बेहतर बनाने के लिए, एलसीपी और एफ़आईडी की वैल्यू को कम करना ज़रूरी है. ऐसा करने का एक तरीका है, कोड को बांटना. Mail.ru के होम पेज के साथ-साथ हमारी टीम, पोर्टल नेविगेशन के लिए एक विजेट डेवलप कर रही है. फ़िलहाल, यह हमारी कंपनी के कई प्रोजेक्ट में एम्बेड है.
ऐतिहासिक वजहों से, विजेट को पेज की शुरुआत में सिंक्रोनस रूप से लोड होने वाली स्क्रिप्ट के रूप में डाला जाता है. समय के साथ, इस स्क्रिप्ट में पॉलीफ़िल की संख्या में बढ़ोतरी हुई. हमने आधुनिक और लेगसी, दोनों तरह के ब्राउज़र के लिए कोड को बांटने की सुविधा लागू की है. ऐसा, इन पॉलीफ़िल लोड करने से खराब परफ़ॉर्मेंस के असर को कम करने के लिए किया गया है.
हमने मॉडर्न या लेगसी ब्राउज़र के लिए, JavaScript बंडल लोड करने का module/nomodule पैटर्न इस्तेमाल करने का फ़ैसला लिया. ऐसा इसलिए, क्योंकि <script> एलिमेंट के type="module" एट्रिब्यूट से ऐसे ब्राउज़र को टारगेट नहीं किया जा सका जो हमारी ज़रूरतों के हिसाब से मॉडर्न थे. इसकी समस्या को हल करने के लिए, Mail.ru बैकएंड पर आधुनिक ब्राउज़र वर्शन की पहचान करने के लिए एक इन-हाउस टूल का इस्तेमाल करता है. साथ ही, वह उन ब्राउज़र के मुताबिक खुद में बदलाव कर सकता है.
बैकएंड में ब्राउज़र की पहचान हो जाने के बाद, हमने मॉडर्न और लेगसी ब्राउज़र के लिए कोड को अलग-अलग करने की सुविधा लागू की. इसका नतीजा यह हुआ कि मॉडर्न ब्राउज़र के लिए सिंक्रोनस तरीके से लोड किए गए JavaScript विजेट के साइज़ में 43.3% की कमी आई. यह तरीका कुछ दूसरी पोर्टल स्क्रिप्ट पर भी लागू किया गया है.
बंडल के साइज़ में कमी और वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी पर अच्छा असर डालने के साथ-साथ, कोड को बांटने से डेवलपर को बेहतर अनुभव मिलता है. हमारे सिर्फ़ 3.5% उपयोगकर्ता लेगसी ब्राउज़र का इस्तेमाल करते हैं और उसका शेयर नीचे की ओर जा रहा है. इसलिए, कोड को अलग-अलग करने की सुविधा लागू करने से हमारे डेवलपर सभी उपयोगकर्ताओं के लिए लेगसी ब्राउज़र के लिए ज़रूरी पॉलीफ़िल ब्लोट लागू किए बिना, सबसे नए ब्राउज़र एपीआई का इस्तेमाल कर पाए.
नतीजे
ऑप्टिमाइज़ेशन की कोशिश के बाद, हमने अपने फ़ील्ड डेटा में 24 से 30 मई, 2021 के हफ़्ते के लिए औसत वैल्यू देखी:
| मेट्रिक ग्रुप का नाम | वेबसाइट की परफ़ॉर्मेंस के बारे में जानकारी | वेबसाइट की परफ़ॉर्मेंस की अन्य जानकारी | |||||
|---|---|---|---|---|---|---|---|
| मेट्रिक का नाम | एलसीपी | एफ़आईडी | सीएलएस | एफ़सीपी | टीबीटी | टीटीआई | |
| वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी के थ्रेशोल्ड के मुताबिक उपयोगकर्ताओं का प्रतिशत | अच्छा | 58% (+6%) | 93% (+1%) | 93% (+60%) | 43% (+8%) | 49% (+7%) | 51% (+8%) |
| सुधार की ज़रूरत | 18% की संभावित बचत | 4% | 3% | 34% से ज़्यादा हुई | 17% की संभावित बचत | 24% | |
| कमज़ोर | 24% | 3% | 4% | 23% | 34% से ज़्यादा हुई | 25% | |
नीचे दिए गए ग्राफ़ में, "प्लैटफ़ॉर्म" के हिसाब से वेब पेज की परफ़ॉर्मेंस मेट्रिक की वैल्यू में हुए बदलाव दिखाए गए हैं. ग्राफ़ पर दो अहम तारीखों पर ध्यान दें:
- 23 मार्च, 2021: Svelte पर माइग्रेट किए गए आखिरी पेज सेक्शन के साथ इटरेशन की रिलीज़;
- 19 अप्रैल, 2021: रिटर्न किए गए SSR और लेआउट के साथ इटरेशन की रिलीज़ को सही सीएलएस रिग्रेशन के हिसाब से बदला गया.
रूस में मई की छुट्टियों की वजह से, 1 मई से 10 मई के बीच किराये में कमी आ रही है.
"प्लैटफ़ॉर्म" का इस्तेमाल करके मिलने वाले नतीजे, Chrome UX रिपोर्ट (CrUX) में मेट्रिक वैल्यू में बढ़ोतरी के मुताबिक होते हैं.
शुरुआती सुधारों के रोल-आउट से एक हफ़्ते पहले और रोल आउट के एक हफ़्ते बाद की औसत वैल्यू की तुलना करने पर, उपयोगकर्ता के सेशन की अवधि में 2.7% की बढ़ोतरी दिखती है. इसके अलावा, पेज के ज़्यादातर सेक्शन में, कन्वर्ज़न में काफ़ी बढ़ोतरी हुई है. खास तौर पर, Mail.ru ईमेल ऐप्लिकेशन पर कन्वर्ज़न में 11.6%, न्यूज़ सेक्शन के कन्वर्ज़न में 13.5% की बढ़ोतरी हुई है.
181%
अच्छे सीएलएस थ्रेशोल्ड में बढ़ोतरी
2.7%
सेशन की औसत अवधि
13.5%
समाचार सेक्शन की कन्वर्ज़न दर में बढ़ोतरी
इससे हमें सबसे उम्मीद से पता चला कि मार्केटिंग बैनर की क्लिक मिलने की दर (सीटीआर) में 17.4% की बढ़ोतरी हुई. SSR और पहले से लोड किए जाने वाले टैग के लॉन्च होने की वजह से, इसके रेंडर होने के समय में काफ़ी कमी आई.
पेज पर मौजूद बाकी सेक्शन का विश्लेषण करने के बाद, हमें उनमें से ज़्यादातर सेक्शन की परफ़ॉर्मेंस में सुधार दिखा. मौसम और कोरोना वायरस जैसे सेक्शन के लिए भी—जो हमारे पेज पर अहम नहीं हैं—उन्हें कन्वर्ज़न में 9.6% और 9.5% की बढ़ोतरी दिखी.
नतीजा
परफ़ॉर्मेंस को बेहतर बनाना चुनौती भरा है, क्योंकि इसमें ज़्यादा समय तक काम करना पड़ सकता है. आपको समय-समय पर मेट्रिक में होने वाले बदलावों पर नज़र रखनी चाहिए. साथ ही, यह पक्का करना चाहिए कि प्रॉडक्ट की सभी नई सुविधाओं की वजह से, वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी में कोई रिग्रेशन न हो. इसके लिए, हम अपने परफ़ॉर्मेंस बजट में, वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी में होने वाले बदलावों पर नज़र रखते हैं.
सबसे अहम बात यह है कि हमने वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी की अहमियत पर ज़ोर दिया. यह बात हमारी प्रॉडक्ट टीम के सभी सदस्यों को दी गई. इनमें मैनेजर, डिज़ाइनर से लेकर टेस्टर और QA तक शामिल हैं. टीम के हर सदस्य को परफ़ॉर्मेंस मेट्रिक के बारे में पता होना चाहिए. साथ ही, वह उन्हें बेहतर बनाने में सक्षम होना चाहिए. हम नियमित तौर पर, कारोबार की प्रोसेस में परफ़ॉर्मेंस ऑप्टिमाइज़ेशन के मकसद को भी शामिल करते हैं. टीम के सभी सदस्यों के संयुक्त प्रयास से ही उच्च-क्वालिटी वाला उपयोगकर्ता अनुभव सफलतापूर्वक उपलब्ध कराया जा सकता है.