TBT को 30 गुना कम करने और Next.js पर माइग्रेट करने से The Ecomonic Times को आईएनपी कम करने में करीब चार गुना मदद मिली. इसकी वजह से बाउंस दर में 50% की कमी और पेज व्यू में 43% की बढ़ोतरी हुई.
इंटरैक्शन टू नेक्स्ट पेंट (आईएनपी) एक ऐसी मेट्रिक है जो यह आकलन करती है कि वेबसाइट, उपयोगकर्ता के इनपुट के हिसाब से कितनी रिस्पॉन्सिव है. अच्छे रिस्पॉन्स का मतलब है कि पेज, उपयोगकर्ता के इंटरैक्शन का तुरंत जवाब देता है. किसी पेज का आईएनपी जितना कम होगा, वह उपयोगकर्ता के इंटरैक्शन को उतना ही बेहतर तरीके से जवाब दे पाएगा.
मुश्किल शुरुआत
Google ने शुरुआत में आईएनपी को प्रयोग के तौर पर एक मेट्रिक के तौर पर लॉन्च किया था, जिसकी वेबसाइट की परफ़ॉर्मेंस की जानकारी देने वाली मेट्रिक में शामिल होने की संभावना थी. इसके बाद, Economic Times की टीम ने आईएनपी को इसमें शामिल करने से पहले, इसे ठीक करने की चुनौती भरी. ऐसा इसलिए, क्योंकि हमारे कारोबार की मुख्य नीतियों के लिए यह बहुत ज़रूरी है, ताकि उपयोगकर्ताओं को बेहतरीन अनुभव दिया जा सके.
आईएनपी मेट्रिक, अब तक की सबसे मुश्किल मेट्रिक में से एक है. शुरुआत में, यह समझ नहीं आ रहा था कि आईएनपी को असरदार तरीके से कैसे मापा जाए. इससे और भी मुश्किल हो गई, क्योंकि कम्यूनिटी के साथ मदद की कमी थी. इसमें, रीयल यूज़र मॉनिटरिंग (आरयूएम) की सुविधा देने वाली ज़्यादातर कंपनियां भी शामिल थीं, जो अभी तक सहायता नहीं दे रही थीं. हालांकि, हमारे पास Chrome User Experience Report (CrUX), web-vitals JavaScript लाइब्रेरी, और इसके साथ काम करने वाले दूसरे Google RUM टूल थे. इनसे हमें यह पता चला कि आगे की प्रक्रिया का आकलन करते समय हम कहां मौजूद थे. जब हमने शुरुआत की थी, तब ऑरिजिन लेवल पर हमारा आईएनपी, 1,000 मिलीसेकंड के करीब था.
फ़ील्ड में आईएनपी को ठीक करते समय एक बात सामने आई कि टारगेट की जाने वाली लैब मेट्रिक में से एक टोटल ब्लॉकिंग टाइम (टीबीटी) हो सकती है. TBT के पास पहले से ही दस्तावेज़ हैं और समुदाय ने इसका समर्थन किया है. वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी के थ्रेशोल्ड को पूरा करने के बावजूद, हम TBT के पहलुओं के मामले में अच्छा परफ़ॉर्म नहीं कर रहे थे. ऐसा इसलिए, क्योंकि शुरुआत में हमें तीन सेकंड से ज़्यादा लगे थे.
TBT क्या है और इसे बेहतर बनाने के लिए हमने क्या कदम उठाए हैं?
TBT एक लैब मेट्रिक है. इससे पता चलता है कि पेज लोड होने के दौरान, उपयोगकर्ता के इनपुट के लिए वेब पेज कितना रिस्पॉन्सिव है. अगर किसी टास्क को पूरा करने में 50 मिलीसेकंड से ज़्यादा समय लगता है, तो उसे एक लंबा टास्क माना जाता है. साथ ही, 50 मिलीसेकंड के बाद के समय को ब्लॉक करने का समय कहा जाता है.
TBT, पेज लोड के दौरान सभी लंबे टास्क को ब्लॉक करने में लगने वाले समय को जोड़कर कैलकुलेट करता है. उदाहरण के लिए, अगर लोड होने के दौरान दो टास्क ज़्यादा लंबे हैं, तो ब्लॉक करने का समय इस तरह तय किया जाता है:
- टास्क A में 80 मिलीसेकंड (50 मिलीसेकंड से ज़्यादा 30 मिलीसेकंड से ज़्यादा) लगते हैं.
- टास्क B में 100 मिलीसेकंड (50 मिलीसेकंड से ज़्यादा 50 मिलीसेकंड से ज़्यादा) लगते हैं.
पेज का TBT होगा: 80 मिलीसेकंड (30 + 50). TBT जितना कम होगा, उतना ही बेहतर होगा, और TBT INP के साथ अच्छे से संबंध रखता है.
यहां लैब में तुलना करने की सुविधा दी गई है. इसकी मदद से, एक्सपेरिमेंट को बेहतर बनाने से पहले और बाद में इसकी तुलना की जा सकती है:
मुख्य थ्रेड के काम को कम से कम करें
ब्राउज़र का मुख्य थ्रेड, एचटीएमएल को पार्स करने, डीओएम बनाने, और सीएसएस को पार्स करने और स्टाइल को लागू करने के साथ-साथ JavaScript की जांच और उसे लागू करने जैसे सभी काम मैनेज करता है. मुख्य थ्रेड, उपयोगकर्ता के इंटरैक्शन को भी मैनेज करता है. इसका मतलब है कि क्लिक, टैप, और बटन दबाने का तरीका इस्तेमाल किया जाता है. अगर मुख्य थ्रेड में कोई और काम किया जा रहा है, तो हो सकता है कि यह उपयोगकर्ता के इनपुट का बेहतर तरीके से जवाब न दे. इसकी वजह से उपयोगकर्ताओं को खराब अनुभव मिल सकता है.
हमारे पास यह सबसे मुश्किल काम था, क्योंकि हमारे पास ऐसे एल्गोरिदम हैं जो सदस्यता की स्थिति और A/B टेस्टिंग, आंकड़ों वगैरह के लिए तीसरे पक्ष की स्क्रिप्ट के आधार पर विज्ञापन दिखाने के लिए, उपयोगकर्ता की पहचान करते हैं.
हमने शुरुआत में छोटे-छोटे कदम उठाए हैं. जैसे, कारोबार की कम ज़रूरी ऐसेट को लोड करने की प्राथमिकता से बाहर किया जा रहा है. दूसरा, हमने requestIdleCallback का इस्तेमाल गैर-ज़रूरी काम के लिए किया है. इससे टीबीटी को कम करने में मदद मिल सकती है.
if ('requestIdleCallback' in window) {
this.requestIdleCallbackId = requestIdleCallback(fetchMarketsData.bind(this), {timeout: 3000});
} else {
fetchMarketsData(); // Fallback in case requestIdleCallback is not supported
}
हमारा सुझाव है कि requestIdleCallback का इस्तेमाल करते समय, टाइम आउट तय करें. इससे यह पक्का होता है कि अगर दिया गया समय बीत चुका है और कॉलबैक को पहले ही कॉल नहीं किया गया है, तो यह टाइम आउट के तुरंत बाद कॉलबैक को एक्ज़ीक्यूट कर देता है.
स्क्रिप्ट की जांच में लगने वाले समय को कम करें
हम लोड किए जा सकने वाले कॉम्पोनेंट का इस्तेमाल करके, तीसरे पक्ष की लाइब्रेरी को भी लेज़ी लोड करते हैं. हमने Chrome DevTools में कवरेज टूल की मदद से पेज की प्रोफ़ाइल बनाकर, इस्तेमाल नहीं किए गए JavaScript और सीएसएस को भी हटा दिया है. इससे हमें उन क्षेत्रों का पता लगाने में मदद मिली जहां पेज लोड के दौरान कम कोड शिप करने के लिए पेड़ों को हिलाने की ज़रूरत थी. इससे हमें ऐप्लिकेशन के बंडल का शुरुआती साइज़ कम करने में मदद मिली.
डीओएम का साइज़ कम करें
हर लाइटहाउस के हिसाब से, बड़े डीओएम साइज़ से मेमोरी का इस्तेमाल बढ़ जाता है. इससे स्टाइल को रीकैलकुलेशन ज़्यादा समय तक किया जाता है. साथ ही, इससे महंगे लेआउट रीफ़्लो होते हैं.
हमने DOM नोड की संख्या को दो तरीकों से कम किया:
- सबसे पहले, हमने उपयोगकर्ता के अनुरोध पर अपने मेन्यू आइटम को रेंडर (क्लिक करने पर) किया. इससे डीओएम का साइज़ करीब 1,200 नोड तक घटाया गया.
- दूसरा, हमने कम ज़रूरी विजेट को लेज़ी लोड किया.
इन कोशिशों की वजह से, हमने टीबीटी को काफ़ी कम कर लिया और इसी हिसाब से हमारी आईएनपी में करीब 50% की कमी हुई:
उस समय, TBT (और प्रॉक्सी के ज़रिए आईएनपी) को और कम करने के लिए हमारे पास जीत की कोई आसानी नहीं थी, लेकिन हमें पता था कि सुधार की काफ़ी गुंजाइश है. इसी दौरान हमने ज़रूरत के हिसाब से कॉम्पोनेंट को फिर से रेंडर करने से बचने के लिए, हुक का बेहतर इस्तेमाल करने के लिए, Next.js के साथ-साथ ज़रूरत के हिसाब से बनाए गए यूज़र इंटरफ़ेस (यूआई) बॉयलरप्लेट को React के नए वर्शन पर अपग्रेड करने का फ़ैसला लिया.
वेबसाइट के अन्य हिस्सों की तुलना में अक्सर ज़्यादा अपडेट और ट्रैफ़िक कम होने की वजह से, हमने अपने विषय वाले पेजों को Next.js पर माइग्रेट करना शुरू कर दिया. हमने PartyTown के लिए, वेब वर्कर के साथ-साथ मुख्य थ्रेड के अतिरिक्त काम को ऑफ़लोड किया और गैर-ज़रूरी टास्क को कुछ समय के लिए रोकने के लिए requestIdleCallBack जैसी तकनीकों का इस्तेमाल किया.
आईएनपी में सुधार से The Economic Times को कैसे मदद मिली?
ऑरिजिन के लिए, मौजूदा टीबीटी और आईएनपी
इस पोस्ट को पब्लिश करते समय, हमने अपने ऑरिजिन के लिए TBT 120 मिलीसेकंड किया था. जब हमने ऑप्टिमाइज़ेशन की शुरुआत की थी, तब यह 3,260 मिलीसेकंड से कम था. इसी तरह, ऑप्टिमाइज़ेशन की हमारी कोशिशों के बाद, हमारे ऑरिजिन के लिए आईएनपी में 257 मिलीसेकंड थे. पहले यह 1,000 मिलीसेकंड से कम था.
आईएनपी CrUX रुझान
विषय के पेजों पर मिला ट्रैफ़िक, कुल ट्रैफ़िक का काफ़ी छोटा हिस्सा होता है. इसलिए, यह प्रयोग करने के लिए एक आदर्श जगह थी. CrUX और कारोबार को मिले नतीजे बहुत उत्साह बढ़ाने वाले थे. इससे हमें पूरी वेबसाइट पर और बेहतर तरीके से फ़ायदा पाने में मदद मिली.
Akamai mPulse TBT विश्लेषण
हम Akamai mPulse का इस्तेमाल अपने आरयूएम समाधान के तौर पर करते हैं. इससे फ़ील्ड में TBT का पता चलता है. हमें TBT में लगातार कमी देखने को मिली. आईएनपी को कम करने की हमारी कोशिशों के नतीजों की साफ़ तौर पर मैपिंग की गई. जैसा कि नीचे दिए गए स्क्रीनशॉट में देखा जा सकता है, फ़ील्ड में TBT वैल्यू करीब 5 सेकंड से घटकर करीब 200 मिलीसेकंड हो जाती हैं.
कारोबार का नतीजा
कुल मिलाकर, Next.js पर माइग्रेट करने के साथ-साथ TBT को 30 गुना कम करने की हमारी कोशिशों से हमें आईएनपी में करीब चार गुना मदद मिली. इसकी वजह से विषय के पेजों पर बाउंस रेट में 50% की कमी और पेज व्यू में 43% की बढ़ोतरी हुई.
नतीजा
कम शब्दों में कहें, तो आईएनपी ने Economic Times की वेबसाइट के कुछ हिस्सों में, रनटाइम के दौरान परफ़ॉर्मेंस से जुड़ी समस्याओं का पता लगाने में काफ़ी मदद की. यह कारोबार को आगे बढ़ाने के लिए, सबसे असरदार मेट्रिक में से एक है. इस प्रयास का परिणाम देखकर हमें बहुत प्रोत्साहित करने वाली संख्याओं के बारे में पता चला. इसलिए, हम अपनी वेबसाइट के अन्य क्षेत्रों में ऑप्टिमाइज़ेशन के प्रयासों को बढ़ाने और अतिरिक्त लाभ पाने के लिए उत्साहित हैं.