कैश मेमोरी में सेव की जाने वाली गतिविधियां मैनेज करें

Firebase Hosting, आपकी साइट को ज़्यादा से ज़्यादा तेज़ बनाने के लिए, एक बेहतरीन ग्लोबल सीडीएन का इस्तेमाल करता है.

अनुरोध किया गया कोई भी स्टैटिक कॉन्टेंट, सीडीएन पर अपने-आप कैश मेमोरी में सेव हो जाता है. अगर अपनी साइट का कॉन्टेंट फिर से डिप्लॉय किया जाता है, तो अगले अनुरोध तक Firebase Hosting, CDN पर कैश मेमोरी में सेव किया गया सारा कॉन्टेंट अपने-आप मिटा देता है.

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

हालांकि, डाइनैमिक कॉन्टेंट के लिए कैश मेमोरी का इस्तेमाल करने का तरीका कॉन्फ़िगर किया जा सकता है. उदाहरण के लिए, अगर कोई फ़ंक्शन सिर्फ़ समय-समय पर नया कॉन्टेंट जनरेट करता है, तो जनरेट किए गए कॉन्टेंट को कम से कम कुछ समय के लिए कैश मेमोरी में सेव करके, अपने ऐप्लिकेशन को तेज़ किया जा सकता है.

फ़ंक्शन को ट्रिगर करने की लागत को कम करने के लिए, कैश मेमोरी के व्यवहार को इसी तरह कॉन्फ़िगर किया जा सकता है. ऐसा इसलिए, क्योंकि कॉन्टेंट को ट्रिगर किए गए फ़ंक्शन के बजाय सीडीएन से दिखाया जाता है. फ़ंक्शन के लागू होने और सेवाओं को ऑप्टिमाइज़ करने के बारे में ज़्यादा जानने के लिए, Cloud Functions और Cloud Run दस्तावेज़ पढ़ें.

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

अगर 404 रिस्पॉन्स में पहले से ही आपकी Cloud Functions या Cloud Run सेवा से सेट किए गए कैश मेमोरी हेडर मौजूद हैं, तो वे 10 मिनट के डिफ़ॉल्ट समय को बदल देते हैं. साथ ही, सीडीएन के कैश मेमोरी के व्यवहार को पूरी तरह से तय करते हैं.

कैश मेमोरी के व्यवहार के बारे में ज़्यादा जानने के लिए, Google के वेब डेवलपर के लिए दस्तावेज़ देखें.

Cache-Control सेट करना

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

res.set('Cache-Control', 'public, max-age=300, s-maxage=600');

इस उदाहरण के हेडर में, डायरेक्टिव तीन काम करते हैं:

  • public — कैश मेमोरी को public के तौर पर मार्क करता है. इसका मतलब है कि ब्राउज़र और इंटरमीडियरी सर्वर (Firebase Hosting के लिए सीडीएन) दोनों, कॉन्टेंट को कैश मेमोरी में सेव कर सकते हैं.

  • max-age — इससे ब्राउज़र और सीडीएन को पता चलता है कि वे कॉन्टेंट को कितने सेकंड तक कैश मेमोरी में सेव कर सकते हैं. तय समय खत्म होने पर, ब्राउज़र और सीडीएन को ऑरिजिन सर्वर से कॉन्टेंट की फिर से पुष्टि करनी होगी. उदाहरण के तौर पर दिए गए हेडर में, हम ब्राउज़र और सीडीएन को कॉन्टेंट को पांच मिनट के लिए कैश मेमोरी में सेव करने की अनुमति दे रहे हैं. सीडीएन को कैश मेमोरी में सेव करने के लिए खास कंट्रोल के बारे में जानने के लिए, यहां s-maxage देखें.

  • s-maxage — सिर्फ़ सीडीएन-कैश मेमोरी के लिए, max-age डायरेक्टिव को बदल देता है. साथ ही, सीडीएन को बताता है कि वह कॉन्टेंट को कितने सेकंड के लिए कैश मेमोरी में सेव कर सकता है. तय समय खत्म होने पर, सीडीएन को ओरिजनल सर्वर से कॉन्टेंट की फिर से पुष्टि करनी होगी. उदाहरण के तौर पर दिए गए हेडर में, हम max-age सिर्फ़ सीडीएन के लिए की सेटिंग को बदल रहे हैं. साथ ही, सीडीएन को कॉन्टेंट को 10 मिनट के लिए कैश मेमोरी में सेव करने की अनुमति दे रहे हैं.

