रनटाइम कैश मेमोरी का मतलब है, "आपके इस्तेमाल के हिसाब से" कैश मेमोरी में धीरे-धीरे जवाब जोड़ना. हालांकि, रनटाइम को कैश मेमोरी में सेव करने से, मौजूदा अनुरोध की विश्वसनीयता कम नहीं होती, लेकिन इससे किसी यूआरएल के लिए आने वाले समय में किए जाने वाले अनुरोधों को ज़्यादा भरोसेमंद बनाया जा सकता है.
ब्राउज़र की एचटीटीपी कैश मेमोरी, रनटाइम के दौरान कैश मेमोरी में सेव करने का एक उदाहरण है. इसे किसी यूआरएल के लिए अनुरोध करने के बाद ही भरा जाता है. हालांकि, सर्विस वर्कर आपको रनटाइम कैश मेमोरी में सेव करने की सुविधा लागू करने की सुविधा देते हैं. यह कैश मेमोरी, एचटीटीपी कैश की सुविधा से भी ज़्यादा काम करती है.
रणनीति बनाना
पहले से कैश मेमोरी में सेव करने (जो हमेशा कैश मेमोरी से, पहले से तय फ़ाइलों के सेट को दिखाने की कोशिश करता है) के उलट, रनटाइम कैश मेमोरी में नेटवर्क और कैश ऐक्सेस को कई तरीकों से जोड़ा जा सकता है. आम तौर पर, हर कॉम्बिनेशन को कैश मेमोरी में सेव करने की रणनीति कहा जाता है. कैश मेमोरी में सेव करने की मुख्य रणनीतियों में ये शामिल हैं:
- नेटवर्क-फ़र्स्ट
- कैश-फ़र्स्ट
- पुरानी-पुष्टि के दौरान
नेटवर्क-फ़र्स्ट
इस तरीके में, आपका सर्विस वर्कर पहले नेटवर्क से रिस्पॉन्स पाने की कोशिश करता है. अगर नेटवर्क अनुरोध पूरा हो जाता है, तो अच्छी बात है! रिस्पॉन्स को आपके वेब ऐप्लिकेशन पर वापस भेजा जाता है और रिस्पॉन्स की एक कॉपी, कैश स्टोरेज एपीआई का इस्तेमाल करके सेव की जाती है. इस कॉपी में या तो नई एंट्री बनाई जाती है या उसी यूआरएल के लिए पिछली एंट्री अपडेट की जाती है.
अगर नेटवर्क अनुरोध पूरी तरह से काम नहीं करता है या जवाब देने में ज़्यादा समय लगता है, तो कैश मेमोरी से सबसे हाल का रिस्पॉन्स दिखाया जाता है.
कैश-फ़र्स्ट
कैश-फ़र्स्ट रणनीति, नेटवर्क-फ़र्स्ट रणनीति से बिलकुल उलट होती है. इस तरीके में, जब आपका सर्विस वर्कर किसी अनुरोध को रोकता है, तो यह पहले कैश मेमोरी एपीआई का इस्तेमाल करके यह पता लगाता है कि कैश मेमोरी में सेव किया गया कोई रिस्पॉन्स उपलब्ध है या नहीं. अगर ऐसा है, तो वेब ऐप्लिकेशन को रिस्पॉन्स वापस आ जाता है.
हालांकि, अगर कैश मिस होता है, तो सर्विस वर्कर नेटवर्क पर जाएगा और वहां रिस्पॉन्स पाने की कोशिश करेगा. यह मानते हुए कि नेटवर्क अनुरोध पूरा हो गया है, उसे आपके वेब ऐप्लिकेशन पर वापस भेज दिया जाता है और उसकी एक कॉपी कैश में सेव कर ली जाती है. अगली बार उसी यूआरएल का अनुरोध करने पर, नेटवर्क को बायपास करने के लिए, कैश मेमोरी में सेव की गई इस कॉपी का इस्तेमाल किया जाएगा.
पुरानी-पुष्टि के दौरान
पुरानी और फिर से पुष्टि करने की प्रक्रिया एक हाइब्रिड मॉडल है. इसका इस्तेमाल करते समय, आपका सर्विस वर्कर तुरंत कैश मेमोरी में सेव किए गए रिस्पॉन्स की जांच करेगा और अगर कोई रिस्पॉन्स मिलता है, तो उसे आपके वेब ऐप्लिकेशन पर वापस भेज दिया जाता है.
इस बीच, भले ही कोई कैश मैच हुआ हो या नहीं, आपका सर्विस वर्कर भी "नया" जवाब पाने के लिए नेटवर्क अनुरोध को ट्रिगर करता है. इस रिस्पॉन्स का इस्तेमाल, पहले से कैश मेमोरी में सेव किए गए किसी पुराने रिस्पॉन्स को अपडेट करने के लिए किया जाता है. अगर शुरुआती कैश मेमोरी की जांच नहीं की गई है, तो नेटवर्क रिस्पॉन्स की एक कॉपी आपके वेब ऐप्लिकेशन को भी भेज दी जाएगी.
आपको Workbox का इस्तेमाल क्यों करना चाहिए?
कैश मेमोरी में सेव करने की इन रणनीतियों में, ऐसी रेसिपी शामिल होती हैं जिन्हें आम तौर पर, आपको अपने सर्विस वर्कर में बार-बार लिखना पड़ता है. इसके बजाय, Workbox को अपनी रणनीति लाइब्रेरी के हिस्से के तौर पर पैकेज के तौर पर उपलब्ध कराया जाता है, ताकि आप अपने सर्विस वर्कर के तौर पर काम करने के लिए तैयार हों.
वर्कबॉक्स, वर्शन के लिए भी सहायता उपलब्ध कराता है. इससे, कैश मेमोरी में सेव की गई एंट्री को अपने-आप खत्म किया जा सकता है. इसके अलावा, कैश मेमोरी में सेव की गई पिछली एंट्री के अपडेट होने पर, वेब ऐप्लिकेशन को सूचना दी जा सकती है.
आपको किन रणनीतियों की मदद से अपनी किन ऐसेट को कैश मेमोरी में सेव करना चाहिए?
रनटाइम कैशिंग को प्रीकैशिंग के एक पूरक के रूप में देखा जा सकता है. अगर आपकी सभी एसेट पहले से ही पहले से कैश मेमोरी में सेव की जा रही हैं, तो इसका मतलब है कि आपका काम हो गया है. रनटाइम के दौरान, कैश मेमोरी में कैश मेमोरी में सेव करने की ज़रूरत नहीं है. हालांकि, हो सकता है कि किसी कॉम्प्लेक्स वेब ऐप्लिकेशन के लिए आपने सब कुछ पहले से इकट्ठा न किया हो.
बड़ी मीडिया फ़ाइलें, ऐसी ऐसेट जिन्हें सीडीएन या एपीआई से मिले रिस्पॉन्स जैसे तीसरे पक्ष के होस्ट से दिखाया जाता है, ऐसी एसेट के कुछ उदाहरण हैं जिन्हें सही तरीके से पहले से कैश मेमोरी में सेव नहीं किया जा सकता. इस कैटगरी में आने वाले अनुरोधों की पहचान करने के लिए, DevTools में नेटवर्क पैनल का इस्तेमाल करें. हर अनुरोध के लिए, इस बारे में सोचें कि नयापन और भरोसेमंद होने के बीच क्या फ़र्क़ है.
ताज़गी के बजाय विश्वसनीयता को प्राथमिकता देने के लिए, 'फिर से पुष्टि करने के दौरान पुरानी जानकारी' का इस्तेमाल करें
'फिर से पुष्टि करें' के दौरान पुरानी रणनीति, पहले अनुरोध से कैश मेमोरी में जानकारी भरे जाने के तुरंत बाद कैश मेमोरी में सेव किया गया रिस्पॉन्स दिखाती है. इस रणनीति का इस्तेमाल करने पर, आपको तेज़ी से परफ़ॉर्मेंस मिलेगी. इसके लिए, रिस्पॉन्स डेटा को वापस पाने के मुकाबले यह डेटा पुराने हो सकते हैं. यह रणनीति उपयोगकर्ता की प्रोफ़ाइल इमेज या किसी व्यू को पॉप्युलेट करने के लिए इस्तेमाल किए गए शुरुआती एपीआई रिस्पॉन्स जैसी एसेट के लिए सबसे अच्छी तरह तब काम करती है, जब आपको पता हो कि किसी चीज़ को तुरंत दिखाना अहम है, भले ही वह पुरानी वैल्यू क्यों न हो.
भरोसेमंद के बजाय फ़्रेशनेस को प्राथमिकता देने के लिए, नेटवर्क-फ़र्स्ट का इस्तेमाल करें
कई मायनों में, नेटवर्क को प्राथमिकता देने वाली रणनीति का इस्तेमाल करना यह स्वीकार करता है कि नेटवर्क के ख़िलाफ़ आपकी लड़ाई में हार हुई है. इसे प्राथमिकता दी जाती है, लेकिन इससे भरोसे को लेकर अनिश्चितता होती है. कुछ खास तरह की एसेट के लिए पुरानी जानकारी वापस पाने के लिए, नई जानकारी देखना बेहतर होता है. हो सकता है कि बार-बार अपडेट किए जाने वाले लेख के टेक्स्ट के लिए, एपीआई अनुरोध करते समय आपको नया अनुरोध करना पड़े.
किसी सर्विस वर्कर के अंदर नेटवर्क-फ़र्स्ट रणनीति का इस्तेमाल करने से, सीधे नेटवर्क के ख़िलाफ़ जाने के बजाय, आपको किसी चीज़ पर वापस जाने का फ़ायदा मिलता है. भले ही, यह जवाब पुराना हो. आप तेज़ी से नहीं रुकेंगे, लेकिन ऑफ़लाइन रहते हुए भी आप भरोसेमंद बने रहेंगे.
वर्शन वाले यूआरएल के लिए कैश-फ़र्स्ट का इस्तेमाल करें
कैश-फ़र्स्ट रणनीति में, किसी एंट्री को कैश मेमोरी में सेव करने के बाद, उसे कभी अपडेट नहीं किया जाता. इस वजह से, पक्का करें कि इसका इस्तेमाल सिर्फ़ उन ऐसेट के साथ किया जाए जिनमें बदलाव किया जा सकता है. खास तौर पर, यह सुविधा उन यूआरएल के लिए सबसे अच्छी तरह काम करती है जिनमें वर्शन की जानकारी होती है. यह उसी तरह के यूआरएल होता है जिन्हें Cache-Control: max-age=31536000 रिस्पॉन्स हेडर के साथ भी दिखाया जाना चाहिए.