सर्विस वर्कर की एक सुविधा यह है कि सर्विस वर्कर को इंस्टॉल करते समय फ़ाइलों को कैश मेमोरी में सेव किया जा सकता है. इसे "प्रीकैशिंग" कहा जाता है. प्रीकैशिंग से, नेटवर्क में जाए बिना ब्राउज़र पर कैश मेमोरी में सेव की गई फ़ाइलें दिखाई जा सकती हैं. उन ज़रूरी एसेट के लिए पहले से कैश मेमोरी का इस्तेमाल करें जिनकी ज़रूरत आपकी साइट को, ऑफ़लाइन होने पर भी होती है: मुख्य पेज, स्टाइल, फ़ॉलबैक इमेज, और ज़रूरी स्क्रिप्ट.
आपको Workbox का इस्तेमाल क्यों करना चाहिए?
प्रीकैशिंग के लिए 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') को मिटाने के लिए, उन्हें मिटाना भी ज़रूरी है.
"ऐप स्टोर" इंस्टॉल करने का सही अनुभव
प्रीकैश मेमोरी का एक और फ़ायदा यह है कि आप उपयोगकर्ताओं को ऐसा अनुभव दे सकते हैं जिन्हें "ऐप स्टोर" इंस्टॉल करने के बाहर हासिल करना मुश्किल हो सकता है. जब कोई उपयोगकर्ता पहली बार आपके वेब ऐप्लिकेशन के किसी पेज पर जाता है, तो आपके पास अपने वेब ऐप्लिकेशन के किसी भी व्यू को दिखाने के लिए, ज़रूरी सभी यूआरएल प्री-कैश मेमोरी में सेव हो जाते हैं. इसके लिए, उन्हें हर व्यू पर जाने का इंतज़ार नहीं करना पड़ता.
जब कोई उपयोगकर्ता कोई ऐप्लिकेशन इंस्टॉल करता है, तो वह उम्मीद करता है कि पेज का हर हिस्सा जल्दी दिखे, न कि सिर्फ़ वे व्यू जिन्हें वे पहले देख चुके हैं. प्रीकैशिंग से वेब ऐप्लिकेशन में भी वही अनुभव मिलता है.
आपकी कौनसी ऐसेट पहले से कैश मेमोरी में सेव होनी चाहिए?
प्री-कैश करने के लिए सबसे ज़्यादा इस्तेमाल किए जाने वाले यूआरएल की जानकारी पाने के लिए, पता लगाएं कि क्या लोड हो रहा है गाइड देखें. सामान्य नियम ऐसे किसी भी एचटीएमएल, JavaScript या सीएसएस को पहले से कैश मेमोरी में सेव करना है जो पहले लोड होता है. साथ ही, किसी पेज की बुनियादी बनावट दिखाने के लिए यह ज़रूरी है.
बेहतर होगा कि बाद में लोड किए जाने वाले मीडिया या अन्य ऐसेट को पहले से कैश मेमोरी में सेव न किया जाए. ऐसा सिर्फ़ तब किया जाता है, जब वेब ऐप्लिकेशन के फ़ंक्शन के लिए ज़रूरी न हो. इसके बजाय, रनटाइम कैश मेमोरी में सेव करने की रणनीति का इस्तेमाल करें, ताकि यह पक्का किया जा सके कि ये ऐसेट, रीयल-टाइम में कैश मेमोरी में सेव हों.
हमेशा ध्यान रखें कि प्री-कैशिंग में उपयोगकर्ता के डिवाइस पर नेटवर्क बैंडविड्थ और डिवाइस की मेमोरी का इस्तेमाल होता है (ठीक वैसे ही जैसे किसी ऐप स्टोर से ऐप्लिकेशन इंस्टॉल किया जाता है). यह डेवलपर के तौर पर आपकी ज़िम्मेदारी है कि वह सही तरीके से प्रीकैश मेमोरी में सेव हो जाए और पूरी तरह से कैश मेमोरी में सेव किए गए मेनिफ़ेस्ट से बचा जाए.
वर्कबॉक्स के बिल्ड टूल आपको प्री-कैश मेमोरी में मौजूद आइटम की संख्या और प्रीकैश पेलोड का कुल साइज़ बताते हैं.
प्री-कैशिंग की शुरुआती लागत से लंबे समय में, आपके वेब ऐप्लिकेशन पर आने वाले लोगों को बार-बार फ़ायदा होता है. इसकी वजह यह है कि नेटवर्क से बचने की सुविधा की मदद से, समय के साथ सेव किए गए बैंडविथ में खुद ही पैसा चुकाया जाता है.