संचय कर रहा है

कैश मेमोरी स्टोरेज एक बेहतरीन टूल है. इससे आपके ऐप्लिकेशन, नेटवर्क की स्थिति पर कम निर्भर होते हैं. कैश मेमोरी का सही इस्तेमाल करके, अपने वेब ऐप्लिकेशन को ऑफ़लाइन उपलब्ध कराया जा सकता है. साथ ही, किसी भी नेटवर्क स्थिति में अपनी ऐसेट को ज़्यादा से ज़्यादा तेज़ी से दिखाया जा सकता है. ऐसेट और डेटा में बताए गए तरीके से, ज़रूरी ऐसेट को कैश मेमोरी में सेव करने की सबसे अच्छी रणनीति तय की जा सकती है. कैश मेमोरी को मैनेज करने के लिए, आपका सेवा वर्कर Cache Storage API के साथ इंटरैक्ट करता है.

ब्राउज़र के इस्तेमाल से जुड़ी सहायता

सोर्स

ध्यान दें: किसी प्लैटफ़ॉर्म के लिए बने ऐप्लिकेशन इंस्टॉल करते समय, डिवाइस एक ही चरण में ऑपरेटिंग सिस्टम में ऐप्लिकेशन का आइकॉन और अन्य एसेट सेव करता है. PWA के लिए, इस प्रोसेस में दो अलग-अलग चरण होते हैं. ब्राउज़र में पहली बार विज़िट करने के बाद, कोई PWA आपके डिवाइस पर एसेट को किसी भी समय सेव कर सकता है. ऐसा, बिना इंस्टॉल किए भी किया जा सकता है. इंस्टॉल करना एक अलग कार्रवाई है. इस बारे में इस कोर्स में आगे बताया गया है.

Cache Storage API, अलग-अलग संदर्भों में उपलब्ध है:

विंडो कॉन्टेक्स्ट (आपके PWA की मुख्य थ्रेड).
सर्विस वर्कर.
आपके इस्तेमाल में आने वाले अन्य वर्कर्स.

सेवा वर्कर का इस्तेमाल करके कैश मेमोरी मैनेज करने का एक फ़ायदा यह है कि इसका लाइफ़साइकल, विंडो से जुड़ा नहीं होता. इसका मतलब है कि आप मुख्य थ्रेड को ब्लॉक नहीं कर रहे हैं. ध्यान रखें कि Cache Storage API का इस्तेमाल करने के लिए, इनमें से ज़्यादातर कॉन्टेक्स्ट को टीएलएस कनेक्शन के तहत होना चाहिए.

क्या कैश मेमोरी में सेव करना है

कैश मेमोरी सेव करने के बारे में सबसे पहला सवाल यह है कि क्या कैश मेमोरी में सेव किया जाए. इस सवाल का कोई एक जवाब नहीं है. हालांकि, यूज़र इंटरफ़ेस को रेंडर करने के लिए, ज़रूरी सभी संसाधनों के साथ शुरुआत की जा सकती है.

इन रिसॉर्स में ये चीज़ें शामिल होनी चाहिए:

मुख्य पेज का एचटीएमएल (आपके ऐप्लिकेशन का start_url).
मुख्य यूज़र इंटरफ़ेस के लिए ज़रूरी सीएसएस स्टाइलशीट.
यूज़र इंटरफ़ेस में इस्तेमाल की गई इमेज.
यूज़र इंटरफ़ेस को रेंडर करने के लिए ज़रूरी JavaScript फ़ाइलें.
JSON फ़ाइल जैसा डेटा, जो बुनियादी अनुभव को रेंडर करने के लिए ज़रूरी है.
वेब फ़ॉन्ट.
कई पेजों वाले ऐप्लिकेशन में, ऐसे अन्य एचटीएमएल दस्तावेज़ जिन्हें आपको तेज़ी से या ऑफ़लाइन दिखाना है.

ऑफ़लाइन इस्तेमाल के लिए तैयार

