मॉडर्न फ़्रेमवर्क, नई आईएनपी मेट्रिक पर कैसा परफ़ॉर्म करते हैं

जानें कि नई आईएनपी मेट्रिक, JavaScript फ़्रेमवर्क और लाइब्रेरी का इस्तेमाल करके बनाई गई साइटों के अनुभव पर कैसे असर डालती है.

लीना सोहोनी
लीना सोहोनी
एडी ओस्मान
एडी उस्मान
कीन यी लिआउ
कीन यी ल्यु

Chrome ने हाल ही में Chrome की उपयोगकर्ता अनुभव से जुड़ी रिपोर्ट में एक्सपेरिमेंट के तौर पर लागू की गई रिस्पॉन्स मेट्रिक शामिल की है. इस मेट्रिक को अब इंटरैक्शन टू नेक्स्ट पेंट (आईएनपी) के नाम से जाना जाता है. यह मेट्रिक, पेज पर लोगों के इंटरैक्शन से जुड़े पूरे रिस्पॉन्स को मेज़र करती है. आज हम यह अहम जानकारी शेयर करना चाहते हैं कि आधुनिक JavaScript फ़्रेमवर्क का इस्तेमाल करके बनाई गई वेबसाइटें, इस मेट्रिक के मुकाबले कहां बेहतर हैं. हम इस बारे में चर्चा करना चाहते हैं कि आईएनपी मेट्रिक, फ़्रेमवर्क के लिए क्यों ज़रूरी है. साथ ही, हम इस बात पर भी चर्चा करना चाहते हैं कि रिस्पॉन्स को ऑप्टिमाइज़ करने के लिए, Aurora और फ़्रेमवर्क कैसे काम कर रहे हैं.

बैकग्राउंड

Chrome, वेबसाइट की लोड होने के रिस्पॉन्स का आकलन करने के लिए, वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी देने वाली रिपोर्ट (CWV) के हिस्से के तौर पर, फ़र्स्ट इनपुट डिले (एफ़आईडी) का इस्तेमाल करता है. एफ़आईडी, उपयोगकर्ता के पहले इंटरैक्शन से लेकर उस समय तक के इंतज़ार के समय को मापता है जब ब्राउज़र, इंटरैक्शन से कनेक्ट किए गए इवेंट हैंडलर को प्रोसेस कर पाता है. इसमें इवेंट हैंडलर को प्रोसेस करने, एक ही पेज पर बाद के इंटरैक्शन को प्रोसेस करने या इवेंट कॉलबैक चलाने के बाद अगले फ़्रेम को पेंट करने का समय शामिल नहीं होता. हालांकि, पेज के पूरे लाइफ़साइकल के दौरान उपयोगकर्ता अनुभव के लिए, रिस्पॉन्स देना बहुत ज़रूरी होता है. इसकी वजह यह है कि पेज लोड होने के बाद, उपयोगकर्ता उस पर करीब 90% समय बिताते हैं.

आईएनपी उस समय को मेज़र करता है जो वेब पेज को, उपयोगकर्ता के इंटरैक्शन पर जवाब देने में लगने वाले समय से लेकर, स्क्रीन पर अगला फ़्रेम पेंट होने तक लगने वाले समय तक लगता है. आईएनपी की मदद से, हम पेज के लाइफ़साइकल में सभी इंटरैक्शन की अनुमानित इंतज़ार के समय के लिए एग्रीगेट किए गए माप को चालू करने की उम्मीद करते हैं. हमारा मानना है कि आईएनपी से आपको वेब पेजों के लोड होने और रनटाइम के दौरान जवाब देने में लगने वाले समय का ज़्यादा सटीक अनुमान मिलेगा.

एफ़आईडी, सिर्फ़ पहले इंटरैक्शन के इनपुट में देरी का आकलन करता है. इसलिए, हो सकता है कि वेब डेवलपर ने सीडब्ल्यूवी को बेहतर बनाने की प्रोसेस के तहत, बाद के इंटरैक्शन को बेहतर तरीके से ऑप्टिमाइज़ न किया हो. इसलिए, ऐसी साइटों को इस मेट्रिक पर अच्छा परफ़ॉर्म करने के लिए मेहनत करनी पड़ेगी, जिनमें खास तौर पर ज़्यादा इंटरैक्टिविटी होती है.

