अपनी वेबसाइट के लिए, पेज के रिस्पॉन्स में लगने वाले समय (आईएनपी) को ऑप्टिमाइज़ करने का तरीका जानें.
पब्लिश होने की तारीख: 19 मई, 2023, पिछले अपडेट की तारीख: 2 सितंबर, 2025
पेज के रिस्पॉन्स में लगने वाला समय (आईएनपी), वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी देने वाली एक स्टेबल मेट्रिक है. इससे यह पता चलता है कि कोई पेज, उपयोगकर्ता के अनुरोधों का जवाब देने के मामले में कुल मिलाकर कितना रिस्पॉन्सिव है. इसमें यह देखा जाता है कि जब कोई उपयोगकर्ता किसी पेज पर आया, तो इस दौरान ज़रूरी शर्तों को पूरा करने वाले सभी इंटरैक्शन का जवाब देने में पेज को कितना समय लगा. आईएनपी की फ़ाइनल वैल्यू से पता चलता है कि किसी व्यक्ति और पेज के बीच सबसे लंबा इंटरैक्शन कितने समय तक चला. इसमें कभी-कभी आउटलायर वैल्यू को नज़रअंदाज़ कर दिया जाता है.
उपयोगकर्ताओं को अच्छा अनुभव देने के लिए, वेबसाइटों का आईएनपी 200 मिलीसेकंड या इससे कम होना चाहिए. ज़्यादातर उपयोगकर्ताओं के लिए इस टारगेट को पूरा करने का एक अच्छा तरीका यह है कि मोबाइल और कंप्यूटर, दोनों के लिए कुल पेज लोड का 75वां पर्सेंटाइल मेज़र करें.
वेबसाइट के हिसाब से, इंटरैक्शन कम या ज़्यादा हो सकते हैं. जैसे, ज़्यादातर टेक्स्ट और इमेज वाले पेजों पर इंटरैक्टिव एलिमेंट कम या ज़्यादा हो सकते हैं. इसके अलावा, टेक्स्ट एडिटर या गेम जैसी वेबसाइटों के मामले में, सैकड़ों या हज़ारों इंटरैक्शन हो सकते हैं. दोनों ही मामलों में, आईएनपी ज़्यादा होने पर उपयोगकर्ता अनुभव पर असर पड़ता है.
आईएनपी को बेहतर बनाने में समय और मेहनत लगती है. हालांकि, इससे उपयोगकर्ताओं को बेहतर अनुभव मिलता है. इस गाइड में, आईएनपी को बेहतर बनाने का तरीका बताया जाएगा.
आईएनपी स्कोर खराब होने की वजह का पता लगाना
धीमे इंटरैक्शन की समस्या को ठीक करने से पहले, आपको डेटा की ज़रूरत होगी. इससे आपको पता चलेगा कि आपकी वेबसाइट का आईएनपी खराब है या उसमें सुधार की ज़रूरत है. यह जानकारी मिलने के बाद, लैब में जाकर धीमे इंटरैक्शन का विश्लेषण किया जा सकता है. साथ ही, समस्या को हल करने के लिए काम किया जा सकता है.
फ़ील्ड में धीमे इंटरैक्शन ढूंढना
आम तौर पर, आईएनपी को ऑप्टिमाइज़ करने की प्रोसेस फ़ील्ड डेटा से शुरू होती है. रीयल यूज़र मॉनिटरिंग (आरयूएम) की सेवा देने वाली कंपनी से मिलने वाले फ़ील्ड डेटा से, आपको पेज की आईएनपी वैल्यू के साथ-साथ काम का डेटा भी मिलेगा. इससे यह पता चलता है कि आईएनपी वैल्यू के लिए कौनसा इंटरैक्शन ज़िम्मेदार था, इंटरैक्शन पेज लोड होने के दौरान हुआ या उसके बाद, इंटरैक्शन किस तरह का था (क्लिक, कीप्रेस या टैप), और अन्य ज़रूरी जानकारी.
अगर फ़ील्ड डेटा पाने के लिए, आरयूएम की सेवा देने वाली कंपनी पर भरोसा नहीं किया जा रहा है, तो आईएनपी फ़ील्ड डेटा की गाइड में, Chrome के लिए उपयोगकर्ता अनुभव से जुड़ी रिपोर्ट (CrUX) का डेटा देखने के लिए, PageSpeed Insights का इस्तेमाल करने की सलाह दी गई है. इससे कमियों को दूर करने में मदद मिलती है. CrUX, Core Web Vitals प्रोग्राम का Google डेटासेट है. यह लाखों वेबसाइटों के लिए, मेट्रिक की खास जानकारी देता है. इसमें आईएनपी भी शामिल है. हालांकि, CrUX अक्सर वह कॉन्टेक्स्ट डेटा नहीं देता जो आपको आरयूएम की सेवा देने वाली कंपनी से मिलता है. इस डेटा से आपको समस्याओं का विश्लेषण करने में मदद मिलती है. इसलिए, हमारा सुझाव है कि साइटें जब भी मुमकिन हो, आरयूएम की सेवा देने वाली कंपनी का इस्तेमाल करें या CrUX में उपलब्ध जानकारी को बेहतर बनाने के लिए, अपना आरयूएम समाधान लागू करें.
लैब में धीमे इंटरैक्शन का विश्लेषण करना
आम तौर पर, लैब में टेस्टिंग तब शुरू की जाती है, जब फ़ील्ड डेटा से पता चलता है कि आपके इंटरैक्शन धीमे हैं. फ़ील्ड डेटा न होने पर, लैब में धीमे इंटरैक्शन की पहचान करने के लिए कुछ रणनीतियां अपनाई जा सकती हैं. इन रणनीतियों में, सामान्य यूज़र फ़्लो को फ़ॉलो करना और इस दौरान इंटरैक्शन की जांच करना शामिल है. साथ ही, पेज लोड होने के दौरान पेज से इंटरैक्ट करना भी शामिल है. पेज लोड होने के दौरान, मुख्य थ्रेड अक्सर सबसे ज़्यादा व्यस्त होता है. इससे, उपयोगकर्ता अनुभव के उस अहम हिस्से के दौरान धीमे इंटरैक्शन की पहचान की जा सकती है.
इंटरैक्शन ऑप्टिमाइज़ करना
धीमे इंटरैक्शन की पहचान करने और लैब में उसे मैन्युअल तरीके से फिर से जनरेट करने के बाद, अगला चरण उसे ऑप्टिमाइज़ करना है.
इंटरैक्शन को तीन सब-पार्ट में बांटा जा सकता है:
- इनपुट डिले, जो तब शुरू होता है, जब उपयोगकर्ता पेज से इंटरैक्ट करना शुरू करता है. यह तब खत्म होता है, जब इंटरैक्शन के लिए इवेंट कॉलबैक चलने लगते हैं.
- प्रोसेस होने में लगने वाला समय. इसमें, इवेंट कॉलबैक को पूरा होने में लगने वाला समय शामिल होता है.
- प्रज़ेंटेशन में लगने वाला समय. यह वह समय होता है जो ब्राउज़र को अगला फ़्रेम दिखाने में लगता है. इस फ़्रेम में इंटरैक्शन का विज़ुअल नतीजा होता है.
इन तीनों सबपार्ट का योग, इंटरैक्शन का कुल इंतज़ार का समय होता है. इंटरैक्शन का हर सबपार्ट, इंटरैक्शन के कुल इंतज़ार के समय में कुछ समय जोड़ता है. इसलिए, यह जानना ज़रूरी है कि इंटरैक्शन के हर हिस्से को कैसे ऑप्टिमाइज़ किया जाए, ताकि वह कम से कम समय तक चले.
इनपुट में होने वाली देरी की पहचान करना और उसे कम करना
जब कोई उपयोगकर्ता किसी पेज से इंटरैक्ट करता है, तो उस इंटरैक्शन का पहला हिस्सा इनपुट डिले होता है. पेज पर होने वाली अन्य गतिविधि के आधार पर, इनपुट में होने वाली देरी काफ़ी ज़्यादा हो सकती है. ऐसा मुख्य थ्रेड पर होने वाली गतिविधि की वजह से हो सकता है. जैसे, स्क्रिप्ट लोड होना, पार्स होना, और कंपाइल होना. इसके अलावा, फ़ेच हैंडलिंग, टाइमर फ़ंक्शन या अन्य इंटरैक्शन की वजह से भी ऐसा हो सकता है. ये इंटरैक्शन, एक के बाद एक तेज़ी से होते हैं और एक-दूसरे को ओवरलैप करते हैं.
इंटरैक्शन के इनपुट में होने वाली देरी की वजह चाहे जो भी हो, आपको इनपुट में होने वाली देरी को कम से कम करना होगा. इससे इंटरैक्शन, इवेंट कॉलबैक को जल्द से जल्द चलाना शुरू कर सकते हैं.
स्टार्टअप के दौरान, स्क्रिप्ट के आकलन और ज़्यादा समय लेने वाले कामों के बीच का संबंध
पेज के लाइफ़साइकल में इंटरैक्टिविटी का एक अहम पहलू, स्टार्टअप के दौरान होता है. जब कोई पेज लोड होता है, तो वह शुरुआत में रेंडर होगा. हालांकि, यह याद रखना ज़रूरी है कि अगर कोई पेज रेंडर हो गया है, तो इसका मतलब यह नहीं है कि पेज लोड हो गया है. किसी पेज को पूरी तरह से काम करने के लिए कितने रिसॉर्स की ज़रूरत है, इसके आधार पर यह मुमकिन है कि उपयोगकर्ता पेज के लोड होने के दौरान ही उससे इंटरैक्ट करने की कोशिश करें.
पेज लोड होने के दौरान, इंटरैक्शन के इनपुट में होने वाली देरी को बढ़ाने वाली एक चीज़, स्क्रिप्ट का आकलन है. नेटवर्क से JavaScript फ़ाइल फ़ेच होने के बाद, ब्राउज़र को JavaScript चलाने से पहले कुछ और काम करने होते हैं. इनमें स्क्रिप्ट को पार्स करके यह जांचना शामिल है कि उसका सिंटैक्स मान्य है या नहीं, उसे बाइट कोड में कंपाइल करना, और फिर उसे चलाना.
स्क्रिप्ट के साइज़ के आधार पर, इस काम की वजह से मुख्य थ्रेड पर ज़्यादा समय लेने वाले टास्क शुरू हो सकते हैं. इससे ब्राउज़र को उपयोगकर्ता के अन्य इंटरैक्शन का जवाब देने में देरी होगी. पेज लोड होने के दौरान, उपयोगकर्ता के इनपुट के हिसाब से पेज को रिस्पॉन्सिव बनाए रखने के लिए, यह समझना ज़रूरी है कि पेज लोड होने के दौरान, ज़्यादा समय लेने वाले टास्क की संभावना को कम करने के लिए क्या किया जा सकता है. इससे पेज तेज़ी से लोड होता है.
इवेंट कॉलबैक को ऑप्टिमाइज़ करना
आईएनपी, इनपुट में होने वाली देरी के अलावा और भी चीज़ें मेज़र करता है. आपको यह भी पक्का करना होगा कि उपयोगकर्ता के इंटरैक्शन के जवाब में चलने वाले इवेंट कॉलबैक, जल्द से जल्द पूरे हो सकें.
मुख्य थ्रेड को अक्सर यील्ड करें
इवेंट कॉलबैक को ऑप्टिमाइज़ करने के लिए, सबसे सही सलाह यह है कि उनमें कम से कम काम किया जाए. हालांकि, हो सकता है कि आपके इंटरैक्शन का लॉजिक जटिल हो और आप उनके काम को थोड़ा ही कम कर पाएं.
अगर आपको लगता है कि आपकी वेबसाइट के लिए भी ऐसा ही है, तो इवेंट कॉलबैक में मौजूद काम को अलग-अलग टास्क में बांटें. इससे, एक साथ किए जाने वाले काम को ज़्यादा समय लेने वाले काम में बदलने से रोका जा सकता है. ज़्यादा समय लेने वाले काम, मुख्य थ्रेड को ब्लॉक कर देते हैं. इससे अन्य इंटरैक्शन को मुख्य थ्रेड पर इंतज़ार करना पड़ता है. हालांकि, इस तरीके से अन्य इंटरैक्शन को मुख्य थ्रेड पर इंतज़ार नहीं करना पड़ता और वे जल्दी रन हो जाते हैं.
टास्क को छोटे-छोटे हिस्सों में बांटने का एक तरीका setTimeout है. ऐसा इसलिए, क्योंकि इसमें पास किया गया कॉलबैक, नए टास्क में चलता है. setTimeout का इस्तेमाल अपने-आप किया जा सकता है या ज़्यादा बेहतर तरीके से नतीजे पाने के लिए, इसके इस्तेमाल को किसी अलग फ़ंक्शन में शामिल किया जा सकता है.
बिना सोचे-समझे यील्ड करना, बिलकुल भी यील्ड न करने से बेहतर है. हालांकि, मुख्य थ्रेड को यील्ड करने का एक और तरीका है. इसमें यूज़र इंटरफ़ेस को अपडेट करने वाले इवेंट कॉलबैक के तुरंत बाद यील्ड करना शामिल है, ताकि रेंडरिंग लॉजिक को जल्दी चलाया जा सके.
रेंडरिंग का काम जल्दी पूरा करने के लिए, यील्ड करें
यील्डिंग की एक बेहतर तकनीक में, इवेंट कॉलबैक में कोड को इस तरह से स्ट्रक्चर किया जाता है कि सिर्फ़ वही लॉजिक रन हो जो अगले फ़्रेम के लिए विज़ुअल अपडेट लागू करने के लिए ज़रूरी है. बाकी सभी चीज़ों को बाद के टास्क के लिए टाला जा सकता है. इससे न सिर्फ़ कॉलबैक हल्के और तेज़ रहते हैं, बल्कि इंटरैक्शन के लिए रेंडर होने में लगने वाला समय भी कम हो जाता है. ऐसा इसलिए होता है, क्योंकि इवेंट कॉलबैक कोड पर विज़ुअल अपडेट ब्लॉक नहीं होते.
उदाहरण के लिए, एक ऐसे रिच टेक्स्ट एडिटर की कल्पना करें जो आपके टाइप करते ही टेक्स्ट को फ़ॉर्मैट करता है. साथ ही, आपके लिखे गए टेक्स्ट के हिसाब से यूज़र इंटरफ़ेस (यूआई) के अन्य पहलुओं को भी अपडेट करता है. जैसे, शब्दों की संख्या, वर्तनी की गलतियों को हाइलाइट करना, और अन्य ज़रूरी विज़ुअल फ़ीडबैक. इसके अलावा, ऐप्लिकेशन को आपके लिखे गए कॉन्टेंट को सेव करने की ज़रूरत भी पड़ सकती है. इससे, ऐप्लिकेशन को छोड़ने और वापस आने पर, आपका कोई भी काम नहीं छूटेगा.
इस उदाहरण में, उपयोगकर्ता के टाइप किए गए वर्णों के जवाब में ये चार चीज़ें होनी चाहिए. हालांकि, अगला फ़्रेम दिखाने से पहले, सिर्फ़ पहला आइटम पूरा करना ज़रूरी है.
- उपयोगकर्ता ने जो टाइप किया है उसके हिसाब से टेक्स्ट बॉक्स को अपडेट करें और ज़रूरी फ़ॉर्मैटिंग लागू करें.
- यूज़र इंटरफ़ेस (यूआई) के उस हिस्से को अपडेट करना जो मौजूदा शब्द संख्या दिखाता है.
- स्पेलिंग की गलतियों की जांच करने के लिए लॉजिक चलाएं.
- हाल ही में किए गए बदलावों को सेव करना (लोकल या रिमोट डेटाबेस में).
इसके लिए, कोड कुछ ऐसा दिख सकता है:
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 में ऐसी कई प्रॉपर्टी होती हैं जिनकी वजह से लेआउट थ्रैशिंग हो सकती है.
लेआउट थ्रैशिंग की वजह से परफ़ॉर्मेंस में रुकावट आती है. ऐसा इसलिए होता है, क्योंकि स्टाइल अपडेट करने के बाद, JavaScript में उन स्टाइल की वैल्यू का तुरंत अनुरोध करने पर, ब्राउज़र को सिंक्रोनस लेआउट का काम करना पड़ता है. ऐसा न होने पर, इवेंट कॉलबैक के चलने के बाद, ब्राउज़र को एसिंक्रोनस तरीके से काम करने के लिए इंतज़ार करना पड़ सकता है.
प्रज़ेंटेशन में होने वाली देरी को कम करना
किसी इंटरैक्शन मार्क की प्रज़ेंटेशन में देरी, इंटरैक्शन के इवेंट कॉलबैक के चलने के बाद से शुरू होती है. यह तब तक चलती है, जब तक ब्राउज़र अगला फ़्रेम नहीं दिखा देता. इस फ़्रेम में, विज़ुअल में हुए बदलाव दिखते हैं.
डीओएम साइज़ को कम करना
जब किसी पेज का डीओएम छोटा होता है, तो रेंडरिंग का काम आम तौर पर जल्दी पूरा हो जाता है. हालांकि, जब डीओएम बहुत बड़े हो जाते हैं, तो डीओएम का साइज़ बढ़ने के साथ-साथ रेंडरिंग का काम भी बढ़ जाता है. रेंडरिंग और डीओएम के साइज़ के बीच का संबंध लीनियर नहीं होता. हालांकि, छोटे डीओएम की तुलना में बड़े डीओएम को रेंडर करने के लिए ज़्यादा काम करना पड़ता है. बड़ा डीओएम दो मामलों में समस्या पैदा करता है:
- पेज के शुरुआती रेंडर के दौरान, जब बड़े DOM को पेज की शुरुआती स्थिति को रेंडर करने के लिए बहुत ज़्यादा काम करना पड़ता है.
- उपयोगकर्ता के इंटरैक्शन के जवाब में, जहां बड़ा डीओएम रेंडरिंग अपडेट को बहुत महंगा बना सकता है. इसलिए, ब्राउज़र को अगला फ़्रेम दिखाने में ज़्यादा समय लगता है.
ध्यान रखें कि कुछ मामलों में, बड़े डीओएम को काफ़ी हद तक कम नहीं किया जा सकता. डीओएम के साइज़ को कम करने के लिए, कई तरीके अपनाए जा सकते हैं. जैसे, डीओएम को फ़्लैट करना या उपयोगकर्ता के इंटरैक्शन के दौरान डीओएम में जोड़ना, ताकि शुरुआती डीओएम का साइज़ छोटा रहे. हालांकि, ये तकनीकें कुछ हद तक ही काम करती हैं.
ऑफ़-स्क्रीन एलिमेंट को लेज़ी रेंडर करने के लिए, content-visibility का इस्तेमाल करें
पेज लोड होने के दौरान रेंडरिंग के काम को सीमित करने और उपयोगकर्ता के इंटरैक्शन के जवाब में रेंडरिंग के काम को सीमित करने का एक तरीका है, सीएसएस content-visibility प्रॉपर्टी का इस्तेमाल करना. इससे व्यूपोर्ट के करीब आने पर, एलिमेंट को लेज़ी रेंडर किया जा सकता है. content-visibility का असरदार तरीके से इस्तेमाल करने के लिए, कुछ प्रैक्टिस की ज़रूरत पड़ सकती है. हालांकि, अगर इससे रेंडर होने में लगने वाला समय कम होता है, तो यह आपके पेज के आईएनपी को बेहतर बना सकता है.
JavaScript का इस्तेमाल करके एचटीएमएल रेंडर करते समय, परफ़ॉर्मेंस पर पड़ने वाले असर का ध्यान रखें
जहां एचटीएमएल होता है वहां एचटीएमएल पार्सिंग होती है. ब्राउज़र, एचटीएमएल को डीओएम में पार्स करने के बाद, उस पर स्टाइल लागू करता है, लेआउट का हिसाब लगाता है, और फिर उस लेआउट को रेंडर करता है. यह एक ऐसी लागत है जिससे बचा नहीं जा सकता. हालांकि, एचटीएमएल को रेंडर करने का तरीका मायने रखता है.
जब सर्वर एचटीएमएल भेजता है, तो वह ब्राउज़र में स्ट्रीम के तौर पर पहुंचता है. स्ट्रीमिंग का मतलब है कि सर्वर से एचटीएमएल रिस्पॉन्स, अलग-अलग हिस्सों में मिल रहा है. ब्राउज़र, स्ट्रीम को मैनेज करने के तरीके को ऑप्टिमाइज़ करता है. इसके लिए, वह स्ट्रीम के हिस्सों को धीरे-धीरे पार्स करता है और उन्हें थोड़ा-थोड़ा करके रेंडर करता है. यह परफ़ॉर्मेंस ऑप्टिमाइज़ेशन की एक सुविधा है. इसमें ब्राउज़र, पेज लोड होने के दौरान समय-समय पर और अपने-आप, मुख्य थ्रेड को अन्य टास्क के लिए उपलब्ध कराता है. इसके लिए, आपको कुछ नहीं करना पड़ता.
किसी भी वेबसाइट पर पहली बार जाने पर, हमेशा कुछ एचटीएमएल शामिल होता है. आम तौर पर, एचटीएमएल के शुरुआती हिस्से से शुरुआत की जाती है. इसके बाद, कॉन्टेंट वाले हिस्से को भरने के लिए JavaScript का इस्तेमाल किया जाता है. कॉन्टेंट के उस हिस्से में होने वाले बाद के अपडेट भी, उपयोगकर्ता के इंटरैक्शन की वजह से होते हैं. आम तौर पर, इसे एक पेज का ऐप्लिकेशन (एसपीए) मॉडल कहा जाता है. इस पैटर्न की एक कमी यह है कि क्लाइंट पर JavaScript की मदद से एचटीएमएल रेंडर करने पर, आपको उस एचटीएमएल को बनाने के लिए JavaScript प्रोसेसिंग की लागत तो चुकानी ही पड़ती है. साथ ही, ब्राउज़र तब तक कोई नतीजा नहीं देगा, जब तक कि वह उस एचटीएमएल को पार्स और रेंडर नहीं कर लेता.
हालांकि, यह याद रखना ज़रूरी है कि जो वेबसाइटें एसपीए नहीं हैं उनमें भी इंटरैक्शन की वजह से, JavaScript के ज़रिए एचटीएमएल रेंडरिंग की कुछ मात्रा शामिल हो सकती है. आम तौर पर, यह ठीक है. हालांकि, ऐसा तब तक ही सही है, जब तक क्लाइंट पर बड़ी संख्या में एचटीएमएल रेंडर न किया जा रहा हो. इससे अगले फ़्रेम को दिखाने में देरी हो सकती है. हालांकि, यह समझना ज़रूरी है कि ब्राउज़र में एचटीएमएल को रेंडर करने के इस तरीके से, परफ़ॉर्मेंस पर क्या असर पड़ता है. साथ ही, अगर JavaScript का इस्तेमाल करके बहुत सारे एचटीएमएल को रेंडर किया जा रहा है, तो उपयोगकर्ता के इनपुट के हिसाब से आपकी वेबसाइट के रिस्पॉन्स पर इसका क्या असर पड़ सकता है.
नतीजा
अपनी साइट के आईएनपी को बेहतर बनाना एक ऐसी प्रोसेस है जिसे बार-बार दोहराना पड़ता है. जब फ़ील्ड में किसी धीमे इंटरैक्शन को ठीक किया जाता है, तो इस बात की काफ़ी संभावना होती है कि आपको अन्य धीमे इंटरैक्शन भी मिलने लगें. ऐसा खास तौर पर तब होता है, जब आपकी वेबसाइट पर बहुत ज़्यादा इंटरैक्टिविटी हो. आपको उन्हें भी ऑप्टिमाइज़ करना होगा.
आईएनपी को बेहतर बनाने के लिए, लगातार कोशिश करना ज़रूरी है. समय के साथ, अपने पेज को इतना रिस्पॉन्सिव बनाया जा सकता है कि उपयोगकर्ता आपके पेज पर मिलने वाले अनुभव से खुश हों. इस बात की भी संभावना है कि जब अपने उपयोगकर्ताओं के लिए नई सुविधाएं डेवलप की जाएं, तो आपको उनके हिसाब से इंटरैक्शन को ऑप्टिमाइज़ करने के लिए, इसी प्रोसेस को दोहराना पड़े. इसमें समय और मेहनत लगेगी, लेकिन यह समय और मेहनत सही जगह पर खर्च होगी.