लैब में धीमे इंटरैक्शन का मैन्युअल रूप से विश्लेषण करें

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

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

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

अगर आपके पास फ़ील्ड डेटा नहीं है, तो क्या होगा?

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

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

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

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

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

लैब में धीमे इंटरैक्शन फिर से करना

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

ट्रेस रिकॉर्ड करें

धीमे इंटरैक्शन का पता लगाने और समस्या हल करने के लिए, Chrome का परफ़ॉर्मेंस प्रोफ़ाइलर टूल इस्तेमाल करने का सुझाव दिया जाता है. Chrome के परफ़ॉर्मेंस प्रोफ़ाइलर में किसी इंटरैक्शन को प्रोफ़ाइल करने के लिए, यह तरीका अपनाएं:

  1. जिस पेज की जांच करनी है उसे खुला रखें.
  2. Chrome DevTools खोलें और परफ़ॉर्मेंस पैनल पर जाएं.
  3. ट्रेस करना शुरू करने के लिए पैनल के ऊपर बाईं ओर रिकॉर्ड करें बटन पर क्लिक करें.
  4. वे इंटरैक्शन करें जिनसे जुड़ी समस्या हल करनी है.
  5. ट्रेस करना बंद करने के लिए रिकॉर्ड करें बटन पर फिर से क्लिक करें.

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

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

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

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

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

इंटरैक्शन ट्रैक में, बार-बार होने वाली गतिविधि पर कर्सर घुमाकर, इस बारे में ज़्यादा जानकारी पाई जा सकती है कि इंटरैक्शन का कौनसा हिस्सा सबसे लंबा था:

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

बातचीत का धारीदार हिस्सा यह दिखाता है कि इंटरैक्शन का समय 200 मिलीसेकंड से कितना ज़्यादा है, जो "अच्छे" की ऊपरी सीमा है थ्रेशोल्ड के हिसाब से सेट किया जा सकता है. यहां बातचीत के ये हिस्से शामिल किए गए हैं:

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

यहां पर, इंटरैक्शन धीमा होने की वजह(समस्याओं) की गहराई से जांच करने की ज़रूरत है, जिसके बारे में इस गाइड में आगे बताया गया है.

वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी देने वाला Chrome एक्सटेंशन

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

इंस्टॉल होने के बाद, अगर आपने यह तरीका अपनाया है, तो Web Vitals एक्सटेंशन, DevTools कंसोल में इंटरैक्शन का डेटा दिखाता है:

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

इन चरणों को पूरा करने के बाद, Chrome DevTools में कंसोल खोलें. इसके बाद, किसी पेज पर संदिग्ध इंटरैक्शन की जांच करना शुरू करें. इंटरैक्ट करने पर, डाइग्नोस्टिक्स डेटा कंसोल में दिखेगा:

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

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

कैसे पता लगाएं कि इंटरैक्शन का कौनसा हिस्सा धीमा है

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

इनपुट में देरी की पहचान कैसे करें

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

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

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

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

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

प्रोसेसिंग की लंबी अवधि की पहचान करने का तरीका

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

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

महंगे इवेंट कॉलबैक ढूंढने के लिए, किसी खास इंटरैक्शन के ट्रेस में इन्हें देखा जा सकता है:

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

किसी इंटरैक्शन की प्रोसेसिंग अवधि को कम करने के लिए, इनमें से कोई एक रणनीति आज़माएं:

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

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

प्रज़ेंटेशन में देरी का पता कैसे लगाएं

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

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

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

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

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

क्या होगा अगर आपको धीमा इंटरैक्शन करने में दिक्कत हो रही है?

क्या होगा अगर आपके फ़ील्ड डेटा से पता चलता है कि कोई विशेष इंटरैक्शन धीमा है, लेकिन आप लैब में समस्या को मैन्युअल रूप से फिर से नहीं कर पा रहे हैं? कई वजहों से ऐसा हो सकता है.

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

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

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

आईएनपी से जुड़ी समस्या का हल बार-बार किया जाता है

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

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