फ़्रेमवर्क की भूमिका

कई वेबसाइटें, इंटरैक्टिविटी देने के लिए JavaScript का इस्तेमाल करती हैं, इसलिए आईएनपी स्कोर पर मुख्य रूप से मुख्य थ्रेड पर प्रोसेस की गई JavaScript की मात्रा का असर पड़ता है. JavaScript फ़्रेमवर्क, मॉडर्न फ़्रंट-एंड वेब डेवलपमेंट का एक अहम हिस्सा होते हैं. इनसे डेवलपर को, रूटिंग, इवेंट मैनेज करने, और JavaScript कोड को अलग-अलग कैटगरी में बांटने से जुड़ी अहम जानकारी मिलती है. इसलिए, उनका इस्तेमाल करने वाली वेबसाइटों की प्रतिक्रिया और उपयोगकर्ता अनुभव को बेहतर बनाने में उनकी मुख्य भूमिका है.

ऐसा हो सकता है कि वेबसाइटों के लिए एफ़आईडी को बेहतर बनाने के बाद, फ़्रेमवर्क बेहतर रिस्पॉन्स के लिए कुछ ज़रूरी कदम उठाए गए हों. हालांकि, अब उन्हें उपलब्ध रिस्पॉन्स मेट्रिक डेटा का विश्लेषण करके, कमियों को पूरा करना होगा. आम तौर पर, आईएनपी में पास होने की दर कम होती है और मेज़रमेंट प्रोसेस में अंतर होने के लिए, अतिरिक्त कोड ऑप्टिमाइज़ेशन की ज़रूरत होती है. नीचे दी गई टेबल में इसकी खास जानकारी दी गई है.

एफ़आईडी आईएनपी
मापें पहले उपयोगकर्ता के इनपुट और उससे जुड़े इवेंट हैंडलर के चलने के बीच के समय को मेज़र करता है. प्रोसेस में लगने वाले समय का इस्तेमाल करके, इंटरैक्शन के कुल इंतज़ार के समय को मापता है
निर्भर करता है पहले इंटरैक्शन के लिए ज़रूरी इवेंट हैंडलर को चलाने के लिए, मुख्य थ्रेड की उपलब्धता. मुख्य थ्रेड को ब्लॉक किया जा सकता है, क्योंकि यह शुरुआती पेज लोड के हिस्से के तौर पर अन्य संसाधनों को प्रोसेस कर रहा है. पहले इंटरैक्शन के साथ-साथ अलग-अलग इंटरैक्शन के लिए, इवेंट हैंडलर की ओर से लागू की गई स्क्रिप्ट की मुख्य थ्रेड की उपलब्धता और साइज़.
खराब स्कोर की मुख्य वजह खराब एफ़आईडी, मुख्य थ्रेड पर बहुत ज़्यादा JavaScript का इस्तेमाल करने की वजह से होता है. हैंडलर को चलाने के बाद, इवेंट को हैंडल करने वाले भारी JavaScript और रेंडरिंग से जुड़े अन्य टास्क की वजह से, आईएनपी खराब हो सकता है.
ऑप्टिमाइज़ेशन पेज लोड होने पर रिसॉर्स लोडिंग को बेहतर बनाकर और JavaScript कोड को ऑप्टिमाइज़ करके, एफ़आईडी को ऑप्टिमाइज़ किया जा सकता है. यह हर इंटरैक्शन के लिए एफ़आईडी की तरह है. साथ ही, रेंडरिंग पैटर्न के इस्तेमाल के दौरान, रेंडरिंग वाले दूसरे टास्क के बजाय, मुख्य UX अपडेट को प्राथमिकता दी जाती है.
एफ़आईडी बनाम आईएनपी: मेज़रमेंट और ऑप्टिमाइज़ेशन

