सर्विस वर्कर को डिप्लॉय करने पर, किसी वेबसाइट के काम करने के तरीके में बदलाव आ सकता है. हालांकि, ऐसा कई बार हो सकता है. वर्कबॉक्स की मदद से, सर्विस वर्कर को लिखना और डिप्लॉय करना आसान हो जाता है. इसलिए, डिप्लॉय करने के बाद वेबसाइट पर सर्विस वर्कर के कुछ असर छूट सकते हैं.
इसका मतलब यह नहीं है कि Workbox का इस्तेमाल करने के नतीजे खराब होते हैं. सिर्फ़ सुविधा मिलने के बाद, अगर किसी को यह न पता हो कि सर्विस वर्कर को डिप्लॉय करने का क्या फ़ायदा है, तो कुछ मुश्किलें भी आसानी से हो जाती हैं.
प्रीकैशिंग के दौरान होने वाली गलतियां
इन दस्तावेज़ों में प्री-कैशिंग के बारे में पहले ही जानकारी दी जा चुकी है. हालांकि, इस बारे में पूरी तरह से जानकारी नहीं दी गई है कि यह तरीका किस तरह पीछे हट सकता है. बहुत ज़्यादा एसेट के लिए प्रीकैशिंग लागू करने पर या पेज के ज़रूरी एसेट लोड होने से पहले ही सर्विस वर्कर के रजिस्टर होने पर, आपको समस्याएं आ सकती हैं.
workbox-webpack-plugin के डिफ़ॉल्ट व्यवहार की वजह से, सर्विस वर्कर को जनरेट की गई एसेट अपने-आप कैश मेमोरी में सेव करने का निर्देश देने की कोशिश की जाती है. इस वजह से, इन्हें आसानी से इस्तेमाल करने में समस्या आ सकती है, क्योंकि इसे इस्तेमाल करने में कोई रुकावट नहीं आती.
workbox-webpack-plugin. से मिलने वाला टर्मिनल आउटपुट
इस उदाहरण में, यह मौजूदा प्रोजेक्ट में 14 ऐसेट को डिफ़ॉल्ट रूप से कुल 352 किलोबाइट प्रति कैश मेमोरी के तौर पर प्री-कैश करता है.जब कोई सर्विस वर्कर, इंस्टॉलेशन के दौरान एसेट को पहले से सेव करता है, तो एक या उससे ज़्यादा नेटवर्क अनुरोध एक साथ शुरू होते हैं. अगर इसे सही समय पर न चलाया जाए, तो उपयोगकर्ता अनुभव पर बुरा असर पड़ सकता है. अगर सटीक समय वाला कन्वर्ज़न ट्रैकिंग सेट है, तो भी पहले से कैश मेमोरी में सेव की गई एसेट की संख्या को सीमित न किया जाए, तो इससे डेटा की बर्बादी हो सकती है.
आपने तय समय के हिसाब से काम किया है
अगर कोई सर्विस वर्कर, किसी भी चीज़ को प्री-कैश करता है, तो उसके रजिस्टर होने का समय अहम होता है.
सर्विस वर्कर अक्सर इनलाइन <script> एलिमेंट का इस्तेमाल करके रजिस्टर किए जाते हैं.
इसका मतलब है कि पेज की ज़रूरी ऐसेट लोड होने से पहले, एचटीएमएल पार्सर, सर्विस वर्कर के रजिस्ट्रेशन कोड को खोज सकते हैं.
यह एक समस्या है. सर्विस वर्कर को सबसे खराब स्थिति में आम तौर पर, अपनी परफ़ॉर्मेंस
न्यूट्रल नहीं होना चाहिए, ताकि परफ़ॉर्मेंस खराब न हो. उपयोगकर्ताओं पर एहसान करें और
पेज के load इवेंट के सक्रिय होने पर सर्विस वर्कर के लिए रजिस्टर करें.
इससे यह संभावना कम हो जाती है कि प्रीकैशिंग की वजह से, पेज की क्रिटिकल ऐसेट लोड होने में रुकावट आएगी. इसका मतलब है कि पेज को तेज़ी से इंटरैक्टिव बनाया जा सकता है. इसके लिए, उन्हें ऐसेट के लिए नेटवर्क अनुरोधों पर काम नहीं करना पड़ता, जिसकी ज़रूरत शायद बाद में हो.
डेटा खर्च का ध्यान रखें
समय पर ध्यान दिए बिना, प्रीकैशिंग में नेटवर्क अनुरोधों को भेजना शामिल है. अगर प्रीकैश करने के लिए एसेट के किसी मेनिफ़ेस्ट को सावधानी से इकट्ठा नहीं किया गया है, तो इससे कुछ हद तक बर्बाद हो सकता है.
बर्बाद किया गया डेटा, प्रीकैशिंग का एक संभावित दुविधा हो सकता है, लेकिन तेज़ इंटरनेट या अनलिमिटेड डेटा प्लान का ऐक्सेस सभी के पास नहीं होता! पहले से कैश मेमोरी में सेव करते समय, खास तौर पर बड़े एसेट को काटने के बारे में सोचें. साथ ही, खर्च का अनुमान लगाने के बजाय उन्हें कैप्चर करने के लिए, रनटाइम के दौरान कैश मेमोरी का इस्तेमाल करें.
सर्विस वर्कर के शुरू होने की वजह से, नेटवर्क के अनुरोध आने में देरी हो सकती है
सर्विस वर्कर, वेबसाइट के बाकी कोड से अलग प्रोसेस में चलते हैं. यह प्रोसेस बार-बार शुरू और बंद होती है. जब किसी सर्विस वर्कर को बंद होने के बाद फ़ेच इवेंट को हैंडल करने की ज़रूरत होती है, तो ब्राउज़र को सबसे पहले सर्विस वर्कर को शुरू करने में समय लगता है. अनुरोध पर कार्रवाई करने से पहले लगने वाला यह ज़्यादा खर्च, नेटवर्क के बजाय कैश मेमोरी से जवाब देने के फ़ायदे के मुकाबले कम होता है.
ऐसी रणनीतियों का इस्तेमाल करते समय जिन्हें कैश मेमोरी से इस्तेमाल नहीं किया जा सकता और नेटवर्क पर जाना पड़ता है—खास तौर पर, नेविगेशन के अनुरोधों पर काम करते समय—बूटअप समय में हमेशा थोड़ी देरी होती है. डिवाइस की क्षमताओं और/या सीपीयू के दबाव के आधार पर, धीमे सर्विस वर्कर बूट-अप की वजह से नेविगेशन अनुरोध में काफ़ी देरी हो सकती है. इस देरी की जानकारी न रखते हुए किसी सर्विस वर्कर को डिप्लॉय करने का मतलब है कि उपयोगकर्ताओं को अनजाने में परफ़ॉर्मेंस पर असर पड़ सकता है.
इस समस्या को नेविगेशन प्रीलोड की मदद से हल कर दिया गया है, लेकिन यह अभी तक सभी ब्राउज़र पर काम नहीं करती. हालांकि, इसके इस्तेमाल पर विचार करना ज़रूरी है. इस बारे में इस दस्तावेज़ में बाद में बताया गया है.
कैश मेमोरी को प्राथमिकता देने वाली रणनीतियां, काम करना बंद कर सकती हैं
कैश मेमोरी में सेव डेटा को कैश मेमोरी में सेव करने की रणनीतियां, ऑफ़लाइन ऐक्सेस और परफ़ॉर्मेंस, दोनों के लिए बहुत बढ़िया होती हैं. इनमें सिर्फ़ कैश मेमोरी से जानकारी शामिल करना शामिल है. हालांकि, कुछ चुनिंदा मामलों में इनकी वजह से समस्याएं आ सकती हैं.
ऐसी स्टैटिक ऐसेट की रनटाइम कैश मेमोरी जिसे इस्तेमाल नहीं किया जा सकता
बंडलर आम तौर पर फ़ाइल के नाम (उदाहरण के लिए, styles.a4edf38c.css) में कॉन्टेंट-आधारित हैश के साथ स्टैटिक एसेट का वर्शन बनाते हैं.
ऐसे सर्विस वर्कर जो स्टैटिक एसेट के लिए कैश मेमोरी से पहले कैश मेमोरी इस्तेमाल करते हैं और पेज मार्कअप के लिए नेटवर्क-फ़र्स्ट रणनीति का इस्तेमाल करते हैं
वे कैश मेमोरी की रणनीतियों का इस्तेमाल करते हैं.
इसमें कैश मेमोरी की समस्या नहीं होनी चाहिए, क्योंकि अपडेट की गई एसेट का रेफ़रंस मार्कअप में किया जाता है, जिसे हमेशा नेटवर्क से वापस लाया जाता है.
ऐसी स्थितियों में समस्याएं आती हैं जब रनटाइम के दौरान, इन रणनीतियों का इस्तेमाल करके, वापस नहीं ली गई स्टैटिक ऐसेट को कैश मेमोरी में सेव किया जाता है.
अगर किसी वेबसाइट की सुविधाएं app.js देता है और कैश-फ़र्स्ट रनटाइम रणनीति का इस्तेमाल किया जाता है,
तो app.js को बाद में फ़ाइल के नाम में बदलाव किए बिना अपडेट किया जाता है.
शुरुआत में, कैश मेमोरी में सेव किया गया वर्शन, अपडेट होने के बजाय कैश मेमोरी से दिखाया जाता है.
इसे हल करने के लिए ऐसी रणनीति का इस्तेमाल करना चाहिए जो अपडेट के लिए नेटवर्क से सलाह ले. जैसे, 'नेटवर्क-फ़र्स्ट' या 'फिर से पुष्टि' के दौरान पुरानी जानकारी. इसके अलावा, बिल्ड टूल उन एसेट के लिए प्री-कैश मेनिफ़ेस्ट जनरेट कर सकते हैं, क्योंकि वर्कबॉक्स को पहले से कैश मेमोरी में सेव करने का लॉजिक, उन्हें अप-टू-डेट रखेगा.
इसके बावजूद, हम स्टैटिक एसेट को वर्शन देने पर विचार करते हैं, चाहे एसेट के नाम में हैश का इस्तेमाल करें या क्वेरी स्ट्रिंग में. इससे उन सर्विस वर्कर में पुरानी एसेट से जुड़ी समस्याएं नहीं होंगी जो स्टैटिक एसेट के लिए कैश-फ़र्स्ट रनटाइम रणनीतियों का इस्तेमाल करती हैं.
माइंड स्टोरेज कोटा
समय-समय पर सर्विस वर्कर के अपडेट रोल आउट करना सामान्य बात है. अपडेट रोल आउट होने पर, नए सर्विस वर्कर के चालू होने के दौरान, जिनकी समयसीमा खत्म हो चुकी है उनके पुराने कैश आम तौर पर हटा दिए जाते हैं.
हालांकि, कुछ सर्विस वर्कर इटरेशन लंबे समय तक बने रहते हैं या हो सकता है कि नए अपडेट में कैश नाम अपडेट न हों. ऐसा होने पर, अपडेट रोल आउट होने पर पुरानी स्टैटिक एसेट, कैश मेमोरी में जमा हो सकती हैं. ब्राउज़र, स्टोरेज कोटा सेट करते हैं. इनकी सीमाएं अलग-अलग हो सकती हैं. उन्हें ध्यान में रखना एक अच्छी वजह है!
वर्कबॉक्स इन समस्याओं को कम कर देता है, लेकिन फिर भी स्टोरेज कोटा पार हो सकता है. workbox-expiration मॉड्यूल की मदद से, कैश मेमोरी को बेहतर तरीके से कंट्रोल किया जा सकता है.
डरें नहीं
सर्विस वर्कर को डिप्लॉय करना कोई छोटी चीज़ नहीं है. हालांकि, अगर वर्कबॉक्स के साथ सर्विस वर्कर को डिप्लॉय करने का प्लान बनाया जाता है और सोच-समझकर काम किया जाता है, तो यह एक डरावनी उपलब्धि नहीं होनी चाहिए. जारी रखने के साथ-साथ, इस दस्तावेज़ की मदद से, सावधानी और भरोसे के साथ इन समस्याओं से निपटने में मदद पाएं.