प्रोग्रेसिव वेब ऐप्लिकेशन के लिए, ऑफ़लाइन काम करने की सुविधा होना ज़रूरी है. हालांकि, यह समझना ज़रूरी है कि हर प्रोग्रेसिव वेब ऐप्लिकेशन को पूरी तरह से ऑफ़लाइन काम करने की ज़रूरत नहीं होती. उदाहरण के लिए, क्लाउड गेमिंग सलूशन या क्रिप्टो एसेट ऐप्लिकेशन. इसलिए, ऐसे मामलों में उपयोगकर्ताओं को गाइड करने के लिए, बुनियादी यूज़र इंटरफ़ेस देना ठीक है.

आपके PWA को ब्राउज़र का गड़बड़ी का मैसेज नहीं दिखाना चाहिए. इस मैसेज में यह जानकारी होती है कि वेब रेंडरिंग इंजन, पेज को लोड नहीं कर सका. इसके बजाय, अपने मैसेज दिखाने के लिए अपने सेवा वर्कर का इस्तेमाल करें. इससे, ब्राउज़र में सामान्य और भ्रमित करने वाली गड़बड़ी से बचा जा सकता है.

अपने PWA की ज़रूरतों के हिसाब से, कैश मेमोरी सेव करने की कई अलग-अलग रणनीतियों का इस्तेमाल किया जा सकता है. इसलिए, तेज़ और भरोसेमंद अनुभव देने के लिए, कैश मेमोरी के इस्तेमाल को डिज़ाइन करना ज़रूरी है. उदाहरण के लिए, अगर आपके ऐप्लिकेशन की सभी एसेट तेज़ी से डाउनलोड हो जाती हैं, ज़्यादा जगह नहीं लेती हैं, और हर अनुरोध में अपडेट करने की ज़रूरत नहीं होती है, तो सभी एसेट को कैश मेमोरी में सेव करना एक सही रणनीति होगी. दूसरी ओर, अगर आपके पास ऐसे संसाधन हैं जिनका नया वर्शन होना ज़रूरी है, तो हो सकता है कि आप उन एसेट को कैश मेमोरी में सेव न करना चाहें.

चेतावनी: कैश मेमोरी में सेव किए गए कॉन्टेंट और उसे हटाने के नियम, हर ऑरिजिन के हिसाब से सेट किए जाते हैं, न कि हर PWA के हिसाब से. ऐसा इसलिए, क्योंकि एक ही ऑरिजिन में एक से ज़्यादा PWA हो सकते हैं. अगर आपने कई PWA के लिए अपना ऑरिजिन शेयर किया है, तो अपने कैश मेमोरी के नामों में प्रीफ़िक्स जोड़ना अच्छा रहेगा. इससे हर PWA के डेटा स्टोरेज में डेटा के डुप्लीकेट होने से जुड़ी समस्याओं से बचा जा सकता है.

एपीआई का इस्तेमाल करना

अपने ऑरिजिन में कैश मेमोरी का सेट तय करने के लिए, Cache Storage API का इस्तेमाल करें. हर कैश मेमोरी को स्ट्रिंग के नाम से पहचाना जाता है. caches ऑब्जेक्ट की मदद से एपीआई को ऐक्सेस करें. साथ ही, open तरीके से पहले से बनाए गए कैश मेमोरी को खोला या बनाया जा सकता है. open मेथड, कैश मेमोरी ऑब्जेक्ट के लिए एक प्रॉमिस दिखाता है.

caches.open("pwa-assets")
.then(cache => {
  // you can download and store, delete or update resources with cache arguments
});

ऐसेट डाउनलोड और सेव करना

ब्राउज़र से ऐसेट डाउनलोड और सेव करने के लिए, add या addAll तरीकों का इस्तेमाल करें. add तरीका, अनुरोध करता है और एक एचटीटीपी रिस्पॉन्स को सेव करता है. वहीं, addAll तरीका, अनुरोधों या यूआरएल के कलेक्शन के आधार पर, लेन-देन के तौर पर एचटीटीपी रिस्पॉन्स के ग्रुप को सेव करता है.

caches.open("pwa-assets")
.then(cache => {
  cache.add("styles.css"); // it stores only one resource
  cache.addAll(["styles.css", "app.js"]); // it stores two resources
});

ध्यान दें: add() और addAll(), दोनों बिना किसी आर्ग्युमेंट के प्रॉमिस दिखाते हैं. अगर यह पूरा हो जाता है, तो आपको पता चलता है कि एसेट डाउनलोड और कैश मेमोरी में सेव हो गई हैं. अगर यह पूरा नहीं होता है, तो इसका मतलब है कि एपीआई एक या उससे ज़्यादा संसाधनों को डाउनलोड नहीं कर सका और उसने कैश मेमोरी में बदलाव नहीं किया.

