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

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

Leena Sohoni
Leena Sohoni
Addy Osmani
Addy Osmani
Keen Yee Liau
Keen Yee Liau

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

बैकग्राउंड

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

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

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

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

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

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

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

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

एक्सपेरिमेंट के तौर पर लागू होने वाली रिस्पॉन्सिवनेस मेट्रिक का डेटा

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

टेक्नोलॉजी % पासिंग
% मोबाइल डेस्कटॉप
कोणीय (v2.0.0+) 28.6 83.6
Next.js 28.5 87.3
Nuxt.js 32.0 91.2
प्रीऐक्ट 48.6 92.8
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 की टाइम स्लाइसिंग की मदद से, चुनिंदा या प्रोग्रेसिव हाइड्रेशन के लिए ऑप्ट-इन किया जा सकता है. इसका मतलब है कि हाइड्रेशन का मतलब सिंक्रोनस ब्लॉक नहीं है. ऐसा छोटे-छोटे टुकड़ों में किया जाता है, इसलिए किसी भी समय रुकावट आ सकती है.

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

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

Angular

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

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

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

नतीजा

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

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

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