प्रॉम्प्ट और संदर्भ
उपयोगकर्ता फ़िल्टर बटन पर क्लिक करने के बाद पेज के जैंकी होने की रिपोर्ट करते हैं। बताएं कि मेन-थ्रेड long tasks का पता कैसे लगाया जाए, Interaction to Next Paint (INP) पर उनके प्रभाव का आकलन कैसे किया जाए और समाधान को कैसे सत्यापित किया जाए।
इनपुट डिले (input delay), इवेंट-हैंडलर वर्क (event-handler work), और अगले पेंट (next paint) के बीच अंतर स्पष्ट करें। केवल “debounce जोड़ना” या “worker का उपयोग करना” कोई निदान नहीं है। वास्तविक उपयोगकर्ता साक्ष्य, लैब ट्रेसेस, रिग्रेशन मेट्रिक्स और फॉलबैक सीमाओं को शामिल करें।
साक्षात्कारकर्ता क्या जांच रहा है
परफॉर्मेंस मॉडल
एक मजबूत उत्तर किसी इंटरैक्शन को इनपुट वेटिंग, इवेंट प्रोसेसिंग, रेंडरिंग और पेंटिंग में विभाजित करता है, फिर यह समझाता है कि व्यस्त मेन-थ्रेड ब्राउज़र के फीडबैक में देरी क्यों करता है।
साक्ष्य-आधारित निदान
अनुमान लगाने के बजाय स्क्रिप्ट, कंपोनेंट और डेटा साइज़ की पहचान करने के लिए PerformanceObserver, ब्राउज़र Performance ट्रेसेस और इंटरैक्शन संदर्भ का उपयोग करें।
सुधार के ट्रेड-ऑफ
सीरियलाइज़ेशन और स्टेट स्थिरता को ध्यान में रखते हुए टास्क स्प्लिटिंग, सिंक्रोनस कार्य को कम करने, वर्चुअलाइज़ेशन, गैर-महत्वपूर्ण अपडेट्स को टालने और वर्कर्स पर चर्चा करें।
वास्तविक उपयोगकर्ता सत्यापन
p75 INP, long-task काउंट, इंटरैक्शन पर्सेंटाइल और व्यावसायिक रूपांतरण (conversion) की तुलना करें। लैब सैंपल्स को वास्तविक डिवाइसों, नेटवर्क्स और लो-एंड CPUs से अलग रखें।
स्पष्टीकरण के लिए पूछे जाने वाले प्रश्न
- क्या जैंक हर इंटरैक्शन को प्रभावित करता है या केवल एक फ़िल्टर शर्त को?
- कौन से डिवाइस, ब्राउज़र और डेटा साइज़ दायरे में हैं?
- क्या समस्या इनिशियल लोड, इवेंट प्रोसेसिंग, या इवेंट के बाद के लेआउट और पेंट में है?
- क्या वास्तविक उपयोगकर्ताओं के INP, इवेंट ड्यूरेशन और long-task सैंपल्स उपलब्ध हैं?
- क्या परिणामों को सिंक्रोनस रूप से अपडेट होना चाहिए, या क्या गणना समाप्त होने से पहले UI प्रतिक्रिया दे सकता है?
- क्या सॉर्टिंग, पेजिनेशन या परिणाम की शुद्धता (precision) में बदलाव किया जा सकता है?
30-सेकंड उत्तर रूपरेखा
“मैं प्रभावित पेज को खोजने के लिए वास्तविक उपयोगकर्ता INP और इंटरैक्शन सैंपल्स का उपयोग करूंगा, फिर उसी डिवाइस और डेटा साइज़ के साथ एक Performance ट्रेस रिकॉर्ड करूंगा। PerformanceObserver 50ms से अधिक के long tasks को एकत्र कर सकता है; ट्रेस कॉल स्टैक और पेंट फेज़ का पता लगाता है। यदि सिंक्रोनस इवेंट वर्क बहुत बड़ा है, तो मैं काम को विभाजित करूंगा, री-रेंडर कम करूंगा और लिस्ट को वर्चुअलाइज़ करूंगा। मैं मैसेज और सीरियलाइज़ेशन लागत को शामिल करते हुए, केवल लाभदायक शुद्ध CPU कार्य के लिए worker पर विचार करूंगा। इसके बाद मैं p75 INP, इंटरैक्शन long tasks और रूपांतरण की तुलना करूंगा।”
चरण-दर-चरण गहन विश्लेषण
चरण 1: बेसलाइन स्थापित करें
पेज, इंटरैक्शन, डिवाइस और रिलीज़ के आधार पर p75 INP, इवेंट ड्यूरेशन, नेक्स्ट-पेंट डिले, long-task काउंट और त्रुटियों को विभाजित करें। एक तेज़ स्थानीय मशीन संपूर्ण आबादी के लिए बेसलाइन नहीं हो सकती।
चरण 2: पुनरुत्पादन और स्थान निर्धारण
ब्राउज़र Performance पैनल में फ़िल्टर इंटरैक्शन को रिकॉर्ड करें। मेन-थ्रेड फ्लेम चार्ट, long tasks, लेआउट और पेंट का निरीक्षण करें। एक PerformanceObserver रनटाइम long-task प्रविष्टियों को एकत्र कर सकता है और पेज, इंटरैक्शन तथा रिलीज़ संदर्भ जोड़ सकता है।
चरण 3: बाधाओं (Bottlenecks) को अलग करें
लंबा इनपुट इंतज़ार किसी पूर्ववर्ती सिंक्रोनस टास्क की ओर इशारा करता है; लंबा इवेंट वर्क पार्सिंग, फ़िल्टरिंग या स्टेट अपडेट की ओर इशारा करता है; लंबा पेंट लेआउट, स्टाइल या बड़े DOM की ओर इशारा करता है। INP पूरे इनपुट-टू-नेक्स्ट-पेंट पथ को मापता है, किसी एक फ़ंक्शन की अवधि को नहीं।
चरण 4: सिंक्रोनस कार्य को कम करें
पेजिनेशन, वर्चुअलाइज़ेशन, इंक्रीमेंटल फ़िल्टरिंग और कैशिंग के साथ गणना और री-रेंडर्स को कम करें। लॉगिंग, प्रीफेचिंग और एनालिटिक्स को महत्वपूर्ण इंटरैक्शन पथ से बाहर ले जाएं। आइडल (idle) या चंक्ड शेड्यूलिंग का उपयोग केवल तभी करें जब अपर्याप्त आइडल समय के लिए कोई योजना मौजूद हो।
चरण 5: Worker का मूल्यांकन करें
एक worker ट्रांसफ़रेबल या प्रबंधनीय डेटा वाले शुद्ध CPU कार्य के लिए उपयुक्त होता है। बड़े डेटा की कॉपियाँ, लगातार मैसेजिंग और DOM एक्सेस इसके फायदों को समाप्त कर सकते हैं। परिणामों का वर्ज़न बनाएं, पुराने कार्य को रद्द करें, और पुराने फ़िल्टर को नई स्थिति पर ओवरराइट करने से रोकें।
चरण 6: सत्यापन और रिग्रेशन की रोकथाम
प्रतिनिधि लो-एंड डिवाइसों और डेटासेट्स पर दोबारा चलाएं, फिर धीरे-धीरे रोल आउट करें। p75/p95 INP, long-task काउंट, इंटरैक्शन पूर्णता, रद्दीकरण और रूपांतरण की तुलना करें। एक परफ़ॉर्मेंस बजट सेट करें जो रिग्रेशन के बारे में सचेत करे या उसे ब्लॉक करे।
मॉडल उच्च-गुणवत्ता उत्तर
“मैं पहले वास्तविक उपयोगकर्ता डेटा का उपयोग उस इंटरैक्शन, डिवाइस और रिलीज़ की पहचान करने के लिए करूंगा जहां समस्या केंद्रित है, फिर उसी डेटा साइज़ के साथ फ़िल्टर को रिकॉर्ड करूंगा। ट्रेस एक ही हैंडलर में ऐरे फ़िल्टरिंग, स्टेट अपडेट और लिस्ट लेआउट दिखाता है, इसलिए मैं फ़िल्टरिंग को कैश करूंगा, लिस्ट को वर्चुअलाइज़ करूंगा और गैर-महत्वपूर्ण काम को टाल दूंगा।
मैं PerformanceObserver के साथ 50ms से अधिक के long tasks को एकत्र करूंगा और उन्हें पेज तथा इंटरैक्शन के साथ सहसंबंधित करूंगा। यदि फ़िल्टरिंग एक शुद्ध CPU बाधा बनी रहती है, तो मैं इसे एक worker में ले जाऊंगा, मैसेज साइज़ को सीमित करूंगा और पुराने परिणामों को त्याग दूंगा। मैं विस्तार करने से पहले लो-एंड डिवाइसों पर इस समाधान को कैनरी रोलआउट करूंगा और p75 INP, long-task काउंट, रद्दीकरण और फ़िल्टर पूर्णता की तुलना करूंगा।”
सामान्य गलतियाँ
- केवल औसत विलंबता (average latency) को देखना → टेल यूज़र्स गायब हो जाते हैं → डिवाइस के अनुसार p75/p95 INP को विभाजित करें।
- long task को INP समझना → इनपुट और पेंट छूट जाते हैं → पूरी इंटरैक्शन टाइमलाइन को ट्रेस करें।
- किसी भी जैंक पर debounce जोड़ना → आवश्यक फीडबैक में देरी हो सकती है → पहले गणना, रेंडर और नेटवर्क बाधाओं का पता लगाएं।
- सभी कार्यों को worker में ले जाना → कॉपी और मैसेजिंग लागत बढ़ जाती है → केवल लाभदायक शुद्ध CPU कार्य को माइग्रेट करें।
- केवल डेवलपमेंट लैपटॉप पर परीक्षण करना → लो-एंड डिवाइस अभी भी जैंक करते हैं → प्रतिनिधि डिवाइसों, डेटा और रोलआउट समूहों पर दोबारा जांचें।
- रद्दीकरण के बिना चंकिंग करना → पुराने परिणाम नई स्थिति को ओवरराइट कर देते हैं → वर्ज़न, रद्दीकरण और कमिट जांच जोड़ें।
- केवल लैब Lighthouse का उपयोग करना → वास्तविक इंटरैक्शन छूट जाते हैं → वास्तविक उपयोगकर्ता INP और long tasks का नमूना लें।
- सुधार के बाद कोई परफ़ॉर्मेंस बजट न होना → रिग्रेशन पर किसी का ध्यान नहीं जाता → सीमाएं निर्धारित करें और निरंतर निगरानी रखें।
फॉलो-अप प्रश्न और उत्तर
फॉलो-अप 1: एक long task केवल 60ms का है। फिर भी INP खराब क्यों है?
हैंडलर के बाद इनपुट इंतज़ार, लेआउट और पेंट तथा आस-पास के कार्यों का निरीक्षण करें। INP संपूर्ण प्रतिक्रिया पथ है; केवल 60ms का एक टास्क पूरा स्पष्टीकरण नहीं है।
फॉलो-अप 2: क्या होगा यदि worker परिणाम को और धीमा कर दे?
सीरियलाइज़ेशन, ट्रांसफर और शेड्यूलिंग को मापें। छोटे डेटा के लिए मेन-थ्रेड पर एक फ़ास्ट पाथ रखें, बड़े संदेशों को बैच करें या ट्रांसफ़र बफ़र्स का उपयोग करें, और पुराने अनुरोधों को रद्द करें।
फॉलो-अप 3: आप long-task के स्रोतों का अवलोकन कैसे करते हैं?
PerformanceObserver के साथ प्रारंभ समय, अवधि, पेज और रिलीज़ रिकॉर्ड करें, फिर कॉल स्टैक के लिए Performance ट्रेस का उपयोग करें। संवेदनशील उपयोगकर्ता इनपुट को कभी भी लॉग न करें।
फॉलो-अप 4: क्या होगा यदि फ़िल्टरिंग को तुरंत महसूस होना चाहिए?
इनपुट को स्वीकार करें और सिंक्रोनस रूप से प्रगति दिखाएं, फिर इंक्रीमेंटल रूप से गणना करें। परिणाम के वर्ज़नों को फ़िल्टर स्थिति के साथ संरेखित रखें और एक अस्थायी बनाम पूर्ण स्थिति प्रदर्शित करें।
फॉलो-अप 5: आप यह कैसे साबित करेंगे कि रूपांतरण को कोई नुकसान नहीं पहुंचा?
परिवर्तन को कैनरी रिलीज़ करें और स्पष्ट स्टॉप शर्तों के साथ डिवाइस और नेटवर्क द्वारा p75 INP, पूर्णता, रद्दीकरण, त्रुटियों और मुख्य रूपांतरण की तुलना करें।
स्रोत 1: MDN परफ़ॉर्मेंस डेटा
MDN long-task रिकॉर्ड्स को 50ms या उससे अधिक समय तक चलने वाले कार्यों के रूप में परिभाषित करता है, जो मेन-थ्रेड ब्लॉकिंग का रनटाइम साक्ष्य प्रदान करते हैं।
स्रोत 2: PerformanceObserver
MDN PerformanceObserver के साथ परफ़ॉर्मेंस प्रविष्टियों का अवलोकन करने का दस्तावेज़ीकरण करता है, जो long tasks और रिलीज़ संदर्भ के रनटाइम संग्रह का समर्थन करता है।
स्रोत 3: web.dev Long Tasks और INP
web.dev बताता है कि long tasks मेन थ्रेड को ब्लॉक करते हैं और फीडबैक में देरी करते हैं, और काम को विभाजित करने, सिंक्रोनस काम को कम करने और workers का मूल्यांकन करने की सिफारिश करता है; INP इंटरैक्शन-टू-नेक्स्ट-पेंट रिस्पॉन्सिवनेस को मापता है।