Service Worker navigation preload पहली नेविगेशन पर स्टार्टअप देरी से कैसे बचाता है?

प्रॉम्प्ट और संदर्भ

आपकी साइट ऑफ़लाइन फ़ॉलबैक और शेयर्ड कैशिंग के लिए Service Worker के साथ नेविगेशन रिक्वेस्ट को इंटरसेप्ट करती है। नेटवर्क रिक्वेस्ट शुरू होने से पहले पहली नेविगेशन वर्कर के शुरू होने का इंतज़ार करती है। बिना सपोर्ट वाले ब्राउज़रों के लिए navigation preload डिज़ाइन करें और साथ ही डुप्लिकेट रिक्वेस्ट, पुराने कैश राइट्स और रिस्पॉन्स रेस को रोकें।

इंटरव्यूअर क्या टेस्ट कर रहा है

Navigation preload ब्राउज़र द्वारा शुरू की गई एक नेविगेशन रिक्वेस्ट है जो Service Worker के शुरू होने के दौरान चलती है; यह मनमाने रिसोर्सेज के लिए न तो प्रीकैशिंग है और न ही link rel=preload है। इसे activate के दौरान सक्षम करना, fetch में preloadResponse को पढ़ना, नेटवर्क-बनाम-कैश पॉलिसी, Service-Worker-Navigation-Preload हेडर, टाइमआउट और एरर फ़ॉलबैक, और मेजरमेंट को कवर करें।

पहले पूछने योग्य स्पष्टीकरण प्रश्न

पेज और कैश टार्गेट

स्पष्ट करें कि क्या नेविगेशन SSR HTML, SPA शेल, या ऑफ़लाइन पेज लौटाता है; कौन से पाथ कैशेबल हैं; और क्या यूज़र-विशिष्ट डेटा को शेयर्ड कैश को बायपास करना चाहिए। पर्सनलाइज़्ड रिस्पॉन्स को सार्वजनिक कैश में नहीं लिखा जाना चाहिए।

लाइफसाइकिल और ब्राउज़र सपोर्ट

navigationPreload के लिए रजिस्ट्रेशन, अपडेट, कंट्रोल स्कोप और टार्गेट ब्राउज़र सपोर्ट की पुष्टि करें। एक अनकंट्रोल्ड पहली नेविगेशन के बारे में यह नहीं माना जा सकता कि वह वर्तमान वर्कर से होकर गुज़रेगी।

नेटवर्क और कंसिस्टेंसी पॉलिसी

Network-first, cache-first, या stale-while-revalidate व्यवहार चुनें और ऑफ़लाइन रिस्पॉन्स को परिभाषित करें। तय करें कि सर्वर गलती से कैश कीज़ को बदले बिना प्रीलोड हेडर को कैसे पढ़ता है।

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

“Service Worker के activate इवेंट में फ़ीचर डिटेक्ट करें और navigation preload को सक्षम करें। वर्कर के शुरू होने के दौरान ब्राउज़र नेविगेशन रिक्वेस्ट शुरू करता है; फ़ेच हैंडलर पहले event.preloadResponse का इंतज़ार करता है, फिर कैश की जांच करता है या केवल तभी fetch को कॉल करता है जब कोई उपयोगी प्रीलोड रिस्पॉन्स मौजूद न हो। रिस्पॉन्स को केवल तभी स्वीकार करें जब URL, आइडेंटिटी और कैश पॉलिसी मेल खाते हों। रोलआउट से पहले और बाद में सपोर्ट, स्टार्टअप टाइम, TTFB, कैश हिट्स, डुप्लिकेट रिक्वेस्ट और फ़ॉलबैक एरर्स की तुलना करें।”

चरण-दर-चरण विस्तृत उत्तर

चरण 1: activate के दौरान इसे सक्षम करें

