प्रॉम्ट और संदर्भ
यह HTTP, गेटवे और परफॉरमेंस से जुड़ा प्रश्न बैकएंड, प्लेटफॉर्म और इंफ्रास्ट्रक्चर भूमिकाओं के लिए उपयुक्त है। अंतिम HTML तैयार होने से पहले ओरिजिन के पास एक अनुमानित प्रतीक्षा समय होता है। आपको यह तय करना होगा कि क्या 103 भेजना चाहिए और गलत प्रीलोड, पुराने क्लाइंट्स द्वारा पार्सिंग की विफलताओं और डुप्लिकेट डाउनलोड से कैसे बचना चाहिए।
इंटरव्यूअर क्या मूल्यांकन करता है
- 103 संकेत (hint) सिमेंटिक्स और अंतिम-प्रतिक्रिया (final-response) सिमेंटिक्स में अंतर करना।
- मूल्य का आकलन करने के लिए सर्वर थिंक टाइम, संसाधन स्थिरता और कैश हिट्स का उपयोग करना।
- 103 को एक अनिवार्य पथ बनाने के बजाय HTTP/2 या HTTP/3 पर सुचारू फॉलबैक डिज़ाइन करना।
- यह सत्यापित करना कि प्रीलोड डुप्लिकेट अनुरोध, गलत संसाधन या अत्यधिक बैंडविड्थ की खपत न करे।
स्पष्टीकरण हेतु प्रश्न
यह पुष्टि करें कि क्या प्रतीक्षा डायनामिक HTML जेनरेशन से आ रही है या नेटवर्क ट्रांसफर से, क्या अनुरोध एक टॉप-लेवल नेविगेशन है, क्या क्लाइंट्स और प्रॉक्सी 1xx को विश्वसनीयता से संभालते हैं, क्या संसाधन URL, वर्ज़न और as मान स्थिर हैं, और क्या संसाधन कैशेबल हैं। यदि अंतिम प्रतिक्रिया तुरंत भेजी जा सकती है, तो एक सामान्य Link हेडर या HTML लिंक एलिमेंट अधिक सरल है। यदि प्रमाणीकरण, रीडायरेक्ट या वैयक्तिकरण (personalization) के साथ संसाधन बदलते हैं, तो गलत प्रारंभिक संकेत बचत से अधिक लागत पैदा कर सकते हैं।
30-सेकंड उत्तर रूपरेखा
103 अंतिम प्रतिक्रिया से पहले का एक संकेत है, पृष्ठ का परिणाम नहीं। HTML जनरेट करने के दौरान, ओरिजिन Link: rel=preload या preconnect के साथ 103 भेज सकता है ताकि क्लाइंट समानांतर में संसाधनों को तैयार कर सके; अंतिम 200 अभी भी आधिकारिक हेडर प्रदान करता है। इसे केवल तभी सक्षम करें जब सर्वर थिंक टाइम पर्याप्त हो, भविष्यवाणियां स्थिर हों, और HTTP/2 या HTTP/3 विश्वसनीय हो। पुराने क्लाइंट्स के लिए सामान्य अंतिम-प्रतिक्रिया फॉलबैक के साथ कैश उपयोग, डुप्लिकेट डाउनलोड, LCP, त्रुटियों और बैंडविड्थ को मापें।
चरण-दर-चरण गहन विश्लेषण
- ऑप्टिमाइजेशन विंडो खोजें। अनुरोध प्राप्त करने और अंतिम HTML तैयार होने के बीच की प्रतीक्षा को मापें। यदि ओरिजिन तेजी से 200 लौटाता है, तो 103 के पास कोई उपयोगी अंतराल नहीं है; अंतिम प्रतिक्रिया में सामान्य प्रीलोड बनाए रखें।
- 103 सिमेंटिक्स को परिभाषित करें। 103 यह बताता है कि अंतिम प्रतिक्रिया में इन फ़ील्ड्स के शामिल होने की संभावना है। एक क्लाइंट संभावित रूप से तैयारी कर सकता है, लेकिन यह संकेत अंतिम प्रतिक्रिया के सिमेंटिक्स को बदल या प्रतिस्थापित नहीं कर सकता है।
- संकेत सामग्री चुनें। स्थिर, महत्वपूर्ण, कैशेबल CSS, स्क्रिप्ट्स या कनेक्शन ओरिजिन को प्राथमिकता दें। संसाधन वर्ज़न, मीडिया प्रकार और क्रॉस-ओरिजिन क्रेडेंशियल्स को अंतिम प्रतिक्रिया से मेल खाना चाहिए; अनिश्चित वैयक्तिकृत संपत्तियों का संकेत न दें।
- प्रोटोकॉल और क्लाइंट्स को सीमित करें। HTTP/2 या HTTP/3 को प्राथमिकता दें और सत्यापित करें कि प्रॉक्सी, ब्राउज़र और ऑब्जर्वेबिलिटी पाथ्स 1xx को सही ढंग से संभालते हैं। पुराने HTTP/1.1 क्लाइंट्स के लिए इसे अक्षम या डाउनग्रेड करें जो 103 को अंतिम मान सकते हैं।
- अंतिम प्रतिक्रिया को संभालें। अंतिम 200/3xx/4xx पृष्ठ परिणाम तय करता है। यदि कोई 103 संकेत गलत हो जाता है, तो क्लाइंट अंतिम प्रतिक्रिया का पालन करता है; किसी मध्यस्थ को संकेत को अंतिम ऑब्जेक्ट के रूप में कैश नहीं करना चाहिए।
- मूल्य और लागत को मापें। पहले और बाद के फर्स्ट-व्यू LCP, संसाधन हिट्स, डुप्लिकेट डाउनलोड, बैंडविड्थ और त्रुटियों की तुलना करें। यदि रीडायरेक्ट, अक्षम कैशिंग, या संसाधन वेरिएंट प्रीलोड को बर्बाद करते हैं, तो पृष्ठ सेट को सीमित करें या 103 को हटा दें।
मॉडल उत्तर
मैं 103 को हर जगह केवल इसलिए सक्षम नहीं करूंगा क्योंकि यह तेज़ लगता है। मैं सबसे पहले सार्थक डायनामिक HTML जेनरेशन समय और एक टॉप-लेवल नेविगेशन की पुष्टि करूंगा। यदि CSS और महत्वपूर्ण स्क्रिप्ट URLs, वर्ज़न, as और कैश व्यवहार स्थिर हैं, तो मैं HTTP/2 या HTTP/3 पर संकेत भेजूंगा:
HTTP/2 103 Early Hints
Link: </style.abc.css>; rel=preload; as=style
Link: </app.abc.js>; rel=preload; as=script
HTTP/2 200 OK
Content-Type: text/html; charset=utf-8
Link: </style.abc.css>; rel=preload; as=styleअंतिम प्रतिक्रिया आधिकारिक बनी रहती है; 103 यह वादा नहीं करता कि किसी संसाधन का उपयोग किया ही जाएगा। पुराने क्लाइंट्स, अविश्वसनीय प्रॉक्सी, या ऐसे पृष्ठों के लिए जहाँ रीडायरेक्ट और वैयक्तिकरण संसाधनों को बदल देते हैं, मैं अंतिम प्रतिक्रिया में सामान्य Link हेडर्स पर वापस आ जाता हूँ। मैं सर्वर प्रतीक्षा, LCP, कैश हिट्स, डुप्लिकेट डाउनलोड, बैंडविड्थ और 4xx/5xx को मापने वाला एक प्रयोग चलाऊंगा। यदि संकेत वास्तविक अंतराल को कवर नहीं करते हैं, तो मैं 103 को हटा देता हूँ।
सामान्य गलतियाँ
- 103 को अंतिम स्थिति मानना → क्लाइंट सोच सकता है कि पृष्ठ सफल रहा → समझाएं कि अंतिम प्रतिक्रिया परिणाम तय करती है।
- हर HTML संसाधन को 103 में कॉपी करना → वैयक्तिकृत या गैर-कैशेबल संपत्तियां दो बार डाउनलोड होती हैं → केवल स्थिर महत्वपूर्ण संसाधनों का ही संकेत दें।
- प्रोटोकॉल और प्रॉक्सी संगतता को अनदेखा करना → पुराने क्लाइंट 1xx को गलत तरीके से पार्स कर सकते हैं → HTTP/2/3 को प्राथमिकता दें और फॉलबैक प्रदान करें।
- केवल LCP मापना → व्यर्थ प्रीलोड बैंडविड्थ स्थानीय लाभ को छिपा सकती है → डुप्लिकेट अनुरोधों, कैश और त्रुटियों की भी निगरानी करें।
- आधिकारिक अंतिम हेडर्स को छोड़ना → संकेत अंतिम मेटाडेटा नहीं हैं → अंतिम प्रतिक्रिया में आवश्यक
Linkफ़ील्ड्स को दोहराएं।
फॉलो-अप प्रश्न
103, HTTP/2 Server Push से किस प्रकार भिन्न है?
103 क्लाइंट को यह तय करने देता है कि फ़ेच करना है या नहीं; Server Push सक्रिय रूप से संसाधन भेजता है और क्लाइंट द्वारा पहले से कैश की गई संपत्तियों को भी पुश कर सकता है। जब कैश स्थिति अनिश्चित होती है, तो 103 अनावश्यक ट्रांसफर से बचना आसान बनाता है।
क्या होगा यदि अंतिम प्रतिक्रिया क्रॉस-ओरिजिन रीडायरेक्ट करती है?
शुरुआत में शुरू किए गए कनेक्शन या संसाधन खारिज किए जा सकते हैं, जिससे संकेत अतिरिक्त बैंडविड्थ और कनेक्शन लागत में बदल जाता है। इसे केवल स्थिर प्रवेश बिंदुओं (entry points) के लिए सक्षम करें और प्रयोग में रीडायरेक्ट दर को शामिल करें।
आप डायनामिक एसेट वर्ज़न्स को कैसे संभालते हैं?
एक ज्ञात कंटेंट-हैश वाले URL का उपयोग करें, या केवल ऐसे वर्ज़न का संकेत दें जिसका अंतिम प्रतिक्रिया से मेल खाना निश्चित हो। यदि वर्ज़न अज्ञात है, तो अनुमान लगाने के बजाय अंतिम HTML की प्रतीक्षा करें।
हर पृष्ठ पर 103 क्यों नहीं भेजते?
सर्वर थिंक टाइम के बिना समानांतर करने के लिए कोई कार्य नहीं होता है, और गहरे नेविगेशन में महत्वपूर्ण संपत्तियां पहले से ही कैश हो सकती हैं। एंट्री पेज, प्रोटोकॉल, कैश व्यवहार और मापे गए मूल्य के आधार पर रोल आउट करें।