कैश स्टोरेज इंटरफ़ेस, किसी रिस्पॉन्स के सभी हेडर और मुख्य हिस्से को सेव करता है. इसलिए, इसे बाद में किसी एचटीटीपी अनुरोध या यूआरएल को कुंजी के तौर पर इस्तेमाल करके वापस पाया जा सकता है. विज्ञापन दिखाने के बारे में बताने वाले चैप्टर में, आपको यह तरीका पता चलेगा.

कैश मेमोरी कब भरें

अपने PWA में, यह तय करने का अधिकार आपके पास होता है कि फ़ाइलों को कब कैश मेमोरी में सेव करना है. सेवा वर्कर इंस्टॉल होने पर, ज़्यादा से ज़्यादा ऐसेट स्टोर करने का एक तरीका है. हालांकि, आम तौर पर यह सबसे अच्छा तरीका नहीं है. ज़रूरत न पड़ने वाले रिसॉर्स को कैश मेमोरी में सेव करने से, बैंडविड्थ और स्टोरेज का गलत तरीके से इस्तेमाल होता है. साथ ही, इससे आपके ऐप्लिकेशन में पुराने रिसॉर्स दिख सकते हैं.

आपको सभी ऐसेट को एक साथ कैश मेमोरी में सेव करने की ज़रूरत नहीं है. अपने PWA के लाइफ़साइकल के दौरान, ऐसेट को कई बार कैश मेमोरी में सेव किया जा सकता है. जैसे:

सेवा वर्कर के इंस्टॉल होने पर.
पहले पेज लोड होने के बाद.
जब उपयोगकर्ता किसी सेक्शन या रूट पर जाता है.
जब नेटवर्क इस्तेमाल में न हो.

मुख्य थ्रेड या सेवा वर्कर के कॉन्टेक्स्ट में, नई फ़ाइलों को कैश मेमोरी में सेव करने का अनुरोध किया जा सकता है.

सेवा वर्कर में ऐसेट कैश मेमोरी में सेव करना

आम तौर पर, सेवा वर्कर इंस्टॉल होने पर एसेट का कम से कम सेट कैश मेमोरी में सेव किया जाता है. ऐसा करने के लिए, सेवा वर्कर में install इवेंट में कैश स्टोरेज इंटरफ़ेस का इस्तेमाल किया जा सकता है.

सेवा वर्कर थ्रेड को कभी भी बंद किया जा सकता है. इसलिए, ब्राउज़र से addAll प्रॉमिस के पूरा होने का इंतज़ार करने का अनुरोध किया जा सकता है. इससे सभी एसेट को स्टोर करने और ऐप्लिकेशन को एक जैसा रखने की संभावना बढ़ जाती है. नीचे दिए गए उदाहरण में, ऐसा करने का तरीका बताया गया है. इसके लिए, service worker इवेंट लिसनर में मिले इवेंट आर्ग्युमेंट के waitUntil तरीके का इस्तेमाल किया गया है.

const urlsToCache = ["/", "app.js", "styles.css", "logo.svg"];
self.addEventListener("install", event => {
   event.waitUntil(
      caches.open("pwa-assets")
      .then(cache => {
         return cache.addAll(urlsToCache);
      });
   );
});

waitUntil() तरीके में एक प्रॉमिस मिलता है. साथ ही, ब्राउज़र से कहा जाता है कि वह सेवा वर्कर प्रोसेस को खत्म करने से पहले, प्रॉमिस में दिए गए टास्क के पूरा होने (पूरा हो गया या पूरा नहीं हो सका) का इंतज़ार करे. आपको चेन में प्रॉमिस जोड़ने और add() या addAll() कॉल को रिटर्न करने की ज़रूरत पड़ सकती है, ताकि waitUntil() तरीके को एक नतीजा मिल सके.

async/await सिंटैक्स का इस्तेमाल करके भी प्रॉमिस मैनेज किए जा सकते हैं. ऐसे में, आपको एक ऐसा असाइनिश्नल फ़ंक्शन बनाना होगा जो await को कॉल कर सके और कॉल करने के बाद waitUntil() को एक प्रॉमिस दिखा सके. उदाहरण के लिए:

