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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

स्टार्टअप के दौरान स्क्रिप्ट इवैलुएशन और लंबे टास्क के बीच संबंध

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

नतीजा

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

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

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