इंटरैक्शन को नेक्स्ट पेंट के लिए ऑप्टिमाइज़ करना

अपनी वेबसाइट के इंटरैक्शन टू नेक्स्ट पेंट को ऑप्टिमाइज़ करने का तरीका जानें.

Jeremy Wagner
Philip Walton

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

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

अच्छी आईएनपी वैल्यू 200 मिलीसेकंड या उससे कम होती हैं. खराब वैल्यू 500 मिलीसेकंड से ज़्यादा होती हैं. इन दोनों के बीच की वैल्यू में सुधार की ज़रूरत होती है.

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

आईएनपी को बेहतर बनाने में समय और मेहनत लगती है, लेकिन इनाम से उपयोगकर्ताओं को बेहतर अनुभव मिलता है. इस गाइड में, आईएनपी को बेहतर बनाने का तरीका बताया गया है.

पता लगाएं कि आईएनपी की खराब परफ़ॉर्मेंस की वजह क्या है

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

फ़ील्ड में धीमे इंटरैक्शन ढूंढना

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

अगर फ़ील्ड डेटा पाने के लिए, आरयूएम की सेवा देने वाली किसी कंपनी पर भरोसा नहीं किया जा रहा है, तो INP फ़ील्ड डेटा गाइड में, PageSpeed Insights की मदद से Chrome उपयोगकर्ता अनुभव रिपोर्ट (CrUX) का इस्तेमाल करने का सुझाव दिया गया है. इससे, डेटा में मौजूद गैप को पूरा करने में मदद मिलती है. CrUX, Core Web Vitals प्रोग्राम का आधिकारिक डेटासेट है. यह आईएनपी के साथ-साथ लाखों वेबसाइटों की मेट्रिक की खास जानकारी देता है. हालांकि, CrUX अक्सर काम का वह डेटा उपलब्ध नहीं कराता है जो आपको आरयूएम की सेवा देने वाली कंपनी से मिलता है. इससे, समस्याओं का विश्लेषण करने में मदद मिलती है. इस वजह से, हमारा सुझाव है कि जब भी मुमकिन हो, साइटें आरयूएम की सेवा देने वाली कंपनी का इस्तेमाल करें या CrUX में उपलब्ध चीज़ों को पूरा करने के लिए, साइटें आरयूएम का अपना समाधान इस्तेमाल करें.

लैब में इंटरैक्शन की धीमी स्पीड का पता लगाना

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

इंटरैक्शन ऑप्टिमाइज़ करना

धीमे इंटरैक्शन की पहचान करने और लैब में इसे मैन्युअल तरीके से फिर से इस्तेमाल करने के बाद, उसे ऑप्टिमाइज़ करना. इंटरैक्शन को तीन चरणों में बांटा जा सकता है:

  1. इनपुट में लगा समय, जो तब शुरू होता है, जब उपयोगकर्ता पेज से इंटरैक्ट करना शुरू करता है और इंटरैक्शन के लिए इवेंट कॉलबैक चलने लगने पर खत्म होता है.
  2. प्रोसेसिंग में लगने वाला समय. इसमें, इवेंट कॉलबैक के पूरा होने में लगने वाला समय शामिल होता है.
  3. प्रज़ेंटेशन में लगा समय: यह वह समय होता है जो ब्राउज़र को अगले फ़्रेम को प्रज़ेंट करने में लगता है. इसमें इंटरैक्शन का विज़ुअल नतीजा भी शामिल होता है.

इन तीन चरणों के कुल समय को इंटरैक्शन में लगने वाला कुल समय कहा जाता है. इंटरैक्शन के हर एक चरण का कुल इंटरैक्शन लेटेंसी में कुछ समय लगता है. इसलिए, यह जानना ज़रूरी है कि इंटरैक्शन के हर हिस्से को ऑप्टिमाइज़ करने का तरीका क्या है, ताकि यह कम से कम समय तक चले.

इनपुट में होने वाली देरी की पहचान करना और उसे कम करना

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

किसी इंटरैक्शन के इनपुट में देरी होने का सोर्स चाहे जो भी हो, आपको इनपुट में देरी को कम से कम करना होगा, ताकि इंटरैक्शन जल्द से जल्द इवेंट कॉलबैक चला सकें.

स्टार्टअप के दौरान स्क्रिप्ट की जांच और लंबे टास्क के बीच का संबंध

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

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

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

इवेंट कॉलबैक ऑप्टिमाइज़ करना

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

मुख्य थ्रेड पर अक्सर नतीजे देते हैं

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

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

setTimeout, टास्क को अलग-अलग करने का एक तरीका है, क्योंकि इसे दिया गया कॉलबैक नए टास्क में चलता है. setTimeout का इस्तेमाल अपने-आप किया जा सकता है या ज़्यादा बेहतर नतीजे पाने के लिए, इसका इस्तेमाल किसी अलग फ़ंक्शन में किया जा सकता है.

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

रेंडरिंग काम को जल्दी पूरा करने में मदद मिलती है

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

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

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

  1. उपयोगकर्ता ने जो टाइप किया है उससे टेक्स्ट बॉक्स को अपडेट करें और ज़रूरी फ़ॉर्मैटिंग लागू करें.
  2. यूज़र इंटरफ़ेस (यूआई) के उस हिस्से को अपडेट करें जो मौजूदा शब्दों की संख्या दिखाता है.
  3. स्पेलिंग की गड़बड़ियों की जांच करने के लिए लॉजिक चलाएं.
  4. हाल ही में किए गए बदलावों को सेव करें. ये बदलाव, स्थानीय या रिमोट डेटाबेस में सेव किए जा सकते हैं.

