प्रॉम्प्ट और संदर्भ
आप एक ई-कॉमर्स होमपेज के मालिक हैं जिसका above-the-fold HTML जेनरेट होने में समय लेता है। प्रस्ताव यह है कि अंतिम रिस्पॉन्स से पहले 103 Early Hints भेजा जाए ताकि ब्राउज़र क्रिटिकल CSS, फॉन्ट या स्क्रिप्ट शुरू कर सके। बताएं कि यह कब मदद करता है, डुप्लिकेट डाउनलोड से कैसे बचें, और LCP में बदलाव को कैसे सत्यापित करें। यह मानकर चलें कि यह HTTP/2 या HTTP/3 पर एक टॉप-लेवल नेविगेशन है, और अंतिम रिस्पॉन्स पर भी सही Link हेडर भेजे जा रहे हैं।
इंटरव्यूअर क्या जांच रहा है
- क्या आप 103 को एक आधिकारिक रिसोर्स सूची के बजाय एक संकेत (hint) के रूप में वर्णित करते हैं: ब्राउज़र कनेक्ट या प्रीलोड कर सकता है, जबकि अंतिम रिस्पॉन्स आधिकारिक बना रहता है।
- क्या आप सर्वर थिंक-टाइम को ओवरलैप विंडो के रूप में पहचानते हैं; जब सर्वर तुरंत 200 लौटा सकता है, तो मुख्य रिस्पॉन्स पर नियमित
preloadयाpreconnectअधिक सरल होता है। - क्या आप रिसोर्स स्थिरता, कैशिंग, क्रॉस-ओरिजिन रीडायरेक्ट, ब्राउज़र सपोर्ट और प्रोटोकॉल आवश्यकताओं को कवर करते हैं।
- क्या आप केवल स्टेटस कोड दोहराने के बजाय LCP, कैश पुन: उपयोग, डुप्लिकेट अनुरोधों और त्रुटियों के साथ सत्यापन करते हैं।
उत्तर देने से पहले स्पष्टीकरण हेतु प्रश्न
- पहले बाइट से पहले सर्वर का समय कितना है? यदि यह शून्य के करीब है, तो हासिल करने के लिए बहुत कम ओवरलैप है; पहले बैकएंड या मुख्य-रिस्पॉन्स संकेतों को ऑप्टिमाइज़ करें।
- क्या संकेत दिए गए रिसोर्स स्थिर और आवश्यक हैं? उपयोगकर्ता, प्रयोग या अनुमति पर निर्भर रिसोर्स जल्दी अनुमान लगाने पर बर्बाद हो सकते हैं।
- क्या यह HTTP/2+ पर एक टॉप-लेवल नेविगेशन है? ब्राउज़र हैंडलिंग नेविगेशन पर केंद्रित है, और MDN HTTP/2 या बाद के संस्करण की सिफारिश करता है।
- क्या रिसोर्स कैश करने योग्य (cacheable) हैं? एक गैर-कैश करने योग्य प्रीलोड HTML आने के बाद फिर से डाउनलोड किया जा सकता है, जिससे संकेत अतिरिक्त काम में बदल जाता है।
30-सेकंड उत्तर फ्रेमवर्क
“मैं पहले यह सत्यापित करता हूं कि पेज में सार्थक सर्वर थिंक-टाइम है और यह एक ऐसा नेविगेशन है जहां क्लाइंट 103 का समर्थन करता है। फिर मैं केवल स्थिर, कैश करने योग्य CSS, फॉन्ट या कनेक्शन ओरिजिन का संकेत देता हूं, और अंतिम रिस्पॉन्स में सही Link हेडर दोहराता हूं। मैं प्रयोग या अनुमति पर निर्भर रिसोर्स के संकेतों से बचता हूं। लॉन्च से पहले और बाद में, मैं TTFB और रिसोर्स अनुरोधों, LCP, डुप्लिकेट बाइट्स और त्रुटियों के बीच ओवरलैप की तुलना करता हूं; जो क्लाइंट 103 का समर्थन नहीं करते हैं वे सामान्य रिस्पॉन्स पथ का उपयोग करते हैं।”
चरण-दर-चरण गहन उत्तर
1. ओवरलैप विंडो को मापें
103 ब्राउज़र को कनेक्ट करने या फेच करने की अनुमति देता है जबकि सर्वर अंतिम HTML तैयार करता है। उपयोगी ऊपरी सीमा लगभग सर्वर तैयारी समय में से वह समय घटाकर होती है जब ब्राउज़र अंतिम रिस्पॉन्स के बाद रिसोर्स की खोज करता। यदि सर्वर जल्दी से 200 लौटाता है, तो विंडो लगभग शून्य होती है; Chrome उस स्थिति में नियमित Link या HTML link की सिफारिश करता है।
2. प्रत्येक HTML संकेत को कॉपी करने के बजाय स्थिर रिसोर्स चुनें
Early Hints अंतिम HTML और उसके उपयोगकर्ता-विशिष्ट वेरिएंट के ज्ञात होने से पहले आते हैं। अच्छे उम्मीदवारों में साझा CSS, सामान्य स्क्रिप्ट, फॉन्ट और क्रिटिकल CDN कनेक्शन शामिल हैं। वैयक्तिकृत छवियों, प्रयोग शाखाओं और अनुमति-प्राप्त रिसोर्स को HTML की प्रतीक्षा करनी चाहिए। जब व्यावहारिक हो तो रिसोर्स को संकेत के लिए एक स्थिर भाग और अंतिम रिस्पॉन्स के लिए एक डायनामिक भाग में विभाजित करें।
3. कैश और प्रोटोकॉल को शुद्धता की शर्तों के रूप में समझें
अंतिम पेज को प्रीलोड किए गए रिसोर्स का पुन: उपयोग करना चाहिए। यदि यह कैश करने योग्य नहीं है, तो ब्राउज़र इसे संकेत से एक बार और HTML पार्स करने के बाद फिर से डाउनलोड कर सकता है। क्रॉस-ओरिजिन फॉन्ट को भी मैचिंग crossorigin सेमेंटिक्स की आवश्यकता होती है। MDN HTTP/2 या बाद के संस्करण पर 103 भेजने की सिफारिश करता है क्योंकि पुराने क्लाइंट और मध्यवर्ती 1xx रिस्पॉन्स को गलत तरीके से संभाल सकते हैं।
4. अंतिम रिस्पॉन्स को आधिकारिक रखें
उन क्लाइंट्स के लिए जो 103 को अनदेखा करते हैं और HTML रेंडर करते समय सीखे गए रिसोर्स के लिए अंतिम रिस्पॉन्स में Link हेडर भेजना जारी रखें। एक क्रॉस-ओरिजिन रीडायरेक्ट ब्राउज़र को शुरुआती कनेक्शन और रिसोर्स को छोड़ने का कारण बन सकता है, इसलिए 103 एक अपरिवर्तनीय डाउनलोड आदेश नहीं है।
5. एक वास्तविक प्रयोग को मापें
Early Hints के साथ और उसके बिना वास्तविक नेविगेशन को रैंडमाइज़ करें। सर्वर थिंक-टाइम, रिसोर्स अनुरोध शुरू होने का समय, LCP, डुप्लिकेट बाइट्स और त्रुटि दर रिकॉर्ड करें। Chrome DevTools Early Hints सर्जक और कैश पुन: उपयोग को प्रदर्शित करता है, लेकिन परीक्षण के दौरान कैश सक्षम रहना चाहिए। यदि LCP में सुधार नहीं होता है, तो जांचें कि क्या रिसोर्स पहले से ही कैश्ड था, संकेत बहुत देर से आया, किसी रीडायरेक्ट ने इसे छोड़ दिया, या सर्वर का समय अड़चन (bottleneck) नहीं है।
6. इसकी HTTP/2 Push से तुलना करें
103 एक सुराग प्रदान करता है और फेचिंग का नियंत्रण ब्राउज़र पर छोड़ देता है; HTTP/2 Push सक्रिय रूप से रिसोर्स भेजता था और अक्सर ब्राउज़र द्वारा पहले से कैश्ड वस्तुओं की नकल करता था। ट्रेडऑफ़ यह है कि Early Hints को अभी भी एक राउंड ट्रिप की आवश्यकता होती है और यह ब्राउज़र समर्थन पर निर्भर करता है, लेकिन यह क्लाइंट से नियंत्रण छीनने से बचता है।
उच्च-गुणवत्ता वाला नमूना उत्तर
मैं पहले बाइट से पहले के समय से शुरुआत करूंगा। यदि SSR में 300 मिलीसेकंड लगते हैं और मुख्य CSS और फॉन्ट प्रत्येक नेविगेशन पर स्थिर हैं, तो 103 उनके कनेक्शन और डाउनलोड को उन 300 मिलीसेकंड के साथ ओवरलैप कर सकता है। मैं केवल कैश करने योग्य स्थिर रिसोर्स का संकेत दूंगा, क्रॉस-ओरिजिन फॉन्ट के लिए सही crossorigin शामिल करूंगा, और वैयक्तिकृत छवियों और प्रयोग स्क्रिप्ट को अंतिम रिस्पॉन्स के लिए छोड़ दूंगा। अंतिम रिस्पॉन्स में अभी भी Link शामिल होगा ताकि असमर्थित क्लाइंट्स के पास एक सामान्य फॉलबैक हो।
मैं यह दावा नहीं करूंगा कि स्टेटस कोड जोड़ने से जीत की गारंटी मिलती है। मैं एक नियंत्रित नेविगेशन प्रयोग चलाऊंगा और LCP, अनुरोध प्रारंभ समय, डुप्लिकेट बाइट्स और क्रॉस-ओरिजिन रीडायरेक्ट दर की तुलना करूंगा। यदि सर्वर पहले से ही जल्दी से 200 लौटाता है, रिसोर्स कैश में है, या अंतिम पेज अक्सर संकेत को अस्वीकार करता है, तो एक नियमित मुख्य-रिस्पॉन्स संकेत—या कोई प्रीलोड नहीं—अधिक सुरक्षित है। यह उत्तर लाभ विंडो, गलत अनुमानों की लागत और फॉलबैक को उजागर करता है।
सामान्य गलतियाँ
- गलती → 103 को 200 के समकक्ष मानना। यह क्यों विफल होता है: 103 केवल सूचनात्मक (informational) है; अंतिम रिस्पॉन्स परिणाम और रिसोर्स को परिभाषित करता है। सुधार: कहें कि संकेत को अनदेखा किया जा सकता है और अंतिम
Linkहेडर बनाए रखें। - गलती → प्रत्येक HTML
preloadको 103 में कॉपी करना। यह क्यों विफल होता है: संकेत के समय उपयोगकर्ता वेरिएंट अज्ञात होते हैं, इसलिए डायनामिक रिसोर्स बैंडविड्थ बर्बाद करते हैं। सुधार: केवल स्थिर, उच्च-संभावना वाले रिसोर्स चुनें। - गलती → केवल LCP मापना। यह क्यों विफल होता है: एक गैर-कैश करने योग्य प्रीलोड या गलत cross-origin एट्रिब्यूट कुल बाइट्स बढ़ाते हुए पहले शुरू हो सकता है। सुधार: कैश पुन: उपयोग, डुप्लिकेट अनुरोध, बैंडविड्थ और त्रुटियों को भी मापें।
- गलती → इसे प्रत्येक HTTP/1.1 अनुरोध पर भेजना। यह क्यों विफल होता है: 1xx हैंडलिंग अलग-अलग होती है और Early Hints नेविगेशन को लक्षित करता है। सुधार: सामान्य-रिस्पॉन्स फॉलबैक के साथ, प्रोटोकॉल, अनुरोध प्रकार और क्लाइंट क्षमता के अनुसार गेट करें।
फॉलो-अप प्रश्न और प्रतिक्रियाएं
अंतिम रिस्पॉन्स अक्सर किसी अन्य ओरिजिन पर रीडायरेक्ट करता है। क्या आप तब भी 103 भेजेंगे?
केवल सावधानी के साथ। MDN और Chrome मार्गदर्शन नोट करते हैं कि एक क्रॉस-ओरिजिन रीडायरेक्ट ब्राउज़र को शुरुआती कनेक्शन और रिसोर्स को छोड़ने पर मजबूर कर सकता है। संकेतों को एक स्थिर अंतिम प्रवेश बिंदु या समान-ओरिजिन रिसोर्स तक सीमित करें जो रीडायरेक्ट से बचे रहते हैं, और एक रीडायरेक्ट-दर थ्रेशोल्ड सेट करें।
प्रयोग समूहों के बीच CSS भिन्न होता है। आप क्या संकेत दे सकते हैं?
केवल प्रत्येक समूह द्वारा साझा किए गए CSS का संकेत दें; प्रयोग-विशिष्ट चंक्स को अंतिम HTML पर छोड़ दें। यदि कोई स्थिर प्रतिच्छेदन (intersection) नहीं है, तो प्रीलोड न करें। गलत अनुमान की बैंडविड्थ लागत बचाए गए प्रतीक्षा समय से अधिक हो सकती है।
आप यह कैसे साबित करते हैं कि लाभ वार्म कैश के बजाय 103 से आया है?
समान कैश स्थितियों वाले समूहों को रैंडमाइज़ करें और कोल्ड और वार्म कैश की अलग-अलग रिपोर्ट करें। केवल एक LCP मान ही नहीं, बल्कि रिसोर्स अनुरोधों और सर्वर थिंक-टाइम के बीच ओवरलैप को मापें; Early Hints सर्जक, कैश हिट्स और डुप्लिकेट डाउनलोड का निरीक्षण करें।
क्या होगा यदि कोई ब्राउज़र किसी विशेष Early Hints निर्देश का समर्थन नहीं करता है?
अंतिम Link और HTML घोषणाओं को फॉलबैक के रूप में रखें। व्यापक रूप से समर्थित preconnect से शुरू करें, लक्ष्य-ब्राउज़र मैट्रिक्स के अनुसार preload रोल आउट करें, और त्रुटियों की निगरानी करें।