सेवा वर्कर एक बेहतरीन टूल है. इसकी मदद से, वेबसाइटों को ऑफ़लाइन काम करने की अनुमति मिलती है. साथ ही, वे अपने लिए कैश मेमोरी सेव करने के खास नियम बना सकते हैं. सर्विस वर्कर्स fetch
हैंडलर, उस पेज से मिले हर अनुरोध को देखता है जिसे वह कंट्रोल करता है. साथ ही, यह तय कर सकता है कि उसे सर्विस वर्कर्स कैश मेमोरी से जवाब देना है या पूरी तरह से अलग जवाब पाने के लिए यूआरएल को फिर से लिखना है. उदाहरण के लिए, स्थानीय उपयोगकर्ता की प्राथमिकताओं के आधार पर.
हालांकि, जब कोई पेज कुछ समय बाद पहली बार लोड किया जाता है और कंट्रोल करने वाला सर्विस वर्कर फ़िलहाल नहीं चल रहा है, तो सर्विस वर्कर की परफ़ॉर्मेंस पर असर पड़ सकता है. सभी फ़ेच, सेवा वर्कर के ज़रिए होने चाहिए. इसलिए, ब्राउज़र को यह जानने के लिए, सेवा वर्कर के शुरू होने और चलने का इंतज़ार करना पड़ता है कि कौनसा कॉन्टेंट लोड करना है. स्टार्टअप की यह लागत कम हो सकती है, लेकिन डेवलपर के लिए यह अहम हो सकती है. वे कैश मेमोरी का इस्तेमाल करके, परफ़ॉर्मेंस को बेहतर बनाने के लिए, सेवा वर्कर का इस्तेमाल करते हैं.
नेविगेशन प्रीलोड, इस समस्या को हल करने का एक तरीका है. इससे, नेविगेशन के अनुरोधों को नेटवर्क पर, सेवा वर्कर के स्टार्टअप के साथ-साथ किया जा सकता है. हालांकि, यह शुरुआती नेविगेशन अनुरोधों तक ही सीमित है और अब भी क्रिटिकल पाथ में सेवा वर्कर शामिल है. नेविगेशन प्रीलोड की सुविधा लॉन्च होने के बाद, समस्याओं को हल करने के लिए कई कोशिशें की गई हैं. इनमें, कुछ अनुरोधों को सेवा वर्कर के शुरू होने पर ब्लॉक न करने के तरीके भी शामिल हैं.
Service Worker Static Routing API
Chrome 116 से, एक्सपेरिमेंट के तौर पर उपलब्ध Service Worker स्टैटिक रूटिंग एपीआई, इस तरह के समाधान के पहले चरण की जांच के लिए उपलब्ध है. जब कोई सेवा वर्कर इंस्टॉल किया जाता है, तो वह Service Worker स्टैटिक रूटिंग एपीआई का इस्तेमाल करके, यह बता सकता है कि कुछ संसाधन पाथ को कैसे फ़ेच किया जाना चाहिए.
एपीआई के शुरुआती वर्शन में, पाथ को हमेशा नेटवर्क से दिखाने के लिए तय किया जा सकता है, न कि सर्विस वर्कर से. जब बाद में कोई कंट्रोल किया गया यूआरएल लोड होता है, तो ब्राउज़र उन पाथ से संसाधनों को फ़ेच करना शुरू कर सकता है, इससे पहले कि सर्विस वर्कर शुरू हो जाए. इससे उन पाथ से सर्विस वर्कर हट जाता है जिनके लिए आपको सर्विस वर्कर की ज़रूरत नहीं है.
एपीआई का इस्तेमाल करने के लिए, सेवा वर्कर 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',
}]);
}
});
Service Worker स्टैटिक रूटिंग एपीआई के बेहतर होने के साथ-साथ, इस कॉन्फ़िगरेशन को ज़्यादा सुविधाजनक बनाने और ज़्यादा स्थितियों में काम करने के लिए तैयार किया जा रहा है. जैसे, नेटवर्क फ़ेच और सेवा वर्कर के स्टार्टअप को डिक्लेरेटिव तरीके से रेस करना. ज़्यादा जानकारी के लिए, एपीआई के संभावित "फ़ाइनल फ़ॉर्म" के बारे में खास जानकारी देखें.
Service Worker स्टैटिक रूटिंग एपीआई को आज़माना
Service Worker स्टैटिक रूटिंग एपीआई, Chrome के 116 वर्शन से उपलब्ध है. हालांकि, इसे ऑरिजिन ट्रायल के तहत ही इस्तेमाल किया जा सकता है. इससे डेवलपर, असली उपयोगकर्ताओं के साथ अपनी साइट पर एपीआई को टेस्ट कर सकते हैं, ताकि वे इसके असर का आकलन कर सकें. ऑरिजिन ट्रायल के बारे में जानकारी पाने के लिए, "ऑरिजिन ट्रायल का इस्तेमाल शुरू करना" लेख पढ़ें.
स्थानीय जांच के लिए, Service Worker स्टैटिक रूटिंग एपीआई को chrome://flags/#service-worker-static-router पर फ़्लैग की मदद से चालू किया जा सकता है. इसके अलावा, --enable-features=ServiceWorkerStaticRouter जैसे कमांड से Chrome को चलाकर भी इसे चालू किया जा सकता है.
सुझाव/राय/शिकायत/राय देना और आने वाले समय में क्या करना है
Service Worker स्टैटिक रूटिंग एपीआई को लगातार डेवलप किया जा रहा है और इसे बेहतर बनाया जा रहा है. अगर आपको लगता है कि यह सुविधा आपके लिए काम की हो सकती है, तो कृपया ओरिजिन ट्रायल की मदद से इसे आज़माएं. साथ ही, एपीआई, लागू करने के तरीके, और उपलब्ध सुविधाओं के बारे में सुझाव/राय दें या शिकायत करें.