ऐसा करने के लिए, कोड कुछ ऐसा दिख सकता है:

textBox.addEventListener('input', (inputEvent) => {
  // Update the UI immediately, so the changes the user made
  // are visible as soon as the next frame is presented.
  updateTextBox(inputEvent);

  // Use `setTimeout` to defer all other work until at least the next
  // frame by queuing a task in a `requestAnimationFrame()` callback.
  requestAnimationFrame(() => {
    setTimeout(() => {
      const text = textBox.textContent;
      updateWordCount(text);
      checkSpelling(text);
      saveChanges(text);
    }, 0);
  });
});

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

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

पिछले कोड के उदाहरण में, requestAnimationFrame() कॉल के अंदर setTimeout() का इस्तेमाल करना थोड़ा मुश्किल है. हालांकि, यह एक असरदार तरीका है, जो सभी ब्राउज़र में काम करता है. इससे यह पक्का होता है कि ग़ैर-ज़रूरी कोड, अगले फ़्रेम को ब्लॉक न करे.

लेआउट थ्रैशिंग से बचना

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

Chrome DevTools के परफ़ॉर्मेंस पैनल में दिखाए गए लेआउट थ्रैशिंग का विज़ुअलाइज़ेशन.
लेआउट थ्रैशिंग का उदाहरण, जैसा कि Chrome DevTools के परफ़ॉर्मेंस पैनल में दिखाया गया है. अगर किसी टास्क को रेंडर करते समय लेआउट थ्रैशिंग का इस्तेमाल किया जाता है, तो उसे कॉल स्टैक के ऊपरी दाएं कोने में एक लाल त्रिकोण के साथ नोट किया जाएगा. आम तौर पर, इस पर स्टाइल को फिर से कैलकुलेट करें या लेआउट लेबल किया जाता है.

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

प्रज़ेंटेशन में लगने वाली देरी को कम करना

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

DOM का साइज़ कम करना

जब किसी पेज का डीओएम छोटा होता है, तो आम तौर पर रेंडरिंग का काम जल्दी पूरा हो जाता है. हालांकि, जब DOM बहुत बड़े हो जाते हैं, तो DOM के साइज़ के बढ़ने के साथ रेंडरिंग का काम भी बढ़ जाता है. रेंडरिंग के काम और DOM के साइज़ के बीच का संबंध लीनियर नहीं है. हालांकि, बड़े DOM को रेंडर करने के लिए छोटे DOM की तुलना में ज़्यादा काम करना पड़ता है. बड़ा डीओएम दो मामलों में समस्या पैदा करता है:

  1. पेज के शुरुआती रेंडर के दौरान, जब बड़े DOM को पेज की शुरुआती स्थिति को रेंडर करने के लिए ज़्यादा काम करना पड़ता है.
  2. उपयोगकर्ता के इंटरैक्शन के जवाब में, बड़े DOM की वजह से अपडेट को रेंडर करने में काफ़ी समय लग सकता है. इसलिए, ब्राउज़र को अगला फ़्रेम दिखाने में ज़्यादा समय लगता है.

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

ऑफ़-स्क्रीन एलिमेंट को लेज़ी तरीके से रेंडर करने के लिए, content-visibility का इस्तेमाल करें

पेज लोड होने के दौरान और उपयोगकर्ता के इंटरैक्शन के जवाब में, रेंडरिंग के काम को सीमित करने का एक तरीका है कि सीएसएस content-visibility प्रॉपर्टी का इस्तेमाल किया जाए. इससे, एलिमेंट को व्यूपोर्ट के करीब आने पर, उन्हें धीरे-धीरे रेंडर किया जाता है. content-visibility का असरदार तरीके से इस्तेमाल करने के लिए, थोड़ी सी प्रैक्टिस की ज़रूरत पड़ सकती है. हालांकि, यह जांच करना ज़रूरी है कि क्या रेंडरिंग में लगने वाला समय कम हो गया है, ताकि आपके पेज का INP बेहतर हो सके.

JavaScript का इस्तेमाल करके एचटीएमएल रेंडर करते समय परफ़ॉर्मेंस की लागत का ध्यान रखें

जहां एचटीएमएल है, वहां एचटीएमएल पार्स करना होता है. साथ ही, जब ब्राउज़र एचटीएमएल को डीओएम में पार्स कर लेता है, तो उसे इसमें स्टाइल लागू करने होंगे, लेआउट की गणना करनी होगी, और इसके बाद उस लेआउट को रेंडर करना होगा. यह एक ऐसी लागत है जिसे टाला नहीं जा सकता. हालांकि, एचटीएमएल को कैसे रेंडर किया जाता है, यह ज़रूरी है.

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

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

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

नतीजा

अपनी साइट के INP को बेहतर बनाने की प्रोसेस बार-बार इस्तेमाल होती है. फ़ील्ड में किसी इंटरैक्शन की स्पीड ठीक करने पर, हो सकता है कि आपको अन्य इंटरैक्शन भी धीमे लगें. खास तौर पर, अगर आपकी वेबसाइट पर इंटरैक्शन की सुविधा का ज़्यादा इस्तेमाल किया जाता है, तो ऐसा हो सकता है. आपको इन इंटरैक्शन को भी ऑप्टिमाइज़ करना होगा.

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

Unsplash से ली गई हीरो इमेज, जिसे डेविड पिस्नोय ने Unsplash के लाइसेंस के मुताबिक बदला है.