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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

इनपुट में लगे समय का पता लगाएं और उसे कम करें

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

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

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

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

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

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

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

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

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

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

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

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 में उन शैलियों के मानों का तुरंत अनुरोध करने से, ब्राउज़र सिंक्रोनस लेआउट का काम करने के लिए बाध्य हो जाता है, नहीं तो यह बाद में इवेंट कॉलबैक चलने के बाद एसिंक्रोनस रूप से काम करने के लिए इंतज़ार कर सकता था.

प्रज़ेंटेशन में देरी को कम करें

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

डीओएम का साइज़ छोटा करें

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

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

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

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

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

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

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

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

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

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

नतीजा

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

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

Unस्प्लैश की हीरो इमेज. इसे डेविड पिज़नॉय ने तैयार किया है. इसमें Unस्प्लैश लाइसेंस के हिसाब से बदलाव किया गया है.