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

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 के लिए सीडीएन भी शामिल है) कॉन्टेंट को कैश कर सकते हैं.

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

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

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

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

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

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