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