प्रतिनिधि इंटरव्यू विषय

Frontend Interview: आपको requestIdleCallback का उपयोग कब करना चाहिए?

फ्रंटएंडमध्यम
Offer.cc संपादकीय टीमप्रकाशित अपडेट किया गया

प्रश्न

एक पेज को एनालिटिक्स इवेंट्स, गैर-महत्वपूर्ण प्रीफ़ेच और डेफर्ड DOM कार्य को प्रोसेस करना है। आप requestIdleCallback का उपयोग कैसे करेंगे, और इससे कब बचेंगे?

1. प्रश्न और संदर्भ

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

2. इंटरव्यूअर क्या मूल्यांकन कर रहा है

  • क्या आप समझते हैं कि requestIdleCallback ब्राउज़र के आइडल समय के दौरान कम-प्राथमिकता वाले कार्य को शेड्यूल करता है; यह थ्रेड को प्रीएम्प्ट (preempt) नहीं करता है।
  • क्या आप चंक्स के लिए IdleDeadline.timeRemaining() का उपयोग करते हैं और कार्य की समय-सीमा होने पर timeout सेट करते हैं।
  • क्या आप सीमित ब्राउज़र समर्थन को पहचानते हैं और स्पष्ट फ़ॉलबैक सेमेन्टिक्स के साथ कैपेबिलिटी डिटेक्शन डिज़ाइन करते हैं।
  • क्या आप गणना, नेटवर्क सेंडिंग, DOM म्यूटेशन और एनिमेशन टाइमिंग को अलग करते हैं, और फिर इंटरैक्शन प्रभाव को मापते हैं।

Coursera की फ़्रंटएंड इंटरव्यू गाइड परफ़ॉर्मेंस ऑप्टिमाइज़ेशन, प्रोडक्शन मेट्रिक्स और ट्रेड-ऑफ़ को मुख्य मूल्यांकन क्षेत्रों के रूप में सूचीबद्ध करती है। MDN requestIdleCallback() को आइडल अवधियों के दौरान बैकग्राउंड वर्क के रूप में वर्णित करता है; इसका timeout विकल्प आवश्यक कार्य को बहुत लंबे समय तक प्रतीक्षा करने से रोक सकता है लेकिन इंटरैक्शन को नुकसान पहुंचा सकता है। Chrome का आधिकारिक उदाहरण आइडल गणना को अगले फ्रेम में DOM अपडेट से और अलग करता है।

3. उत्तर देने से पहले स्पष्ट करने वाले प्रश्न

  1. क्या कार्य में देरी की जा सकती है? एनालिटिक्स बैच, प्रीफ़ेचिंग और आवश्यक उपयोगकर्ता फ़ीडबैक पर कौन सी समय-सीमाएं लागू होती हैं?
  2. क्या कॉलबैक DOM को म्यूटेट करेगा, स्टेट अपडेट करेगा, स्टोरेज में लिखेगा, या केवल एक नेटवर्क अनुरोध भेजेगा?
  3. क्या लक्षित ब्राउज़र API का समर्थन करते हैं? यदि नहीं, तो क्या कार्य में देरी की जानी चाहिए, तुरंत चलाया जाना चाहिए, या छोड़ दिया जाना चाहिए?
  4. किस मीट्रिक की सुरक्षा की जा रही है: इनपुट विलंब (input delay), लंबे कार्य (long tasks), एनिमेशन सुगमता (animation smoothness), या एनालिटिक्स डिलीवरी?

4. 30-सेकंड का उत्तर ढांचा

मैं कार्य को त्याज्य (discardable), विलंब योग्य (deferrable), या आवश्यक (required) के रूप में वर्गीकृत करूँगा। छोटी गैर-महत्वपूर्ण गणना या सेंड कतार के लिए, मैं उपलब्ध timeRemaining() बजट के भीतर requestIdleCallback का उपयोग करूँगा और केवल तभी timeout जोड़ूँगा जब कोई समय-सीमा मायने रखती हो। कॉलबैक अप्रत्याशित DOM म्यूटेशन करने के बजाय डेटा तैयार करेगा; अगला requestAnimationFrame दृश्यमान परिवर्तनों को कमिट करेगा। मैं API का फ़ीचर-डिटेक्ट करूँगा, फ़ॉलबैक में रद्दीकरण, समाप्ति और डिलीवरी सेमेन्टिक्स को सुरक्षित रखूँगा, और इनपुट विलंब, लंबे कार्यों और व्यावसायिक पूर्णता को मापूँगा।

5. चरण-दर-चरण गहन विश्लेषण

चरण 1: तय करें कि क्या कार्य आइडल समय का हिस्सा है

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

चरण 2: बजट के भीतर कार्य को विभाजित (Chunk) करें

