सर्विस वर्कर की एक सुविधा यह है कि सर्विस वर्कर इंस्टॉल करते समय फ़ाइलों को कैश मेमोरी में सेव कर सकता है. इसे "प्रीकैशिंग" कहा जाता है. पहले से कैश मेमोरी में सेव करने की सुविधा से, कैश मेमोरी में सेव की गई फ़ाइलों को नेटवर्क पर जाए बिना ब्राउज़र पर उपलब्ध कराया जा सकता है. उन अहम ऐसेट के लिए प्रीकैशिंग का इस्तेमाल करें जिनकी ज़रूरत आपकी साइट के ऑफ़लाइन होने पर भी होती है: जैसे, मुख्य पेज, स्टाइल, फ़ॉलबैक इमेज, और ज़रूरी स्क्रिप्ट.
आपको Workbox का इस्तेमाल क्यों करना चाहिए?
प्रीकैशिंग के लिए Workbox का इस्तेमाल करना ज़रूरी नहीं है. सर्विस वर्कर के इंस्टॉल होते समय, ज़रूरी ऐसेट को पहले से कैश मेमोरी में सेव करने के लिए, खुद का कोड लिखा जा सकता है. Workbox के इस्तेमाल का मुख्य फ़ायदा है इसके वर्शन कंट्रोल को सबसे बेहतर बनाना. इन फ़ाइलों के वर्शन और अपडेट को खुद मैनेज करने की तुलना में, आपको Workbox का इस्तेमाल करके पहले से कैश मेमोरी में सेव की गई ऐसेट को अपडेट करने में बहुत कम परेशानी होगी.
प्रीकैश मेनिफ़ेस्ट
हर यूआरएल के वर्शन की जानकारी और यूआरएल की सूची के हिसाब से, पहले से कैश मेमोरी को प्रोसेस किया जाता है. कुल मिलाकर, इस जानकारी को प्रीकैश मेनिफ़ेस्ट कहा जाता है. मेनिफ़ेस्ट, किसी वेब ऐप्लिकेशन के दिए गए वर्शन के प्री-कैश मेमोरी में होने वाली हर चीज़ की स्थिति के लिए "सही जानकारी का सोर्स" होता है. वर्कबॉक्स में इस्तेमाल किए गए फ़ॉर्मैट में प्रीकैश मेनिफ़ेस्ट कुछ ऐसा दिखता है:
[{
url: 'app.abcd1234.js'
}, {
url: 'offline.svg',
revision: '7836745f'
}, {
url: 'index.html',
revision: '518747aa'
}]
सर्विस वर्कर इंस्टॉल होने पर, कैश मेमोरी में तीन सूची में शामिल हर यूआरएल के लिए कैश मेमोरी में तीन कैश एंट्री बन जाती हैं. पहली ऐसेट के यूआरएल में वर्शन से जुड़ी जानकारी पहले से ही शामिल है (app फ़ाइल का असल नाम है और .abcd1234 में फ़ाइल एक्सटेंशन .js से ठीक पहले वर्शन की जानकारी होती है). वर्कबॉक्स के बिल्ड टूल इसका पता लगा सकते हैं और किसी रीविज़न फ़ील्ड को बाहर रख सकते हैं. अन्य दो ऐसेट के यूआरएल में, वर्शन की कोई भी जानकारी शामिल नहीं होती. इसलिए, Workbox के बिल्ड टूल एक अलग revision फ़ील्ड बनाते हैं, जिसमें लोकल फ़ाइल के कॉन्टेंट का हैश शामिल होता है.
पहले से कैश मेमोरी में सेव किए गए संसाधन दिखाए जा रहे हैं
ऐसेट को कैश मेमोरी में जोड़ना, पहले से कैश मेमोरी में सेव होने वाली प्रोसेस का सिर्फ़ एक हिस्सा है. ऐसेट कैश मेमोरी में सेव होने के बाद, उन्हें भेजे जाने वाले अनुरोधों का जवाब देना पड़ता है. इसके लिए, आपके सर्विस वर्कर में fetch इवेंट लिसनर की ज़रूरत होती है, जो यह जांच कर सकता है कि कौनसे यूआरएल पहले से कैश मेमोरी में सेव किए गए हैं. साथ ही, यह कैश मेमोरी में सेव किए गए जवाबों को भरोसेमंद तरीके से लौटा सकता है. इसके लिए, इस प्रोसेस में नेटवर्क को बायपास किया जाता है. सर्विस वर्कर, जवाबों के लिए कैश मेमोरी की जांच करता है (और नेटवर्क से पहले उनका इस्तेमाल करता है). इसलिए, इसे कैश मेमोरी को प्राथमिकता देने की रणनीति कहा जाता है.
बेहतर अपडेट
प्री-कैश मेनिफ़ेस्ट में कैश मेमोरी की अनुमानित स्थिति के बारे में सटीक जानकारी मिलती है. अगर मेनिफ़ेस्ट में यूआरएल/रिविज़न का कोई कॉम्बिनेशन बदलता है, तो सर्विस वर्कर यह जानता है कि कैश मेमोरी में सेव की गई पिछली एंट्री अब मान्य नहीं है और उसे अपडेट करने की ज़रूरत है. यह सिर्फ़ एक नेटवर्क अनुरोध करता है, जो ब्राउज़र से सर्विस वर्कर की अपडेट की जांच के हिस्से के तौर पर अपने-आप होता है. इससे यह तय किया जा सकता है कि पहले से कैश मेमोरी में सेव किए गए किन यूआरएल को रीफ़्रेश करने की ज़रूरत है.
पहले से कैश मेमोरी में सेव किए गए संसाधनों के बारे में अपडेट
समय के साथ वेब ऐप्लिकेशन के नए वर्शन रिलीज़ करने पर, आपको पहले से कैश मेमोरी में सेव किए गए यूआरएल अप-टू-डेट रखने होंगे, नई ऐसेट पहले से इकट्ठा करनी होंगी, और पुरानी एंट्री मिटानी होंगी. जब तक साइट को फिर से बनाएं, तब तक हर बार पूरी तरह से कैश मेमोरी में सेव किया जाने वाला मेनिफ़ेस्ट जनरेट किया जा सकता है. यह मेनिफ़ेस्ट किसी भी समय, पहले से कैश मेमोरी में सेव होने वाली आपकी स्थिति के लिए, "सही सोर्स" के तौर पर काम करेगा.
अगर नए रिविज़न फ़ील्ड वाला कोई मौजूदा यूआरएल है या मेनिफ़ेस्ट से किसी यूआरएल को जोड़ा या हटाया गया है, तो यह आपके सर्विस वर्कर की ओर से संकेत देता है कि install और activate इवेंट हैंडलर के हिस्से के तौर पर इन्हें अपडेट करने की ज़रूरत है. उदाहरण के लिए, अगर आपने अपनी साइट में कुछ बदलाव किए हैं और
उसे फिर से बनाया है, तो हो सकता है कि आपके सबसे नए प्री-कैश मेनिफ़ेस्ट में ये बदलाव हुए हों:
[{
url: 'app.ffaa4455.js'
}, {
url: 'offline.svg',
revision: '7836745f'
}, {
url: 'index.html',
revision: '518747aa'
}]
इनमें से हर बदलाव आपके सर्विस वर्कर को बताता है कि पहले से कैश की गई एंट्री ('offline.svg' और 'index.html') को अपडेट करने और नए यूआरएल ('app.ffaa4455.js') को कैश मेमोरी में सेव करने के लिए नए अनुरोध करने होंगे. साथ ही, ऐसे यूआरएल हटाने के लिए भी नए अनुरोध करने होंगे जिनका अब इस्तेमाल नहीं किया जाता है ('app.abcd1234.js').
सही "app store" से इंस्टॉल अनुभव
पहले से कैश मेमोरी में सेव करने का एक और फ़ायदा यह है कि अपने उपयोगकर्ताओं को ऐसा अनुभव दिया जा सकता है जिसे "ऐप स्टोर" इंस्टॉल के बाहर हासिल करना मुश्किल हो सकता है. जब कोई उपयोगकर्ता आपके वेब ऐप्लिकेशन पर पहली बार किसी पेज पर जाता है, तो आप अपने वेब ऐप्लिकेशन के किसी भी व्यू को पहले से दिखाने के लिए ज़रूरी सभी यूआरएल को पहले ही कैश मेमोरी में सेव कर सकते हैं. इसके लिए आपको हर व्यू पर उनके जाने का इंतज़ार नहीं करना होगा.
जब कोई उपयोगकर्ता ऐप्लिकेशन इंस्टॉल करता है, तो वह उम्मीद करता है कि उसका हर हिस्सा जल्द ही दिखेगा, न कि सिर्फ़ वे व्यू जिन्हें वह पहले देख चुका है. पहले से कैश मेमोरी को सेव करने से, वेब ऐप्लिकेशन को भी वही अनुभव मिलता है.
आपको किस तरह की ऐसेट को पहले से कैश मेमोरी में सेव करना चाहिए?
जानें कि क्या लोड हो रहा है गाइड को फिर से पढ़ें. इससे आपको पता चलेगा कि किन यूआरएल को पहले से कैश मेमोरी में सेव करना सबसे सही रहेगा. सामान्य नियम यह है कि किसी भी एचटीएमएल, JavaScript या सीएसएस को पहले से कैश मेमोरी में सेव किया जाए. ऐसा एचटीएमएल, JavaScript या सीएसएस को पहले से तय करना होता है जो जल्दी लोड होता है और किसी पेज का बेसिक स्ट्रक्चर दिखाने के लिए ज़रूरी होता है.
पहले से लोड होने वाले मीडिया या अन्य ऐसेट को प्रीकैश करने से बचें. ऐसा तब करें, जब आपके वेब ऐप्लिकेशन के काम करने के तरीके के लिए यह ज़रूरी न हो. इसके बजाय, रनटाइम कैश मेमोरी की रणनीति का इस्तेमाल करें, ताकि यह पक्का किया जा सके कि इन ऐसेट को इस्तेमाल के हिसाब से कैश मेमोरी में सेव किया जाए.
हमेशा ध्यान रखें कि पहले से कैश मेमोरी में सेव होने की प्रोसेस में, उपयोगकर्ता के डिवाइस पर नेटवर्क बैंडविथ और स्टोरेज का इस्तेमाल किया जाता है. ठीक वैसे ही जैसे ऐप स्टोर से ऐप्लिकेशन इंस्टॉल किया जाता है. डेवलपर के तौर पर, यह आपकी ज़िम्मेदारी है कि आप समझदारी से, ऐप्लिकेशन को पहले से कैश मेमोरी में सेव करें और पहले से कैश मेमोरी में सेव होने वाले ऐप्लिकेशन के मेनिफ़ेस्ट से बचें.
Workbox के बिल्ड टूल से आपको प्रीकैश मेनिफ़ेस्ट में मौजूद आइटम की संख्या और प्रीकैश पेलोड के कुल साइज़ के बारे में जानकारी मिलती है.
प्रीकैशिंग के शुरुआती खर्च से लंबे समय तक, आपके वेब ऐप्लिकेशन पर बार-बार आने वाले लोगों को फ़ायदा होगा. ऐसा इसलिए, क्योंकि नेटवर्क से बचने की इसकी क्षमता समय के साथ सेव किए गए बैंडविड्थ में अपने लिए चुकानी पड़ती है.