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