Chrome में Aurora टीम ओपन सोर्स वेब फ़्रेमवर्क के साथ काम करती है और डेवलपर को उपयोगकर्ता अनुभव के अलग-अलग पहलुओं को बेहतर बनाने में मदद करती है, जिनमें परफ़ॉर्मेंस और CWV मेट्रिक शामिल हैं. आईएनपी के लॉन्च होने के बाद, हम फ़्रेमवर्क आधारित वेबसाइटों के लिए CWV मेट्रिक में होने वाले बदलाव के लिए तैयार रहना चाहते हैं. हमने CrUX रिपोर्ट में, प्रयोग के तौर पर शुरू किए गए रिस्पॉन्स मेट्रिक के आधार पर डेटा इकट्ठा किया है. हम फ़्रेमवर्क पर आधारित वेबसाइटों के लिए, आईएनपी मेट्रिक में ट्रांज़िशन की प्रोसेस को आसान बनाने के लिए, अहम जानकारी और ऐक्शन आइटम शेयर करेंगे.

एक्सपेरिमेंट के तौर पर शुरू किए गए रिस्पॉन्स मेट्रिक का डेटा

आईएनपी की वैल्यू 200 मिलीसेकंड से कम या इसके बराबर होनी चाहिए, ताकि यह पता चल सके कि रिस्पॉन्स कितना अच्छा है. CrUX रिपोर्ट के डेटा और जून 2023 की सीडब्ल्यूवी टेक्नोलॉजी रिपोर्ट से, हमें लोकप्रिय JavaScript फ़्रेमवर्क के लिए रिस्पॉन्सिवनेस के बारे में नीचे दी गई जानकारी मिलती है.

टेक्नोलॉजी % पासिंग
% मोबाइल डेस्कटॉप
एंगुलर (v2.0.0+) 28.6 83.6
Next.js 28.5 यूरो
Nuxt.js 78 जीबी में से 91.2
प्रीैक्ट 48.6 यूरो
Vue (v2.0.0+) 50.3 94.1
Lit 50.0 88.3
सीडब्ल्यूवी टेक्नोलॉजी रिपोर्ट - जून 2023 का आईएनपी डेटा

इस टेबल में, हर फ़्रेमवर्क पर उन ऑरिजिन का प्रतिशत दिखाया जाता है जिनका रिस्पॉन्सिव स्कोर अच्छा होता है. आंकड़े हौसला बढ़ाने वाले हैं, लेकिन हमें यह बताते हैं कि इसमें सुधार की बहुत गुंजाइश है.

JavaScript, आईएनपी पर कैसे असर डालता है?