registration.navigationPreload की जाँच करने के बाद, activate के waitUntil के अंदर enable() को कॉल करें ताकि नए वर्कर के तैयार माने जाने से पहले कॉन्फ़िगरेशन पूरा हो जाए। setHeaderValue() संदर्भ जोड़ सकता है, लेकिन मान में प्राइवेट या अनकैशेबल स्थिति नहीं होनी चाहिए।

चरण 2: fetch में preloadResponse का उपभोग करें

केवल नेविगेशन रिक्वेस्ट के लिए event.preloadResponse पढ़ें। यह Response या undefined में रिज़ॉल्व हो सकता है। एक मान्य प्रीलोड रिस्पॉन्स को प्राथमिकता दें; अन्यथा कैश या सामान्य fetch पॉलिसी का पालन करें। यह तय करने से पहले कि प्रीलोड प्रॉमिस ने कोई उपयोगी परिणाम दिया है या नहीं, दूसरी नेटवर्क रिक्वेस्ट शुरू न करें।

चरण 3: कैश और आइडेंटिटी बाउंड्रीज़ को परिभाषित करें

पहचान, भूगोल, या प्रयोग डेटा युक्त SSR HTML को मौजूदा कैश कीज़ और रिस्पॉन्स हेडर्स का सम्मान करना चाहिए। इसे बिना शर्त Cache Storage में न डालें। एक स्टैटिक शेल cache-first हो सकता है; एक पर्सनलाइज़्ड पेज network-first हो सकता है, जिसमें Cookie, Authorization, और Vary व्यवहार का स्पष्ट रूप से परीक्षण किया गया हो।

चरण 4: हेडर और सर्वर रूटिंग को हैंडल करें

सर्वर पैरेलल रिक्वेस्ट को पहचानने और महंगे काम को छोड़ने या एक डेडिकेटेड कैश का उपयोग करने के लिए Service-Worker-Navigation-Preload का निरीक्षण कर सकता है। प्रॉक्सी और CDNs को उस हेडर को फ़ॉरवर्ड करने, अनदेखा करने, या vary करने के लिए एक स्पष्ट नियम की आवश्यकता होती है ताकि यह क्रॉस-यूज़र कैश शेयरिंग न बना सके।

चरण 5: रेस, टाइमआउट और एरर्स को संभालें

यदि प्रीलोड विफल हो जाता है, टाइमआउट हो जाता है, या अनुपयुक्त स्थिति लौटाता है, तो पॉलिसी के अनुसार कैश या सामान्य fetch पर फ़ॉलबैक करें। एक Response बॉडी आम तौर पर सिंगल-यूज़ होती है; जब दो उपभोक्ताओं की आवश्यकता हो तो clone() का उपयोग करें, और कैंसिलेशन और टाइमआउट को बाउंड करें। नेटवर्क एरर के बाद ऑफ़लाइन पेज का प्रयास करें, लेकिन वास्तविक सर्वर एरर को न छिपाएं।

चरण 6: सुरक्षित रूप से डिग्रेड और अपडेट करें

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

चरण 7: वास्तविक प्रदर्शन और शुद्धता को मापें

कोल्ड और वार्म स्टार्ट, धीमे नेटवर्क, ऑफ़लाइन मोड, अनकंट्रोल्ड पहली विज़िट्स और वर्कर अपडेट की तुलना करें। नेविगेशन-टू-रिस्पॉन्स, TTFB, वर्कर स्टार्टअप, प्रीलोड हिट्स, कैश हिट्स, डुप्लिकेट रिक्वेस्ट और फ़ॉलबैक एरर्स को रिकॉर्ड करें। केवल औसत लोड समय ही नहीं, बल्कि पहचान अलगाव और ब्राउज़र व्यवहार को भी सत्यापित करें।

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

