सर्विस वर्कर, वेबसाइटों को ऑफ़लाइन काम करने देने और अपने लिए कैश मेमोरी के खास नियम बनाने के लिए एक बेहतरीन टूल है. सर्विस वर्कर fetch
हैंडलर, कंट्रोल किए जाने वाले पेज के हर अनुरोध को देखता है. साथ ही, यह तय कर सकता है कि वह सर्विस वर्कर कैश मेमोरी से उसका रिस्पॉन्स सर्व करना चाहता है या नहीं. इसके अलावा, पूरी तरह से अलग रिस्पॉन्स फ़ेच करने के लिए यूआरएल को फिर से लिख सकता है, जैसे कि स्थानीय उपयोगकर्ता की सेटिंग के आधार पर.
हालांकि, जब कोई पेज पहली बार लोड होता है और कंट्रोल करने वाला सर्विस वर्कर फ़िलहाल नहीं चल रहा है, तो सर्विस वर्कर पर परफ़ॉर्मेंस की लागत लागू हो सकती है. सभी तरह के फ़ेच, सर्विस वर्कर के ज़रिए होने चाहिए. इसलिए, ब्राउज़र को सर्विस वर्कर के चालू होने और यह पता लगाने के लिए चलना होता है कि कौनसा कॉन्टेंट लोड होना चाहिए. सर्विस वर्कर का इस्तेमाल करने वाले डेवलपर के लिए, यह शुरुआती लागत छोटी हो सकती है, लेकिन यह कैशिंग रणनीतियों के ज़रिए परफ़ॉर्मेंस को बेहतर बनाने के लिए ज़्यादा होती है.
नेविगेशन प्रीलोड समस्या को हल करने का एक तरीका है—इसकी मदद से सर्विस वर्कर स्टार्टअप के साथ-साथ, नेटवर्क पर नेविगेशन के अनुरोध किए जा सकते हैं—हालांकि, यह शुरुआती नेविगेशन अनुरोधों तक सीमित होता है और इसमें सर्विस वर्कर को अहम पाथ में अब भी शामिल किया जाता है. नेविगेशन प्रीलोड लॉन्च होने के बाद से, समस्या को हल करने के लिए आम तौर पर समस्या हल करने की कई कोशिशें की गईं. इसमें सर्विस वर्कर स्टार्टअप पर कुछ अनुरोधों को ब्लॉक न किए जाने के तरीके भी शामिल हैं.
सर्विस वर्कर स्टैटिक रूटिंग एपीआई
Chrome 116 में, इस तरह के समाधान के पहले चरण की जांच करने के लिए, एक्सपेरिमेंटल सर्विस वर्कर स्टैटिक रूटिंग एपीआई उपलब्ध है. जब कोई सर्विस वर्कर इंस्टॉल किया जाता है, तब यह तय करने के लिए कि कुछ रिसॉर्स पाथ किस तरह फ़ेच किए जाने चाहिए, सेवा वर्कर स्टैटिक रूटिंग एपीआई का इस्तेमाल कर सकता है.
एपीआई के शुरुआती वर्शन में, पाथ को हमेशा नेटवर्क से सेवा देने के लिए तय किया जा सकता है, न कि सर्विस वर्कर से. जब कोई कंट्रोल यूआरएल बाद में लोड होता है, तो सर्विस वर्कर के शुरू होने से पहले ही ब्राउज़र उन पाथ से संसाधनों को फ़ेच करना शुरू कर सकता है. यह उन पाथ से सर्विस वर्कर को हटा देता है जिन्हें आपको सर्विस वर्कर की ज़रूरत नहीं है.
एपीआई का इस्तेमाल करने के लिए, सर्विस वर्कर install इवेंट पर event.registerRouter
को नियमों के सेट के साथ कॉल करता है:
self.addEventListener('install', event => {
if (event.registerRouter) {
// Go straight to the network and bypass invoking "fetch" handlers for all
// same-origin URLs that start with '/form/'.
event.registerRouter([{
condition: {
urlPattern: {pathname: '/form/*'},
},
source: 'network',
}]);
}
});
आम तौर पर, हर नियम में दो प्रॉपर्टी होती हैं:
condition: यह बताता है कि रिसॉर्स पाथ का मिलान करने के लिए, यूआरएल पैटर्न एपीआई का इस्तेमाल करके नियम कब लागू होता है. इस प्रॉपर्टी के लिए,URLPatternया इसके बराबर सामान्य ऑब्जेक्ट कोURLPatternकंस्ट्रक्टर में पास किया जा सकता है. उदाहरण के लिए,new URLPattern({pathname: '*.jpg'})या सिर्फ़{pathname: '*.jpg'}.यूआरएल पैटर्न के सुविधाजनक होने का मतलब है कि नियम किसी पाथ के तहत आने वाले किसी भी संसाधन की तरह आसान चीज़ों का मिलान बहुत खास और ज़्यादा जानकारी वाली स्थिति से कर सकता है. आम तौर पर, पैटर्न की लोकप्रिय रूटिंग लाइब्रेरी के उपयोगकर्ताओं को जानकारी होनी चाहिए.
source: इससे पता चलता है किconditionसे मेल खाने वाले रिसॉर्स कैसे लोड किए जाएंगे. फ़िलहाल, सिर्फ़'network'वैल्यू का इस्तेमाल किया जा सकता है (सर्विस वर्कर को छोड़कर, ताकि नेटवर्क पर संसाधन को सीधे लोड किया जा सके), लेकिन आने वाले समय में इसे अन्य वैल्यू के लिए भी बड़ा किया जाएगा.
इस्तेमाल के उदाहरण
जैसा कि बताया गया है, एपीआई का शुरुआती वर्शन कुछ पाथ के लिए सर्विस वर्कर कंट्रोल से बचने का एक तरीका है. इसका इस्तेमाल कहां करना सही होगा, यह इस बात पर निर्भर करता है कि आप अपने सर्विस वर्कर का इस्तेमाल कैसे करते हैं और उपयोगकर्ता आपकी साइट पर कैसे जाते हैं.
इसका एक उदाहरण यह हो सकता है कि आपकी साइट, कैश मेमोरी को पहले इस्तेमाल करने की रणनीति (नेटवर्क पर वापस चली जाए) का इस्तेमाल करती हो, लेकिन कुछ कॉन्टेंट ऐसा है जिसे बहुत कम लोग देखते हैं. इसकी वजह से, कैश मेमोरी में सेव होने की कोई खास अहमियत नहीं रहती है. जैसे, संग्रहित किया गया कॉन्टेंट या आरएसएस फ़ीड. इन पाथ को नेटवर्क से फ़ेच करने के लिए सीमित करने की सुविधा सिर्फ़ सर्विस वर्कर में सेट अप की जा सकती है. हालांकि, सर्विस वर्कर को अब भी शुरू करके चलाना पड़ता है, ताकि उन अनुरोधों को मैनेज करने का तरीका तय किया जा सके.
इसके उलट, स्टैटिक रूटिंग एपीआई, कुछ डिक्लेरेटिव लाइनों के ज़रिए सर्विस वर्कर को पूरी तरह बायपास करता है:
self.addEventListener('install', event => {
if (event.registerRouter) {
event.registerRouter([{
condition: {
urlPattern: {pathname: '/feeds/*.xml'},
},
source: 'network',
}, {
condition: {
urlPattern: {pathname: '/archives/*'},
},
source: 'network',
}]);
}
});
सर्विस वर्कर स्टैटिक रूटिंग एपीआई के बेहतर होने पर, इस कॉन्फ़िगरेशन के लिए प्लान को ज़्यादा सुविधाजनक बनाने और कई स्थितियों में काम करने के लिए बनाया गया है. जैसे, नेटवर्क फ़ेच और सर्विस वर्कर स्टार्ट होने के बारे में एलान करना. ज़्यादा जानकारी के लिए, एपीआई के संभावित "फ़ाइनल फ़ॉर्म" से जुड़ी खास जानकारी को एक्सप्लोर करना देखें.
सर्विस वर्कर स्टैटिक रूटिंग एपीआई को आज़माया जा रहा है
सर्विस वर्कर स्टैटिक रूटिंग एपीआई, Chrome में ऑरिजिन ट्रायल के बाद वाले वर्शन 116 से उपलब्ध होगा. इससे डेवलपर, इस असर को मापने के लिए, अपनी साइट पर एपीआई को असल उपयोगकर्ताओं के साथ टेस्ट कर सकते हैं. ऑरिजिन ट्रायल के बारे में बैकग्राउंड की जानकारी के लिए "ऑरिजिन ट्रायल का इस्तेमाल शुरू करना" देखें.
लोकल टेस्टिंग के लिए, सर्विस वर्कर स्टैटिक रूटिंग एपीआई को chrome://flags/#service-worker-static-router पर
फ़्लैग के साथ चालू किया जा सकता है. इसके अलावा, इसे --enable-features=ServiceWorkerStaticRouter के साथ कमांड से
Chrome को चलाकर भी चालू किया जा सकता है.
फ़ीडबैक और भविष्य के दिशा-निर्देश
सर्विस वर्कर स्टैटिक रूटिंग एपीआई को डेवलप किया जा रहा है और अब भी तैयार किया जा रहा है. अगर आपको ऐसा लगता है कि यह आपके काम का है, तो कृपया इसे ऑरिजिन ट्रायल पर जाकर आज़माएं. साथ ही, एपीआई, लागू करने, और उपलब्ध सुविधाओं के बारे में सुझाव/राय दें या शिकायत करें.