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

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

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

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

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

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

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

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

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

Cache-Control सेट करना

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

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

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

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

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

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

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

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

अगर आपको कैश मेमोरी में सेव करने की सुविधा को पूरी तरह से बंद करना है (उदाहरण के लिए, स्टैटिक कॉन्टेंट का हमेशा नया वर्शन दिखाना है), तो firebase.json में जाकर इसे कॉन्फ़िगर किया जा सकता है. इसके लिए, headers सेटिंग का इस्तेमाल करें:

"hosting": {
  // ...

  // Disables caching for the /posts route
  "headers": [ {
    // Change source to match your dynamically-rendered routes
    "source": "/posts/**",
    "headers": [ {
      "key": "Cache-Control",
      "value": "no-cache, no-store"
    } ]
  } ]
}

Cache-Control हेडर के बारे में ज़्यादा जानने के लिए, Mozilla Developer Network पर जाएँ. इसके अलावा, Google के वेब डेवलपर के लिए बनाए गए दस्तावेज़ में भी इसके बारे में जानकारी दी गई है.

कैश किया गया कॉन्टेंट कब दिखाया जाता है?

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

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

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, अनुरोध हेडर पर आधारित होता है, न कि जवाब हेडर पर.

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

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

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