कॉलबैक को एक deadline प्राप्त होता है। केवल एक छोटे बैच को प्रोसेस करें जो timeRemaining() में फ़िट बैठता है और कार्य शेष रहने पर एक अन्य कॉलबैक को कतारबद्ध करें। डि-डुप्लिकेशन मार्कर का उपयोग करें ताकि प्रत्येक इवेंट एक और कॉलबैक शेड्यूल न करे। रूट परिवर्तन, अनमाउंट या नए परिणाम संस्करण पर कतारबद्ध कार्य को रद्द करें ताकि पुराने परिणाम पेज को अपडेट न कर सकें।

चरण 3: गणना, नेटवर्क और DOM टाइमिंग को अलग करें

एक आइडल कॉलबैक डेटा तैयार कर सकता है, इसे सीरियलाइज़ कर सकता है, या सेंड को कतारबद्ध कर सकता है; नेटवर्क अनुरोध स्वयं निरंतर आइडल बजट की गारंटी नहीं देता है। DOM राइट्स अप्रत्याशित लेआउट और पेंट को ट्रिगर कर सकते हैं, इसलिए आइडल समय के दौरान गणना करें या एक फ्रैगमेंट बनाएं और requestAnimationFrame में दृश्य परिवर्तनों को कमिट करें। यदि गणना अत्यधिक CPU-गहन बनी रहती है, तो एक Worker अंतहीन स्लाइसिंग की तुलना में मुख्य थ्रेड को अधिक विश्वसनीयता से अलग करता है।

चरण 4: कम्पैटिबिलिटी और मापन डिज़ाइन करें

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

6. उच्च-गुणवत्ता वाला नमूना उत्तर

मैं पहले पूछूंगा कि क्या कार्य वर्तमान इंटरैक्शन को प्रभावित करता है और इसे कब समाप्त होना चाहिए। एनालिटिक्स, गैर-महत्वपूर्ण प्रीफ़ेचिंग और स्लाइस करने योग्य सीरियलाइज़ेशन requestIdleCallback का उपयोग कर सकते हैं; इनपुट फ़ीडबैक, एनिमेशन और महत्वपूर्ण रेंडरिंग आइडल समय की प्रतीक्षा नहीं कर सकते।

मैं छोटे बैचों को तब तक प्रोसेस करूँगा जब तक timeRemaining() अपर्याप्त न हो जाए। केवल वास्तविक व्यावसायिक समय-सीमा वाली कतार को ही timeout मिलता है, और मैं यह स्वीकार करूँगा कि टाइमआउट पथ रुकावट (jank) पैदा कर सकता है। कॉलबैक डेटा तैयार करता है, जबकि requestAnimationFrame DOM परिवर्तनों को कमिट करता है। अनमाउंट और नए परिणाम संस्करण कतार को रद्द कर देते हैं ताकि पुराना कार्य वापस न लिखा जा सके।

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

7. विफलता के सामान्य तरीके

  • आइडल कॉलबैक को बैकग्राउंड थ्रेड के रूप में मानना; यह अभी भी मुख्य थ्रेड पर चलता है, इसलिए लंबा सिंक्रोनस कोड इनपुट को ब्लॉक करता है।
  • बिना शर्त एक छोटा timeout सेट करना; टाइमआउट कम-प्राथमिकता वाले कार्य को इंटरैक्शन संघर्ष के अचानक उछाल में बदल देता है।
  • आइडल कॉलबैक के अंदर बड़े DOM म्यूटेशन करना; अप्रत्याशित लेआउट और पेंट लाभ को समाप्त कर सकते हैं।
  • कैपेबिलिटी डिटेक्शन को छोड़ना और सीमित API समर्थन को सही होने के लिए एक पूर्वापेक्षा बनाना।
  • सम्मिश्रण (coalescing), डि-डुप्लिकेशन, रद्दीकरण या परिणाम-संस्करण जांच के बिना प्रति इवेंट एक बार शेड्यूल करना।

8. अनुवर्ती प्रश्न और उत्तर

अनुवर्ती 1: क्या आइडल समय न होने पर कॉलबैक हमेशा के लिए प्रतीक्षा कर सकता है?

timeout के बिना, आवश्यक कार्य लंबे समय तक प्रतीक्षा कर सकता है। समय-सीमा से बंधे कार्य को एक टाइमआउट दें और बैच को कम करें या टाइमआउट पथ पर अधिक प्रत्यक्ष शेड्यूलर चुनें। इनपुट प्रतिक्रिया का त्याग करने के बजाय त्याज्य कार्य को समाप्त होने दें।

अनुवर्ती 2: requestIdleCallback के अंदर DOM को अपडेट क्यों न करें?

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

अनुवर्ती 3: आपको Worker का उपयोग कब करना चाहिए?

जब निरंतर CPU-गहन गणना चंकिंग के बाद भी मुख्य थ्रेड पर कब्जा करती है, तो Worker का उपयोग करें। वर्कर्स सीरियलाइज़ेशन, संचार और रद्दीकरण लागत जोड़ते हैं; छोटे विलंब योग्य कार्य एक आइडल कॉलबैक के साथ सरल होते हैं।

सार्वजनिक स्रोत

संबंधित प्रश्न