मैं activate में फ़ीचर डिटेक्ट करूँगा और navigation preload को सक्षम करूँगा, फिर नेविगेशन फ़ेच हैंडलर में पहले preloadResponse का इंतज़ार करूँगा। केवल तभी जब यह अनुपस्थित या अनुपयुक्त हो, हैंडलर कैश या सामान्य fetch का उपयोग करेगा। कैश पॉलिसी को स्टैटिक शेल्स को पर्सनलाइज़्ड SSR HTML से अलग करना चाहिए, और सर्वर कैश आइसोलेशन को बदले बिना प्रीलोड हेडर का उपयोग कर सकता है। असमर्थित ब्राउज़र सामान्य fetch व्यवहार को बनाए रखते हैं। मैं TTFB और स्टार्टअप समय की तुलना करते हुए कोल्ड स्टार्ट, धीमे नेटवर्क, ऑफ़लाइन मोड, अनकंट्रोल्ड विज़िट्स, अपडेट और डुप्लिकेट-रिक्वेस्ट काउंट्स का परीक्षण करूँगा।

सामान्य गलतियाँ

• गलती: Navigation preload को स्टैटिक-रिसोर्स प्रीकैशिंग मानना। → यह क्यों विफल होता है: यह नेविगेशन को लक्षित करता है और वर्कर स्टार्टअप के साथ चलता है। → सुधार: फ़ेच हैंडलर में preloadResponse का उपभोग करें।
• गलती: प्रीलोड का कोई तत्काल परिणाम न होने पर बिना शर्त fetch शुरू करना। → यह क्यों विफल होता है: यह रिक्वेस्ट और साइड इफेक्ट्स को डुप्लिकेट कर सकता है। → सुधार: प्रॉमिस, कैश और fetch क्रम को परिभाषित करें।
• गलती: पर्सनलाइज़्ड HTML को शेयर्ड Cache Storage में लिखना। → यह क्यों विफल होता है: Cookie, Authorization, या Vary सीमाएं अनदेखी हो जाती हैं। → सुधार: आइडेंटिटी-अवेयर network-first पॉलिसी का उपयोग करें।
• गलती: केवल औसत लोड समय की तुलना करना। → यह क्यों विफल होता है: कोल्ड स्टार्ट, अनकंट्रोल्ड विज़िट्स, और डुप्लिकेट रिक्वेस्ट औसत में गायब हो जाती हैं। → सुधार: कोहॉर्ट द्वारा TTFB, स्टार्टअप, हिट्स और एरर्स को ट्रैक करें।

फॉलो-अप प्रश्न और उत्तर

फॉलो-अप 1: सीधे link preload का उपयोग क्यों न करें?

link rel=preload पेज-घोषित और रिसोर्स-उन्मुख है। Navigation preload नेविगेशन के लिए एक ब्राउज़र रिक्वेस्ट है जो Service Worker स्टार्टअप के दौरान चलती है; इसका लाइफ़साइकिल और कंसम्पशन API अलग है।

फॉलो-अप 2: preloadResponse undefined क्यों हो सकता है?

ब्राउज़र इसका समर्थन नहीं कर सकता है, रिक्वेस्ट एक नेविगेशन नहीं हो सकती है, प्रीलोड अक्षम हो सकता है, या नेटवर्क रिक्वेस्ट वर्कर इवेंट से पहले विफल हो सकती है। undefined को एक सामान्य ब्रांच के रूप में ट्रीट करें।

फॉलो-अप 3: Response बॉडी को दो बार पढ़ने से कैसे बचें?

एक Response बॉडी आमतौर पर सिंगल-यूज़ होती है। जब पेज और कैश दोनों को इसकी आवश्यकता हो तो clone() को कॉल करें, और दोनों उपभोक्ताओं में एरर्स और कैंसिलेशन को संभालें।

फॉलो-अप 4: पहली विज़िट में अभी भी कोई गति क्यों नहीं दिख सकती है?

एक अनकंट्रोल्ड पेज वर्तमान वर्कर के माध्यम से नेविगेशन को रूट नहीं करता है, और रजिस्ट्रेशन, इंस्टॉलेशन और एक्टिवेशन में समय लगता है। अनकंट्रोल्ड पहली विज़िट्स को प्रीलोड विफलता के रूप में लेबल करने के बजाय अलग से मापें।