फिर से पुष्टि करने के दौरान पुरानी जानकारी को अपडेट करना

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

Jeff Posnick

क्या शिप किया गया?

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 को दो हिस्सों में बांटते हैं: पहला, कैश मेमोरी में सेव किया गया रिस्पॉन्स पुराना हो सकता है और दूसरा, फिर से पुष्टि करने की प्रोसेस.

सबसे पहले, ब्राउज़र को कैसे पता चलता है कि कैश मेमोरी में सेव किया गया रिस्पॉन्स "पुराना" है? Cache-Control रिस्पॉन्स हेडर में stale-while-revalidate के साथ-साथ 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 हेडर के ज़रिए stale-while-revalidate का इस्तेमाल करना, सर्विस वर्कर में इसके इस्तेमाल से काफ़ी मिलता-जुलता है. साथ ही, कॉन्टेंट के ताज़ा होने और उसकी ज़्यादा से ज़्यादा समयसीमा के बारे में कई बातें लागू होती हैं. हालांकि, सर्विस वर्कर पर आधारित तरीका लागू करना है या सिर्फ़ Cache-Control हेडर कॉन्फ़िगरेशन पर भरोसा करना है, यह तय करते समय आपको कुछ बातों का ध्यान रखना चाहिए.

सर्विस वर्कर का इस्तेमाल तब करें, जब…

  • आपके वेब ऐप्लिकेशन में पहले से ही सर्विस वर्कर का इस्तेमाल किया जा रहा है.
  • आपको अपने कैश मेमोरी के कॉन्टेंट पर बारीकी से कंट्रोल चाहिए और आपको हाल ही में इस्तेमाल की गई समयसीमा खत्म होने की नीति जैसी कोई चीज़ लागू करनी है. Workbox का Cache Expiration मॉड्यूल इसमें मदद कर सकता है.
  • आपको यह सूचना चाहिए कि फिर से पुष्टि करने के दौरान, बैकग्राउंड में पुराना रिस्पॉन्स कब बदला. Workbox का Broadcast Cache Update मॉड्यूल इसमें मदद कर सकता है.
  • आपको सभी मॉडर्न ब्राउज़र में इस stale-while-revalidate व्यवहार की ज़रूरत है.

Cache-Control का इस्तेमाल तब करें, जब…

  • आपको अपने वेब ऐप्लिकेशन के लिए, सर्विस वर्कर को डिप्लॉय और मैनेज करने की ज़िम्मेदारी नहीं लेनी है.
  • आपको ब्राउज़र के अपने-आप कैश मेमोरी मैनेज करने की सुविधा से कोई समस्या नहीं है. इससे, आपके डिवाइस की कैश मेमोरी को बहुत ज़्यादा भरने से रोका जा सकता है.
  • आपको ऐसे तरीके से कोई समस्या नहीं है जो फ़िलहाल सभी मॉडर्न ब्राउज़र पर काम नहीं करता (जुलाई 2019 तक; आने वाले समय में यह सुविधा ज़्यादा ब्राउज़र पर काम कर सकती है).

अगर किसी सर्विस वर्कर का इस्तेमाल किया जा रहा है और Cache-Control हेडर की मदद से कुछ जवाबों के लिए stale-while-revalidate को भी चालू किया गया है, तो आम तौर पर सर्विस वर्कर को किसी अनुरोध का जवाब देने का "पहला मौका" मिलेगा. अगर सर्विस वर्कर जवाब न देने का फ़ैसला लेता है या जवाब जनरेट करने की प्रोसेस के दौरान, fetch() का इस्तेमाल करके नेटवर्क का अनुरोध करता है, तो Cache-Control हेडर के ज़रिए कॉन्फ़िगर किया गया व्यवहार लागू हो जाएगा.

ज़्यादा जानें