फ़ील्ड में आईएनपी वैल्यू, लैब में मौजूद टोटल ब्लॉकिंग टाइम (टीबीटी) के साथ जुड़ी हुई हैं. इसका मतलब यह हो सकता है कि मुख्य थ्रेड को लंबे समय के लिए ब्लॉक करने वाली कोई भी स्क्रिप्ट, आईएनपी के लिए खराब होगी. किसी भी इंटरैक्शन के बाद ज़्यादा JavaScript चलाने पर, मुख्य थ्रेड लंबे समय के लिए ब्लॉक हो सकती है. साथ ही, उस इंटरैक्शन का जवाब देने में देरी हो सकती है. स्क्रिप्ट ब्लॉक करने की कुछ सामान्य वजहें ये हैं:

  • ऑप्टिमाइज़ नहीं किया गया JavaScript: कोड का ज़रूरत से ज़्यादा इस्तेमाल होने या कोड को अलग-अलग करने और लोड करने की खराब रणनीतियों की वजह से, JavaScript में गड़बड़ी हो सकती है और मुख्य थ्रेड को लंबे समय के लिए ब्लॉक किया जा सकता है. कोड-स्प्लिटिंग, प्रोग्रेसिव लोडिंग, और लंबे टास्क को हिस्सों में बांटने से, जवाब मिलने में लगने वाले समय में काफ़ी सुधार हो सकता है.

  • तीसरे पक्ष की स्क्रिप्ट: तीसरे पक्ष की स्क्रिप्ट, कभी-कभी मुख्य थ्रेड को ब्लॉक कर सकती हैं. इन स्क्रिप्ट (जैसे, विज्ञापन स्क्रिप्ट) का कभी-कभी इंटरैक्शन को प्रोसेस करने के लिए ज़रूरत नहीं होती. इस वजह से, स्क्रिप्ट में देरी हो सकती है. ज़रूरी स्क्रिप्ट को प्राथमिकता देने से, तीसरे पक्ष की स्क्रिप्ट के नेगेटिव असर को कम करने में मदद मिल सकती है.

  • एक से ज़्यादा इवेंट हैंडलर: हर इंटरैक्शन से जुड़े कई इवेंट हैंडलर, जो अलग-अलग स्क्रिप्ट पर चल रहे हैं, एक-दूसरे में रुकावट डाल सकते हैं और इसकी वजह से काफ़ी देरी हो सकती है. इनमें से कुछ टास्क ज़रूरी नहीं हैं. ये किसी वेब वर्कर पर या ब्राउज़र के कुछ समय से इस्तेमाल में न होने पर शेड्यूल भी किए जा सकते हैं.

  • इवेंट हैंडलिंग पर फ़्रेमवर्क ओवरहेड: इवेंट को मैनेज करने के लिए फ़्रेमवर्क में अतिरिक्त सुविधाएं/सिंटैक्स भी हो सकता है. उदाहरण के लिए, Vue इवेंट लिसनर को एलिमेंट से अटैच करने के लिए v-on का इस्तेमाल करता है, जबकि Angular, उपयोगकर्ता इवेंट हैंडलर को रैप करता है. इन सुविधाओं को लागू करने के लिए, वैनिला JavaScript के ऊपर अतिरिक्त फ़्रेमवर्क कोड की ज़रूरत होती है.

  • हाइड्रेशन: जब JavaScript फ़्रेमवर्क का इस्तेमाल किया जाता है, तब सर्वर किसी पेज के लिए शुरुआती एचटीएमएल जनरेट करता है. इसके बाद, उस पेज को इवेंट हैंडलर और ऐप्लिकेशन की स्थिति के साथ बढ़ाने की ज़रूरत होती है, ताकि उसे वेब ब्राउज़र में इंटरैक्टिव बनाया जा सके. हम इस प्रोसेस को हाइड्रेशन कहते हैं. पेज लोड होने के दौरान यह एक मुश्किल प्रक्रिया हो सकती है. यह इस बात पर निर्भर करता है कि JavaScript को लोड होने में कितना समय लगता है और हाइड्रेशन की प्रोसेस पूरी होने में कितना समय लगता है. इसकी वजह से, ऐसे पेज भी दिख सकते हैं जो इंटरैक्टिव नहीं होते हैं. अक्सर हाइड्रेशन, पेज लोड होने के दौरान या लेज़ी तरीके से (उदाहरण के लिए, उपयोगकर्ता के इंटरैक्शन पर) अपने-आप होता है. टास्क शेड्यूल करने की वजह से, आईएनपी या प्रोसेसिंग के समय पर असर पड़ सकता है. React जैसी लाइब्रेरी में useTransition का इस्तेमाल किया जा सकता है, ताकि कॉम्पोनेंट के रेंडर का कुछ हिस्सा अगले फ़्रेम में हो. साथ ही, आने वाले समय में इस्तेमाल होने वाले फ़्रेम पर, नुकसान पहुंचाने वाले ज़्यादा असर डालने पड़ें. इसे देखते हुए, ट्रांज़िशन के दौरान होने वाले अपडेट, जिनसे तुरंत अपडेट मिलते हैं, जैसे कि क्लिक, एक ऐसा पैटर्न हो सकता है जो आईएनपी के लिए अच्छा हो सकता है.

  • प्रीफ़ेचिंग करना: बाद में नेविगेशन के लिए ज़रूरी संसाधनों को तेज़ी से प्रीफ़ेच करना, सही तरीके से किए जाने पर परफ़ॉर्मेंस को बेहतर करने के लिए फ़ायदेमंद हो सकता है. हालांकि, एसपीए रूट को सिंक करके प्रीफ़ेच और रेंडर किया जाता है, तो आईएनपी पर बुरा असर पड़ सकता है. ऐसा इसलिए होता है, क्योंकि रेंडरिंग की ये सभी महंगी फ़ाइलें एक ही फ़्रेम में पूरी होती हैं. इसके उलट, अपने रास्ते को प्रीफ़ेच न करें और ज़रूरी काम (उदाहरण के लिए, fetch()) को शुरू करने और पेंट को अनब्लॉक करने के बजाय उसे अनब्लॉक करें. हमारा सुझाव है कि आप फिर से जांच कर लें कि प्रीफ़ेच करने के लिए आपके फ़्रेमवर्क का तरीका, बेहतर उपयोगकर्ता अनुभव दे रहा है या नहीं. साथ ही, अगर आपने ऐसा किया है, तो आईएनपी पर इसका क्या असर होगा.

