यह एक और टूल है, जिससे आपको अपने वेब ऐप्लिकेशन को तुरंत और अप-टू-डेट उपलब्ध कराने में मदद मिलती है.
क्या शिप किया गया?
stale-while-revalidate
से डेवलपर को, तुरंत कॉन्टेंट उपलब्ध कराने और उसे अप-टू-डेट रखने में मदद मिलती है. तुरंत कॉन्टेंट उपलब्ध कराने का मतलब है कि कैश मेमोरी में सेव किया गया कॉन्टेंट तुरंत लोड हो जाए. अप-टू-डेट रखने का मतलब है कि कैश मेमोरी में सेव किए गए कॉन्टेंट के अपडेट का इस्तेमाल आने वाले समय में किया जा सके. अगर आपके पास तीसरे पक्ष की ऐसी वेब सेवा या लाइब्रेरी है जो नियमित शेड्यूल पर अपडेट होती है या आपकी पहली-पक्ष की ऐसेट का लाइफ़टाइम कम होता है, तो कैश मेमोरी सेव करने की मौजूदा नीतियों में stale-while-revalidate
को जोड़ना फ़ायदेमंद हो सकता है.
Cache-Control
रिस्पॉन्स हेडर में max-age
के साथ-साथ stale-while-revalidate
सेट करने की सुविधा, Chrome 75 और Firefox 68 में उपलब्ध है.
stale-while-revalidate
के साथ काम न करने वाले ब्राउज़र, कॉन्फ़िगरेशन की उस वैल्यू को चुपचाप अनदेखा कर देंगे और max-age
का इस्तेमाल करेंगे. इस बारे में हम आगे बताएंगे…
इसका क्या मतलब है?
stale-while-revalidate
को दो हिस्सों में बांटते हैं: कैश मेमोरी में सेव किए गए रिस्पॉन्स के पुराने होने की संभावना और फिर से पुष्टि करने की प्रोसेस.
सबसे पहले, ब्राउज़र को कैसे पता चलता है कि कैश मेमोरी में सेव किया गया जवाब "पुराना" है या नहीं? stale-while-revalidate
वाले Cache-Control
रिस्पॉन्स हेडर में max-age
भी होना चाहिए. max-age
से तय किए गए सेकंड की संख्या से यह तय होता है कि डेटा पुराना है या नहीं. कैश मेमोरी में सेव किए गए किसी भी ऐसे रिस्पॉन्स को नया माना जाता है जो max-age
से नया हो. साथ ही, कैश मेमोरी में सेव किए गए पुराने रिस्पॉन्स को पुराना माना जाता है.
अगर कैश मेमोरी में सेव किया गया जवाब अब भी अप-टू-डेट है, तो ब्राउज़र के अनुरोध को पूरा करने के लिए, उसका इस्तेमाल किया जा सकता है. stale-while-revalidate
के हिसाब से,
इस स्थिति में कुछ करने की ज़रूरत नहीं है.
हालांकि, अगर कैश मेमोरी में सेव किया गया रिस्पॉन्स पुराना है, तो उम्र के आधार पर एक और जांच की जाती है:
क्या कैश मेमोरी में सेव किए गए रिस्पॉन्स की उम्र, stale-while-revalidate
सेटिंग में दी गई अतिरिक्त समयसीमा के अंदर है?
अगर किसी पुराने रिस्पॉन्स की उम्र इस विंडो में आती है, तो इसका इस्तेमाल ब्राउज़र के अनुरोध को पूरा करने के लिए किया जाएगा. साथ ही, नेटवर्क के लिए "फिर से पुष्टि करने" का अनुरोध इस तरह किया जाएगा कि कैश मेमोरी में सेव किए गए जवाब के इस्तेमाल में देरी न हो. रिटर्न किए गए रिस्पॉन्स में, पहले से कैश मेमोरी में सेव किए गए रिस्पॉन्स जैसी जानकारी हो सकती है या यह जानकारी अलग हो सकती है. दोनों ही मामलों में, नेटवर्क रिस्पॉन्स को स्थानीय तौर पर सेव किया जाता है. इससे, पहले से कैश मेमोरी में सेव किए गए डेटा की जगह नया डेटा सेव हो जाता है. साथ ही, आने वाले समय में max-age
की तुलना के दौरान इस्तेमाल किए जाने वाले "नयापन" टाइमर को रीसेट कर दिया जाता है.
हालांकि, अगर कैश मेमोरी में सेव किया गया पुराना रिस्पॉन्स, stale-while-revalidate
की समयसीमा से बाहर का है, तो वह ब्राउज़र के अनुरोध को पूरा नहीं करेगा. इसके बजाय, ब्राउज़र नेटवर्क से रिस्पॉन्स हासिल करेगा और उसका इस्तेमाल, शुरुआती अनुरोध को पूरा करने के साथ-साथ, लोकल कैश मेमोरी में नए रिस्पॉन्स को भरने के लिए भी करेगा.
लाइव उदाहरण
यहां मौजूदा समय दिखाने वाले एचटीटीपी एपीआई का एक आसान उदाहरण दिया गया है. इसमें, खास तौर पर, घंटे के बाद बचे हुए मिनटों की संख्या दिख रही है.
इस स्थिति में, वेब सर्वर अपने एचटीटीपी रिस्पॉन्स में इस Cache-Control
हेडर का इस्तेमाल करता है:
Cache-Control: max-age=1, stale-while-revalidate=59
इस सेटिंग का मतलब है कि अगर अगले एक सेकंड में समय के लिए अनुरोध दोहराया जाता है, तो पहले से कैश मेमोरी में सेव की गई वैल्यू अब भी अप-टू-डेट होगी और उसका इस्तेमाल, फिर से पुष्टि किए बिना किया जाएगा.
अगर एक से 60 सेकंड के बीच कोई अनुरोध दोहराया जाता है, तो कैश मेमोरी में सेव की गई वैल्यू पुरानी हो जाएगी. हालांकि, इसका इस्तेमाल एपीआई अनुरोध को पूरा करने के लिए किया जाएगा. साथ ही, "बैकग्राउंड में", पुष्टि करने का अनुरोध किया जाएगा, ताकि कैश मेमोरी में आने वाले समय में इस्तेमाल करने के लिए नई वैल्यू भरी जा सके.
अगर किसी अनुरोध को 60 सेकंड से ज़्यादा समय बाद दोहराया जाता है, तो पुराने जवाब का इस्तेमाल बिल्कुल नहीं किया जाता. साथ ही, ब्राउज़र के अनुरोध को पूरा करने और कैश मेमोरी की फिर से पुष्टि करने, दोनों पर नेटवर्क से जवाब मिलने का असर पड़ेगा.
यहां उन तीन अलग-अलग स्थितियों के बारे में बताया गया है. साथ ही, हमारे उदाहरण में, उनमें से हर स्थिति के लागू होने की समयावधि भी दी गई है:
इस्तेमाल के सामान्य उदाहरण क्या हैं?
"घंटे के बाद के मिनट" एपीआई सेवा के लिए ऊपर दिया गया उदाहरण बनावटी है. हालांकि, इससे इस्तेमाल के उदाहरण के बारे में पता चलता है. यह ऐसी सेवाओं के बारे में बताता है जिनमें ऐसी जानकारी दी जाती है जिसे रीफ़्रेश करने की ज़रूरत होती है. हालांकि, इसमें कुछ समय तक पुरानी जानकारी भी स्वीकार की जा सकती है.
कम जानकारी वाले उदाहरणों में, मौसम की मौजूदा स्थिति के लिए एपीआई या पिछले एक घंटे में लिखी गई मुख्य खबरों की हेडलाइन शामिल हो सकती हैं.
आम तौर पर, किसी तय इंटरवल पर अपडेट होने वाले जवाब का अनुरोध कई बार किया जा सकता है. साथ ही, उस इंटरवल के दौरान वह जवाब स्टैटिक रहता है. ऐसे जवाबों को max-age
की मदद से, कुछ समय के लिए कैश मेमोरी में सेव किया जा सकता है. max-age
के साथ-साथ stale-while-revalidate
का इस्तेमाल करने से, आने वाले समय में किए जाने वाले अनुरोधों को कैश मेमोरी में मौजूद नए कॉन्टेंट से पूरा किया जा सकता है. इसके लिए, नेटवर्क के जवाब को ब्लॉक करने की ज़रूरत नहीं होती.
यह सेवा वर्कर्स के साथ कैसे इंटरैक्ट करता है?
अगर आपने stale-while-revalidate
के बारे में सुना है, तो हो सकता है कि यह सेवा वर्कर में इस्तेमाल की गई रेसिपी के संदर्भ में हो.
Cache-Control
हेडर की मदद से, 'अपडेट होने के दौरान भी मान्य' सुविधा का इस्तेमाल करने पर, सेवा वर्कर में इसका इस्तेमाल करने से कुछ मिलता-जुलता अनुभव मिलता है. साथ ही, अपडेट होने के दौरान भी मान्य रहने की सुविधा के साथ-साथ, डेटा के ज़्यादा से ज़्यादा समय तक मान्य रहने की सुविधा के बारे में भी यही बातें लागू होती हैं. हालांकि, सेवा वर्कर पर आधारित तरीके को लागू करने या सिर्फ़ Cache-Control
हेडर कॉन्फ़िगरेशन पर भरोसा करने का फ़ैसला लेते समय, आपको कुछ बातों का ध्यान रखना चाहिए.
अगर…
- आपके वेब ऐप्लिकेशन में पहले से ही सर्विस वर्कर का इस्तेमाल किया जा रहा है.
- आपको अपने कैश मेमोरी में मौजूद कॉन्टेंट पर बेहतर कंट्रोल चाहिए और आपको कम से कम हाल ही में इस्तेमाल किए गए कॉन्टेंट की समयसीमा खत्म होने की नीति जैसी कोई नीति लागू करनी है. Workbox के कैश मेमोरी में डेटा सेव होने की समयसीमा वाले मॉड्यूल से, इस काम में मदद मिल सकती है.
- आपको पुष्टि करने के दौरान, बैकग्राउंड में पुराने जवाब में बदलाव होने पर सूचना चाहिए. Workbox के ब्रॉडकास्ट कैश मेमोरी अपडेट मॉड्यूल से, इस काम में मदद मिल सकती है.
- आपको सभी मॉडर्न ब्राउज़र में,
stale-while-revalidate
के इस व्यवहार की ज़रूरत है.
कैश-कंट्रोल अप्रोच का इस्तेमाल तब करें, जब…
- आपको अपने वेब ऐप्लिकेशन के लिए, सेवा वर्कर को डिप्लॉय और मैनेज करने की ज़रूरत नहीं है.
- आपने ब्राउज़र के कैश मेमोरी को अपने-आप मैनेज करने की सुविधा चालू की है, ताकि आपके लोकल कैश मेमोरी का साइज़ बहुत ज़्यादा न हो.
- आपने ऐसा तरीका चुना है जो फ़िलहाल सभी आधुनिक ब्राउज़र में काम नहीं करता. हालांकि, आने वाले समय में यह तरीका सभी ब्राउज़र में काम कर सकता है.
अगर किसी सेवा वर्कर का इस्तेमाल किया जा रहा है और आपने Cache-Control
हेडर के ज़रिए कुछ रिस्पॉन्स के लिए stale-while-revalidate
चालू किया है, तो आम तौर पर, सेवा वर्कर को अनुरोध का जवाब देने का "पहला मौका" मिलेगा. अगर सेवा वर्कर, रिस्पॉन्स नहीं देता है या रिस्पॉन्स जनरेट करने की प्रोसेस में, fetch()
का इस्तेमाल करके नेटवर्क अनुरोध करता है, तो Cache-Control
हेडर के ज़रिए कॉन्फ़िगर किया गया व्यवहार लागू हो जाएगा.
ज़्यादा जानें
- Fetch API के स्पेसिफ़िकेशन में
stale-while-revalidate
रिस्पॉन्स. - आरएफ़सी 5861, जिसमें शुरुआती
stale-while-revalidate
स्पेसिफ़िकेशन के बारे में बताया गया है. - इस साइट पर मौजूद "नेटवर्क के काम करने के तरीके" गाइड में, एचटीटीपी कैश मेमोरी: आपकी पहली लाइन ऑफ़ डिफ़ेंस लेख पढ़ें.
सैमुअल जेलर की हीरो इमेज.