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