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