const urlsToCache = ["/", "app.js", "styles.css", "logo.svg"];
self.addEventListener("install", (event) => {
   let cacheUrls = async () => {
      const cache = await caches.open("pwa-assets");
      return cache.addAll(urlsToCache);
   };
   event.waitUntil(cacheUrls());
});

क्रॉस-डोमेन अनुरोध और अस्पष्ट जवाब

आपका PWA, आपके ऑरिजिन और क्रॉस-डोमेन से एसेट डाउनलोड और कैश मेमोरी में सेव कर सकता है. जैसे, तीसरे पक्ष के सीडीएन से कॉन्टेंट. क्रॉस-डोमेन ऐप्लिकेशन के साथ, कैश इंटरैक्शन एक ही ऑरिजिन के अनुरोधों से काफ़ी मिलता-जुलता है. अनुरोध पूरा हो जाता है और जवाब की कॉपी आपके कैश मेमोरी में सेव हो जाती है. कैश मेमोरी में सेव की गई अन्य ऐसेट की तरह ही, इसका इस्तेमाल सिर्फ़ आपके ऐप्लिकेशन के ऑरिजिन में किया जा सकता है.

एसेट को ओपेक रिस्पॉन्स के तौर पर सेव किया जाएगा. इसका मतलब है कि आपका कोड उस रिस्पॉन्स के कॉन्टेंट या हेडर को नहीं देख पाएगा और न ही उनमें बदलाव कर पाएगा. साथ ही, एपीआई से मिले जवाबों का असल साइज़, स्टोरेज एपीआई में नहीं दिखता. इससे कोटा पर असर पड़ता है. कुछ ब्राउज़र, फ़ाइल के साइज़ को 7 एमबी के तौर पर दिखाते हैं. भले ही, फ़ाइल का साइज़ सिर्फ़ 1 केबी हो.

चेतावनी: याद रखें कि क्रॉस-डोमेन से मिले ओपेक रिस्पॉन्स को कैश मेमोरी में सेव करने पर, cache.add() और cache.addAll() काम नहीं करेंगे. ऐसा तब होगा, जब वे रिस्पॉन्स 2xx स्टेटस कोड के साथ न दिखें. इसलिए, अगर कोई सीडीएन या क्रॉस-डोमेन काम नहीं करता है, तो डाउनलोड की जा रही सभी ऐसेट को खारिज कर दिया जाएगा. भले ही, उसी ऑपरेशन में कुछ ऐसेट डाउनलोड हो गई हों.

एसेट अपडेट करना और मिटाना

cache.put(request, response) का इस्तेमाल करके ऐसेट अपडेट की जा सकती हैं और delete(request) का इस्तेमाल करके ऐसेट मिटाई जा सकती हैं.

चेतावनी: अगर आपने अपने सर्वर पर एसेट में बदलाव किया है, तो कैश स्टोरेज एपीआई उन्हें अपडेट नहीं करता. इसके अलावा, वह उन्हें मिटाता भी नहीं है. आपका कोड दोनों स्थितियों को मैनेज कर सकता है. इसके लिए, अलग-अलग डिज़ाइन पैटर्न उपलब्ध हैं. Workbox चैप्टर में, आपको ऐसी लाइब्रेरी के बारे में जानकारी मिलेगी जो इन स्थितियों में मदद कर सकती है.

ज़्यादा जानकारी के लिए, कैश मेमोरी में सेव किए गए ऑब्जेक्ट का दस्तावेज़ देखें.

कैश मेमोरी स्टोरेज को डीबग करना

कई ब्राउज़र, अपने DevTools ऐप्लिकेशन टैब में कैश स्टोरेज के कॉन्टेंट को डीबग करने का तरीका देते हैं. यहां, मौजूदा ऑरिजिन में हर कैश मेमोरी का कॉन्टेंट देखा जा सकता है. हम टूल और डीबग करने के बारे में जानकारी देने वाले चैप्टर में, इन टूल के बारे में ज़्यादा जानकारी देंगे.

Chrome DevTools में कैश स्टोरेज के कॉन्टेंट को डीबग किया जा रहा है.