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