अब से, डेवलपर को एक अच्छे आईएनपी स्कोर के लिए उस कोड की समीक्षा करने पर ध्यान देना होगा जो पेज पर हर इंटरैक्शन के बाद काम करता है. साथ ही, उन्हें पहले-पक्ष और तीसरे-पक्ष की स्क्रिप्ट के लिए, छोटे-छोटे हिस्सों में इस्तेमाल करने, फिर से पानी इकट्ठा करने, और लोड करने की रणनीतियों के साथ-साथ हर रेंडर() अपडेट के साइज़ को ऑप्टिमाइज़ करना होगा.

ऑरोरा और फ़्रेमवर्क, आईएनपी की समस्याओं को कैसे हल कर रहे हैं?

Aurora सामान्य समस्याओं के लिए बेक किए गए समाधान उपलब्ध कराने के लिए सबसे अच्छे तरीकों को शामिल करके फ़्रेमवर्क के साथ काम करता है. हमने समाधान पर Next.js, Nuxt.js, Gatsby, और Angular के साथ काम किया है. ये समाधान परफ़ॉर्मेंस को ऑप्टिमाइज़ करने के लिए, फ़्रेमवर्क में बेहतर डिफ़ॉल्ट सुविधाएं देते हैं. इस संदर्भ में हमारे काम के हाइलाइट नीचे दिए गए हैं:

  • React और Next.js: Next.js स्क्रिप्ट कॉम्पोनेंट तीसरे पक्ष की स्क्रिप्ट को ठीक से लोड न करने की वजह से होने वाली समस्याओं को हल करने में मदद करता है. Next.js में छोटे-छोटे हिस्सों को छोटे-छोटे हिस्सों में बांटा जा सकता है, ताकि शेयर किए गए कोड को छोटे हिस्सों में इस्तेमाल किया जा सके. इससे सभी पेजों पर डाउनलोड किए जाने वाले ऐसे सामान्य कोड की संख्या कम करने में मदद मिलती है जिन्हें इस्तेमाल नहीं किया जाता. हम Next.js के साथ भी काम कर रहे हैं, ताकि आईएनपी डेटा को Analytics सेवा के हिस्से के तौर पर उपलब्ध कराया जा सके.

  • Angular: Aurora सर्वर-साइड रेंडरिंग और हाइड्रेशन से जुड़े सुधारों का पता लगाने के लिए Angular टीम के साथ साझेदारी कर रहा है. आईएनपी को बेहतर बनाने के लिए, हम इवेंट हैंडलिंग में सुधार करने और पहचान में बदलाव करने पर भी काम कर रहे हैं.

  • Vue और Nuxt.js: हम मिलकर काम करने के नए तरीके खोज रहे हैं. इनमें मुख्य तौर पर, स्क्रिप्ट लोड करने और रेंडर करने से जुड़े विकल्प शामिल हैं.

आईएनपी को बेहतर बनाने के लिए फ़्रेमवर्क किस तरह काम कर रहे हैं?

React और Next.js

startTransition और Suspense के ज़रिए लागू, React.js टाइम स्लाइसिंग की मदद से चुनिंदा या प्रोग्रेसिव हाइड्रेशन के लिए ऑप्ट-इन किया जा सकता है. इसका मतलब है कि हाइड्रेशन कोई सिंक्रोनस ब्लॉक नहीं है. इसमें छोटे-छोटे टुकड़ों में किया जाता है. इन्हें किसी भी समय रोका जा सकता है.