max-age और s-maxage के लिए, उनकी वैल्यू को उस सबसे लंबे समय पर सेट करें जब तक आपको उपयोगकर्ताओं को पुराना कॉन्टेंट दिखाना है. अगर कोई पेज हर कुछ सेकंड में बदलता है, तो समय की छोटी वैल्यू का इस्तेमाल करें. हालांकि, दूसरे तरह के कॉन्टेंट को घंटों, दिनों या महीनों तक सुरक्षित तरीके से कैश मेमोरी में सेव किया जा सकता है.

Cache-Control हेडर के बारे में ज़्यादा जानने के लिए, Mozilla Developer Network और Google के वेब डेवलपर के दस्तावेज़ पर जाएं.

कैश मेमोरी में सेव किया गया कॉन्टेंट कब दिखाया जाता है?

ब्राउज़र और सीडीएन, आपके कॉन्टेंट को इनके आधार पर कैश मेमोरी में सेव करते हैं:

  • होस्टनेम
  • पाथ
  • क्वेरी स्ट्रिंग
  • Vary हेडर में बताए गए अनुरोध हेडर का कॉन्टेंट

अलग-अलग हेडर

Vary हेडर से यह तय होता है कि सही जवाब देने के लिए, किन अनुरोध हेडर का इस्तेमाल किया जाना चाहिए. जैसे, कैश मेमोरी में सेव किया गया कॉन्टेंट मान्य है या नहीं या कॉन्टेंट की पुष्टि, ऑरिजिन सर्वर से फिर से करनी होगी या नहीं.

Firebase Hosting, सामान्य स्थितियों के लिए आपके जवाब पर सही Vary हेडर अपने-आप सेट करता है. ज़्यादातर मामलों में, आपको Vary हेडर के बारे में चिंता करने की ज़रूरत नहीं होती. हालांकि, कुछ बेहतर इस्तेमाल के उदाहरणों में, आपके पास ऐसे अन्य हेडर हो सकते हैं जिनसे आपको कैश मेमोरी पर असर डालना हो. ऐसे में, अपने जवाब में Vary हेडर सेट किया जा सकता है. उदाहरण के लिए:

res.set('Vary', 'Accept-Encoding, X-My-Custom-Header');

इस मामले में, Vary हेडर की वैल्यू यह है:

vary: X-My-Custom-Header, x-fh-requested-host, accept-encoding, cookie, authorization

इन सेटिंग की मदद से, अलग-अलग X-My-Custom-Header हेडर वाले दो एक जैसे अनुरोधों को अलग-अलग कैश मेमोरी में सेव किया जाता है. ध्यान दें कि डाइनैमिक कॉन्टेंट के लिए अनुरोध किए जाने पर, Hosting डिफ़ॉल्ट रूप से Vary हेडर में Cookie और Authorization जोड़ता है. इससे यह पक्का होता है कि आपके इस्तेमाल किए गए किसी भी सेशन या कुकी अनुमति वाले हेडर को कैश मेमोरी कुंजी का हिस्सा बनाया गया है. इससे, कॉन्टेंट के अनचाहे तौर पर लीक होने से रोका जा सकता है.

यह भी ध्यान दें:

  • सिर्फ़ GET और HEAD अनुरोधों को कैश मेमोरी में सेव किया जा सकता है. अन्य तरीकों का इस्तेमाल करके किए गए एचटीटीपीएस अनुरोध कभी कैश मेमोरी में सेव नहीं किए जाते.

  • Vary हेडर में सेटिंग जोड़ते समय सावधानी बरतें. जितनी ज़्यादा सेटिंग जोड़ी जाती हैं, उतनी ही कम संभावना होती है कि सीडीएन, कैश मेमोरी में सेव किया गया कॉन्टेंट दिखा पाए. यह भी याद रखें कि Vary, रिस्पॉन्स हेडर के बजाय अनुरोध हेडर पर आधारित होता है.

कुकी का इस्तेमाल करना

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

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