प्रॉम्प्ट और संदर्भ
ओरिजिन अंतिम रिस्पॉन्स से पहले Link के साथ 103 उत्सर्जित कर सकता है, लेकिन प्रोडक्शन ट्रैफ़िक अभी भी TLS टर्मिनेटर, लोड बैलेंसर, रिवर्स प्रॉक्सी और CDN से होकर गुजरता है। एक एंड-टू-एंड कम्पैटिबिलिटी मैट्रिक्स, कैनरी स्विच, पारदर्शी फ़ॉलबैक और ऑब्जर्वेबिलिटी योजना डिज़ाइन करें जो यह साबित करे कि 1xx रिस्पॉन्स समर्थित ब्राउज़र तक पहुँचता है।
इंटरव्यूअर क्या जांचता है
मजबूत उत्तर अंतरिम (interim) और अंतिम रिस्पॉन्स के बीच अंतर करते हैं, उच्च-विश्वसनीयता वाले संसाधनों का चयन करते हैं, HTTP/2, HTTP/3, प्रॉक्सी और CDN पर चर्चा करते हैं, और 103 को अनदेखा किए जाने पर पारदर्शी फ़ॉलबैक प्रदान करते हैं। वे गलत संकेतों (hints), कैश और क्रॉस-ओरिजिन जोखिमों तथा वास्तविक उपयोगकर्ता लाभ के मापन को भी कवर करते हैं।
स्पष्ट करने योग्य प्रश्न
- सर्वर संसाधन सेट को कितनी जल्दी और कितने विश्वास के साथ जान सकता है?
- क्या क्लाइंट, TLS टर्मिनेटर, रिवर्स प्रॉक्सी और CDN 1xx रिस्पॉन्स को बनाए रखते हैं?
- क्या संसाधन वर्ज़न किए गए हैं, और क्या क्रॉस-ओरिजिन
preconnectआवश्यक है? - क्या लक्ष्य LCP है, TTFB के बाद का अंतर है, या CSS और फ़ॉन्ट की पहले खोज करना है?
- त्रुटियों, कैश हिट्स और बिना 103 वाले क्लाइंट्स को कैसे देखा और प्रबंधित किया जाता है?
30-सेकंड का उत्तर
अंतिम रिस्पॉन्स से पहले, मैं उच्च-विश्वसनीयता वाले Link संकेतों के एक छोटे सेट के साथ 103 भेजूँगा, फिर सामान्य अंतिम रिस्पॉन्स भेजूँगा। संसाधन वर्ज़न किए गए URL का उपयोग करते हैं और क्रॉस-ओरिजिन कनेक्शन केवल विश्वसनीय डोमेन तक सीमित होते हैं। 103 को अनदेखा करने पर भी पेज सही रहना चाहिए क्योंकि अंतिम HTML अभी भी संसाधनों को संदर्भित करता है। कवरेज का विस्तार करने से पहले मैं LCP, डिस्कवरी समय, डुप्लिकेट बाइट्स और त्रुटियों के लिए ट्रेस और RUM का उपयोग करके समर्थित और असमर्थित पाथ की तुलना करूँगा।
चरण-दर-चरण विस्तृत उत्तर
चरण 1: समय (timing) को समझें
103 एक सूचनात्मक अंतरिम रिस्पॉन्स है और इसके बाद एक अंतिम रिस्पॉन्स होना चाहिए। जब सर्वर काम कर रहा हो, तो यह Link: </app.css>; rel=preload; as=style जैसे संकेत ले जा सकता है। कोई क्लाइंट उन पर कार्य करता है या नहीं, यह प्रोटोकॉल स्टैक, ब्राउज़र और नीति पर निर्भर करता है; व्यावसायिक शुद्धता उन पर निर्भर नहीं होनी चाहिए।
चरण 2: संसाधन चुनें
केवल उन्हीं संसाधनों का संकेत दें जो लगभग निश्चित, उचित आकार के और स्थिर हों: क्रिटिकल CSS, फ़ॉन्ट या एक preconnect। कम संभावना वाली छवियों, व्यक्तिगत स्क्रिप्ट और अनुमति-निर्भर संपत्तियों से बचें जो बैंडविड्थ बर्बाद करती हैं या गलत चीज़ को प्रीफ़ेच करती हैं।
HTTP/1.1 103 Early Hints
Link: </app.css>; rel=preload; as=style
Link: <https://cdn.example.com>; rel=preconnect
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8चरण 3: मध्यस्थों और फ़ॉलबैक को सत्यापित करें
103 को अग्रेषित (forward) करने या उपभोग करने के लिए वास्तविक लोड बैलेंसर, TLS टर्मिनेशन, CDN और ब्राउज़र पाथ का परीक्षण करें। जो क्लाइंट इसे अनदेखा करता है, उसे अभी भी अंतिम रिस्पॉन्स में सामान्य संदर्भ प्राप्त होने चाहिए; किसी पेज को कभी भी किसी अंतरिम संदेश पर निर्भर न बनाएं।
चरण 4: कैश और सुरक्षा प्रभावों को सीमित करें
संकेत वर्तमान अनुरोध संदर्भ से मेल खाने चाहिए। सामग्री-हैश किए गए (content-hashed) URL और सही Cache-Control का उपयोग करें; उपयोगकर्ता इनपुट से कभी भी मनमाने Link मान न बनाएं। क्रॉस-ओरिजिन preconnect कनेक्शन के इरादे को उजागर करता है और संसाधनों की खपत करता है, इसलिए केवल विश्वसनीय मूल और आवश्यक मापदंडों की अनुमति दें।
चरण 5: गलत प्रीलोड से बचें
यदि प्रमाणीकरण, प्रयोग या भूगोल संसाधन सेट को बदलते हैं, तो उच्च विश्वसनीयता की प्रतीक्षा करें या संकेत को छोड़ दें। यदि अंतिम रिस्पॉन्स अब किसी संकेतित संसाधन को संदर्भित नहीं करता है, तो हो सकता है कि ब्राउज़र ने डाउनलोड बर्बाद कर दिया हो; उस लागत को मापें।
चरण 6: निरीक्षण करें और रोलबैक करें
लॉग करें कि क्या 103 भेजा गया था, अंतिम स्थिति, डिस्कवरी समय, कैश हिट, डुप्लिकेट बाइट्स और प्रॉक्सी द्वारा अंतर। फीचर फ्लैग के साथ रूट या ट्रैफ़िक द्वारा रोलआउट को गेट करें। यदि बैंडविड्थ, त्रुटियां या उपयोगकर्ता मेट्रिक्स खराब होते हैं तो संकेतों को अक्षम करें; अंतिम HTML अपरिवर्तित रहता है।
ट्रेड-ऑफ़ और सीमाएं
103 बनाम प्रीलोड लिंक
103 एक संकेत को पहले ले जाता है, जबकि सामान्य HTML link अंतिम आधिकारिक संदर्भ बना रहता है। डुप्लिकेट डाउनलोड या प्राथमिकता संघर्षों से बचने के लिए उन्हें सहमत होना चाहिए। संकेत CSP, अखंडता (integrity) या अनुमति नीति की जगह नहीं लेते हैं।
प्रोटोकॉल वर्ज़न और मध्यस्थ
RFC 8297 सिमेंटिक्स को परिभाषित करता है, लेकिन एक प्रॉक्सी श्रृंखला 1xx रिस्पॉन्स को छोड़ सकती है। वास्तविक HTTP/2, HTTP/3, CDN और क्लाइंट संयोजनों को मापें और बिना 103 वाला बेसलाइन बनाए रखें।
रोलआउट योजना और प्रमाण
चरणबद्ध रिलीज
एक रूट पर स्थिर CSS से शुरू करें, अंतिम रिस्पॉन्स और संदर्भों को सत्यापित करें, फिर फ़ॉन्ट या सुरक्षित preconnects तक विस्तार करें। एक किल स्विच रखें और पहली बार आने वाले विज़िट, कैश्ड विज़िट और धीमे नेटवर्क की अलग-अलग तुलना करें।
मेट्रिक्स और स्वीकृति
LCP, संसाधन खोज समय, डुप्लिकेट बाइट्स, कैश हिट दर, 4xx/5xx और बैंडविड्थ को ट्रैक करें। ब्राउज़र टूल, एज लॉग और RUM का मिलान करें; केवल सर्वर सेंड लॉग ही क्लाइंट के व्यवहार को साबित नहीं कर सकते।
सामान्य गलतियाँ और फॉलो-अप
गलती: 103 को अंतिम सफलता मानना
व्यावसायिक स्थिति, कैशिंग और त्रुटियां अंतिम रिस्पॉन्स का उपयोग करती हैं; 103 के खो जाने से अनुरोध विफल नहीं होना चाहिए।
गलती: प्रत्येक संसाधन का संकेत देना
कम-विश्वसनीयता वाली संपत्तियां बैंडविड्थ और कनेक्शन बर्बाद करती हैं। एक छोटे स्थिर क्रिटिकल सेट को प्राथमिकता दें।
गलती: केवल सीधे स्थानीय पाथ का परीक्षण करना
प्रोडक्शन CDN, प्रॉक्सी और TLS टर्मिनेशन 1xx व्यवहार को बदल सकते हैं; एंड-टू-एंड परीक्षण करें।
फॉलो-अप: क्या होगा यदि 103 असमर्थित है?
सामान्य अंतिम-HTML संदर्भों और मौजूदा कैशिंग पर भरोसा करें। शुद्धता बनी रहती है; केवल संभावित प्रदर्शन लाभ खो जाता है।
फॉलो-अप: आप कैसे साबित करते हैं कि इसे बनाए रखना सार्थक है?
कैश और नेटवर्क स्थितियों द्वारा खंडित LCP, डिस्कवरी, डुप्लिकेट बाइट्स, त्रुटियों और बैंडविड्थ के लिए एक स्प्लिट प्रयोग चलाएं।