संचय कर रहा है

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

ब्राउज़र सहायता

अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है
अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है
अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है
अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है

सोर्स

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

कैश मेमोरी एपीआई अलग-अलग कॉन्टेक्स्ट में उपलब्ध है:

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

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

क्या कैश करना है

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

इन संसाधनों में यह जानकारी शामिल होनी चाहिए:

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

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

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

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

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

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

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

अपने ऑरिजिन में कैश मेमोरी का एक सेट तय करने के लिए, कैश स्टोरेज एपीआई का इस्तेमाल करें. इसमें हर एक के लिए एक स्ट्रिंग नाम दिया जाता है, जिसे तय किया जा सकता है. caches ऑब्जेक्ट से एपीआई को ऐक्सेस करें. इसके बाद, 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(), दोनों बिना किसी आर्ग्युमेंट के प्रॉमिस प्रॉमिस देते हैं; फ़ाइलों को डाउनलोड और कैश मेमोरी में सेव किया जाता है, तो आपको पता चल जाएगा कि एसेट डाउनलोड और कैश मेमोरी में सेव की गई थीं. अगर ऐसा नहीं होता है, तो एपीआई एक या एक से ज़्यादा रिसॉर्स को डाउनलोड नहीं कर पाएगा. साथ ही, यह कैश मेमोरी में बदलाव नहीं करेगा.

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

कैश मेमोरी कब सेव करें

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

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

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

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

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

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

सर्विस वर्कर थ्रेड को किसी भी समय बंद किया जा सकता है. इसलिए, ब्राउज़र को addAll प्रॉमिस पूरा होने तक इंतज़ार करने का अनुरोध करें, ताकि सभी ऐसेट को सेव करने और ऐप्लिकेशन को एक जैसा बनाए रखने की संभावना बढ़ सके. नीचे दिए गए उदाहरण में, सर्विस वर्कर इवेंट लिसनर में मिले इवेंट आर्ग्युमेंट के 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() तरीके से एक ही नतीजा मिल सकता है.

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

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

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

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

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

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

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

कैश मेमोरी को डीबग करना

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

Chrome DevTools की मदद से कैश स्टोरेज के कॉन्टेंट को डीबग करने की सुविधा.