इससे आईएनपी को बेहतर बनाने में मदद मिलेगी. साथ ही, आपको कीस्ट्रोक का ज़्यादा तेज़ी से जवाब देने, ट्रांज़िशन के दौरान इफ़ेक्ट पर कर्सर घुमाने, और क्लिक का जवाब देने में मदद मिलेगी. इससे अपने-आप पूरा होने जैसे बड़े ट्रांज़िशन के दौरान भी, प्रतिक्रिया वाले ऐप्लिकेशन को रिस्पॉन्सिव बनाए रखने में मदद मिलती है.

Next.js में एक नया रूटिंग फ़्रेमवर्क लागू किया गया है, जो रूट ट्रांज़िशन के लिए डिफ़ॉल्ट रूप से startTransition का इस्तेमाल करता है. इसकी मदद से Next.js साइट के मालिक, 'रिऐक्ट टाइम-स्लाइसिंग' सुविधा अपना सकते हैं. साथ ही, रूट ट्रांज़िशन के रिस्पॉन्स में सुधार कर सकते हैं.

Angular

Angular की टीम ऐसे कई आइडिया पर काम कर रही है जिनसे आईएनपी में भी मदद मिलनी चाहिए:

  • ज़ोनलेस: यह शुरुआती बंडल के साइज़ को कम करता है. साथ ही, इसमें उस कोड को भी कम किया जाता है जो ऐप्लिकेशन के कुछ भी रेंडर होने से पहले लोड होना ज़रूरी है.
  • हाइड्रेशन: आइलैंड-स्टाइल हाइड्रेशन का इस्तेमाल करके, यह तय किया जाता है कि इंटरैक्शन के लिए ऐप्लिकेशन को कितनी देर तक जागना चाहिए.
  • सीडी का ऊपरी हिस्सा कम करें: उदाहरण के लिए, बदलाव का पता लगाना कम खर्चीला करें, ऐप्लिकेशन की कम जानकारी देखने के तरीके ढूंढें, और बदलावों के बारे में प्रतिक्रिया देने वाले सिग्नल का फ़ायदा उठाएं.
  • कोड को ज़्यादा बारीकी से अलग करने की सुविधा: शुरुआती बंडल को छोटा करें.
  • पेज लोड होने के इंडिकेटर के लिए बेहतर सहायता: उदाहरण के लिए, एसएसआर को फिर से रेंडर करने के दौरान, रूट नेविगेशन के दौरान, और लेज़ी लोडिंग ऑपरेशन के दौरान.
  • प्रोफ़ाइलिंग टूल: इंटरैक्शन की लागत को समझने के लिए डेवलपर टूल, खास तौर पर किसी इंटरैक्शन के लिए, बदलाव का पता लगाने की लागत के बारे में.

इन सुधारों की मदद से, हम उन अलग-अलग समस्याओं को ठीक कर सकते हैं जिनकी वजह से जवाब देने में लोगों की दिलचस्पी बढ़ती है और उपयोगकर्ताओं को खराब अनुभव मिलता है. साथ ही, हम फ़्रेमवर्क आधारित वेबसाइटों के लिए CWV मेट्रिक और नई INP मेट्रिक को बढ़ावा दे सकते हैं.

नतीजा

हमें उम्मीद है कि आईएनपी स्कोर से वेबसाइटों के लिए बेहतर दिशा-निर्देश मिलेगा. इससे आने वाले समय में वेबसाइटों को जवाब देने में आसानी होगी और परफ़ॉर्मेंस बेहतर होगी. हम अपनी मौजूदा आईएनपी गाइड को बेहतर बनाएंगे. इसमें, 2023 में फ़्रेमवर्क डेवलपर के लिए ज़्यादा काम की सलाह दी जाएंगी. हमें उम्मीद है कि ऐसा करने के लिए हम:

  • फ़्रेमवर्क और वेब डेवलपर के लिए चैनल बनाना, ताकि आईएनपी पर फ़ील्ड डेटा को आसानी से ऐक्सेस किया जा सके.
  • फ़्रेमवर्क का इस्तेमाल करके ऐसी सुविधाएं बनाएं जिनसे आईएनपी को डिफ़ॉल्ट रूप से बेहतर बनाया जा सके.

आईएनपी को ऑप्टिमाइज़ करने की प्रोसेस शुरू करने वाले फ़्रेमवर्क का इस्तेमाल करने वाले लोगों से, हम सुझाव/राय/शिकायत का स्वागत करते हैं.