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

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

Jeremy Wagner
Philip Walton

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

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

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

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

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

जानें कि खराब आईएनपी की वजह क्या है

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

मुख्य थ्रेड को अक्सर येल्ड करना

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

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

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

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

रेंडरिंग की प्रोसेस जल्दी शुरू करने के लिए, Yield

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

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

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

  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 के साइज़ के बढ़ने के साथ रेंडरिंग का काम भी बढ़ जाता है. रेंडरिंग के काम और डीओएम के साइज़ के बीच का संबंध लीनियर नहीं है. हालांकि, बड़े डीओएम को रेंडर करने के लिए, छोटे डीओएम की तुलना में ज़्यादा काम करना पड़ता है. बड़ा डीओएम दो मामलों में समस्या पैदा करता है:

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

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

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

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

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

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

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

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

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

नतीजा

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

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

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