प्रॉम्प्ट और संदर्भ
पेज में नेविगेशन, लेख की सामग्री, सुझाव, टिप्पणियां और वैयक्तिकृत कार्रवाइयां शामिल हैं। लेख जल्दी दिखाई देना चाहिए; जब कोई एक सेवा विफल हो जाती है, तो किसी धीमे मॉड्यूल को पहले बाइट्स को ब्लॉक नहीं करना चाहिए और न ही पूरे पेज को डाउन करना चाहिए। Suspense के साथ स्ट्रीमिंग SSR डिज़ाइन करें और बताएं कि सर्वर शेल कैसे भेजता है, बाउंड्रीज़ कैसे पूरी होती हैं, विफलताएं कैसे डिग्रेड होती हैं, और स्क्रिप्ट लोड होने के बाद क्लाइंट कैसे रिकवर होता है।
React दस्तावेज़ बताते हैं कि स्ट्रीमिंग पहले शेल और फ़ॉलबैक भेज सकती है, फिर बाउंड्रीज़ पूरी होने पर उन्हें बदल सकती है। इंटरव्यू यह जांचता है कि क्या आप उस तंत्र को नियंत्रित टाइमआउट, त्रुटि, कैश और मॉनिटरिंग व्यवहार में बदल सकते हैं।
इंटरव्यूअर क्या मूल्यांकन करता है
स्थिर शेल बनाम एसिंक्रोनस बाउंड्रीज़, अनुरोध डिडुप्लीकेशन, बाउंड्री टाइमआउट, सर्वर त्रुटियां, क्लाइंट पुनः प्रयास (retries), कैश वेरिएंट, कैंसलेशन, एक्सेसिबिलिटी और Core Web Vitals को कवर करें। बताएं कि कौन सी सामग्री सिंक्रोनस होनी चाहिए और किसे विलंबित किया जा सकता है।
पूछने के लिए स्पष्टीकरण प्रश्न
- क्या फर्स्ट-स्क्रीन का लक्ष्य TTFB, LCP, या इंटरैक्शन का समय है, और प्रत्येक का बजट क्या है?
- लेख, सुझाव, टिप्पणियों और वैयक्तिकरण पर कौन सा उपलब्धता और गोपनीयता स्तर लागू होता है?
- क्या पेज CDN पर कैश किया गया है, और कौन से उपयोगकर्ता, क्षेत्र या प्रयोग वेरिएंट मौजूद हैं?
- धीमे-मॉड्यूल की विफलता पर, क्या UI को खाली स्थिति, पुराना डेटा दिखाना चाहिए या पुनः प्रयास करना चाहिए?
- यदि क्लाइंट JavaScript विफल हो जाता है तो किन मुख्य पाथ्स को काम करना चाहिए?
30-सेकंड का उत्तर
"एक ऐसा शेल भेजें जो धीमे डेटा पर निर्भर न हो, फिर सुझावों, टिप्पणियों और वैयक्तिकरण को स्पष्ट बजट के साथ Suspense बाउंड्रीज़ में विभाजित करें। प्रत्येक बाउंड्री में एक सर्वर टाइमआउट, देखने योग्य त्रुटियां और एक स्वीकार्य फ़ॉलबैक होता है, ताकि विफलता स्थानीय ही रहे। क्लाइंट हाइड्रेशन के बाद सीमित पुनः प्रयासों और इंटरैक्शन को संभालता है। केवल सुरक्षित सार्वजनिक अंशों को कैश करें, और TTFB, LCP, INP, त्रुटियों और बाउंड्री लेटेंसी की निगरानी करें।"
चरण-दर-चरण गहन विश्लेषण
चरण 1: शेल और बाउंड्रीज़ को विभाजित करें
रूटिंग, शीर्षक, लेख संरचना और प्राथमिक शब्दार्थ (semantics) को सिंक्रोनस रूप से पूरा करें। सुझावों, टिप्पणियों और वैयक्तिकरण को अलग-अलग बाउंड्रीज़ में रखें। एक बाउंड्री को उपयोगकर्ता द्वारा समझने योग्य क्षेत्र का प्रतिनिधित्व करना चाहिए, न कि दूरस्थ निर्भरताओं के एक मनमाने संग्रह का।
shell: navigation + heading + article outline
boundary A: recommendations, budget 300 ms
boundary B: comments, budget 500 ms
boundary C: personalized actions, private and uncachedलेआउट शिफ्ट से बचने के लिए प्रत्येक फ़ॉलबैक में हेडिंग, आयाम और शब्दार्थ बनाए रखें। पेज को इतना अधिक खंडित न करें कि उपयोगकर्ता यह न समझ सकें कि क्या लोड हो रहा है।
चरण 2: स्ट्रीमिंग और कैंसलेशन बनाएं
फ़्रेमवर्क के स्ट्रीमिंग सर्वर-रेंडरिंग API का उपयोग करें ताकि शेल पहले प्रतिक्रिया में प्रवेश करे और डेटा हल होने पर बाउंड्रीज़ उसके बाद आएं। एक अनुरोध समय सीमा संलग्न करें; टाइमआउट के बाद, रिमोट कॉल को रद्द करें और एक स्वीकार्य फ़ॉलबैक उत्सर्जित करें। क्लाइंट को ऐसे सर्वर कार्य की प्रतीक्षा नहीं करनी चाहिए जिसे पहले ही रद्द कर दिया गया हो।
बाउंड्री प्रारंभ, पूर्णता, टाइमआउट और त्रुटि घटनाओं को रिकॉर्ड करें। जब क्लाइंट डिस्कनेक्ट हो जाता है, तो अधूरे फ़ेच को रद्द कर दें ताकि छोड़े गए पेज डेटाबेस या सुझाव क्षमता का उपभोग न करें।
चरण 3: सर्वर और क्लाइंट त्रुटियों को संभालें
सर्वर बाउंड्री के अंदर एक त्रुटि को शेल और पूर्ण हो चुके सिब्लिंग्स को संरक्षित करते हुए उस बाउंड्री के फ़ॉलबैक में हल होना चाहिए। ऑपरेटरों के लिए एक स्थिर बाउंड्री पहचानकर्ता और अनुरोध ट्रेस ID संलग्न करें, जबकि उपयोगकर्ता-सामना करने वाले संदेश में केवल यह कहा जाए कि अनुभाग अस्थायी रूप से अनुपलब्ध है।
क्लाइंट कोड लोड होने के बाद, योग्य बाउंड्रीज़ के लिए सीमित, बैकऑफ़-आधारित पुनः प्रयासों की अनुमति दें। पुनः प्रयासों के लिए प्रयास सीमा, इडेम्पोटेंसी शर्तों और कैंसलेशन की आवश्यकता होती है। यदि क्लाइंट स्क्रिप्ट विफल हो जाती हैं, तो लेख का टेक्स्ट, लिंक और मुख्य फॉर्म उपयोग योग्य रहने चाहिए।
चरण 4: कैश बाउंड्रीज़ को परिभाषित करें
मार्ग (route), भाषा, क्षेत्र और सामग्री संस्करण के लिए कुंजियों के साथ सार्वजनिक लेख सामग्री और गैर-उपयोगकर्ता मॉड्यूल को कैश करें। वैयक्तिकृत बाउंड्रीज़ को सार्वजनिक HTML कैश में प्रवेश नहीं करना चाहिए; प्रयोग कुंजी में स्पष्ट होने चाहिए या किनारे (edge) पर अलग किए जाने चाहिए।
कैश हिट से पुराने स्रोत डेटा को छिपाना नहीं चाहिए। प्रत्येक अंश के लिए निर्माण समय, समाप्ति और संस्करण रिकॉर्ड करें, और एक सुसंगत ताजगी नीति का उपयोग करें। अंतिम संयोजित स्ट्रीम को कैश करने के बारे में सतर्क रहें; सुरक्षित अंश आमतौर पर बेहतर सीमा होते हैं।
चरण 5: एक्सेसिबिलिटी और लेआउट स्थिरता बनाए रखें
फ़ॉलबैक और अंतिम सामग्री में समान सिमेंटिक हेडिंग, लैंडमार्क और आयाम बाधाएं बनाए रखें। प्रतिस्थापन को कीबोर्ड फ़ोकस को किसी अदृश्य नोड पर नहीं ले जाना चाहिए। गतिशील क्षेत्रों को पूरे पेज को बार-बार पढ़े बिना उचित स्थिति घोषणा की आवश्यकता होती है।
छवि और मीडिया आयामों को आरक्षित करें और स्केलेटन ज्यामिति को स्थिर रखें; CLS की निगरानी करें। लेख की मुख्य सामग्री को एक प्रारंभिक दृश्यमान बाउंड्री के अंदर रखें, और LCP तत्व को एक अनियंत्रित लॉन्ग-टेल अनुरोध के पीछे न रखें।
चरण 6: रिलीज़ और ऑब्ज़र्वेबिलिटी गेट्स जोड़ें
रिलीज़-पूर्व परीक्षण धीमी निर्भरताओं, 500 प्रतिक्रियाओं, डिस्कनेक्ट, क्लाइंट-स्क्रिप्ट विफलता, कैश प्रदूषण और कैंसलेशन को कवर करते हैं। उत्पादन में, रूट, बाउंड्री और निर्भरता के आधार पर TTFB, LCP, INP, बाउंड्री p50/p95, टाइमआउट दर, फ़ॉलबैक दर और पुनः प्रयास सफलता को मापें।
कैनरी के दौरान, उच्च-जोखिम वाले वैयक्तिकरण को खोलने से पहले शेल और महत्वपूर्ण बाउंड्रीज़ का निरीक्षण करें। यदि त्रुटियां या टेल लेटेंसी एक सीमा को पार करती हैं, तो ट्रैफ़िक को बढ़ाने के बजाय बाउंड्री संरचना या स्थिर फ़ॉलबैक को वापस रोलबैक करें।
एक मजबूत नमूना उत्तर
मैं फर्स्ट-स्क्रीन बजट और उपलब्धता स्तरों को परिभाषित करूँगा, फिर लेख शेल, सुझावों, टिप्पणियों और वैयक्तिकरण को स्वतंत्र Suspense बाउंड्रीज़ में विभाजित करूँगा। प्रत्येक बाउंड्री को एक टाइमआउट, फ़ॉलबैक, कैंसलेशन पाथ और ट्रेस ID मिलता है; विफलताएं स्थानीय रहती हैं। सार्वजनिक अंश सुरक्षित कैश आयामों का उपयोग करते हैं, जबकि वैयक्तिकरण कभी भी साझा कैश में प्रवेश नहीं करता है। मैं डिस्कनेक्ट और स्क्रिप्ट विफलता का परीक्षण करूँगा, और LCP, INP, CLS, बाउंड्री p95 और फ़ॉलबैक दर की निगरानी करूँगा।
सामान्य गलतियां
- पूरे पेज को एक बाउंड्री में लपेटना → सबसे धीमी निर्भरता सब कुछ ब्लॉक कर देती है → उपयोगकर्ता द्वारा समझने योग्य क्षेत्र के अनुसार विभाजित करें।
- फ़ॉलबैक को कोई निश्चित आयाम न देना → प्रतिस्थापन CLS बनाता है → स्थान आरक्षित करें और शब्दार्थ बनाए रखें।
- वैयक्तिकृत HTML को सार्वजनिक कैश में रखना → उपयोगकर्ता डेटा लीक हो सकता है → निजी अंशों को अलग करें और सुरक्षित कुंजी आयाम शामिल करें।
- सर्वर टाइमआउट के बाद हमेशा पुनः प्रयास करते रहना → निर्भरता का दबाव बढ़ जाता है → बजट, बैकऑफ़, सीमा और कैंसलेशन का उपयोग करें।
- केवल सफलता का परीक्षण करना → डिस्कनेक्ट या स्क्रिप्ट विफलता पेज को अनुपयोगी बना देती है → त्रुटियों, कैंसलेशन और नो-स्क्रिप्ट डिग्रेडेशन का परीक्षण करें।
अनुवर्ती प्रश्न और प्रतिक्रियाएं
अनुवर्ती 1: क्या अधिक बाउंड्रीज़ हमेशा बेहतर होती हैं?
नहीं। बाउंड्रीज़ को स्वतंत्र उपयोगकर्ता क्षेत्रों और विफलता डोमेन पर मैप करना चाहिए। अत्यधिक बारीक बाउंड्रीज़ फ़ॉलबैक शोर, मॉनिटरिंग लागत और कैश वेरिएंट जोड़ती हैं; अपरिष्कृत बाउंड्रीज़ ब्लॉकिंग डोमेन को बढ़ाती हैं।
अनुवर्ती 2: आप किसी एक त्रुटि को स्ट्रीम को समाप्त करने से कैसे रोकते हैं?
रिकवरी को बाउंड्री के सर्वर और क्लाइंट पाथ के अंदर रखें, पहले से भेजे गए शेल को सुरक्षित रखें, और प्रत्येक बाउंड्री के लिए एक स्थिर फ़ॉलबैक प्रदान करें। प्रतिक्रिया का कुछ हिस्सा पहले ही भेजे जाने के बाद विफलताओं का परीक्षण करें।
अनुवर्ती 3: कौन से मेट्रिक्स साबित करते हैं कि डिज़ाइन काम करता है?
TTFB, LCP, INP, CLS, बाउंड्री p95, टाइमआउट दर, फ़ॉलबैक दर और पुनः प्रयास सफलता को एक साथ ट्रैक करें। केवल औसत प्रतिक्रिया समय टेल लेटेंसी और स्थानीय विफलताओं को छुपाता है।
अनुवर्ती 4: आप प्रयोग या उपयोगकर्ता-डेटा कैश लीक को कैसे रोकते हैं?
कुंजी में उपयोगकर्ता, प्रयोग, क्षेत्र, भाषा और सामग्री-संस्करण सुरक्षा आयाम शामिल करें। जिन अंशों की सुरक्षा सिद्ध नहीं की जा सकती वे सार्वजनिक कैश से बाहर रहते हैं, और क्रॉस-यूज़र रीप्ले परीक्षण अलगाव को सत्यापित करते हैं।