कैश व्यवहार प्रबंधित करें

फायरबेस होस्टिंग आपकी साइट को जितनी जल्दी हो सके बनाने के लिए एक शक्तिशाली वैश्विक सीडीएन का उपयोग करता है।

किसी भी अनुरोधित स्थिर सामग्री को सीडीएन पर स्वचालित रूप से कैश किया जाता है । यदि आप अपनी साइट की सामग्री को पुन: नियोजित करते हैं, तो फायरबेस होस्टिंग अगले अनुरोध तक सीडीएन में आपकी सभी कैश्ड स्थिर सामग्री को स्वचालित रूप से साफ़ कर देती है।

हालाँकि, क्योंकि क्लाउड फ़ंक्शंस और क्लाउड रन सेवाएँ गतिशील रूप से सामग्री उत्पन्न करती हैं, किसी दिए गए URL की सामग्री उपयोगकर्ता इनपुट या उपयोगकर्ता की पहचान जैसी चीज़ों के आधार पर भिन्न हो सकती है। इसका हिसाब देने के लिए, बैकएंड कोड द्वारा हैंडल किए जाने वाले अनुरोध सीडीएन पर डिफ़ॉल्ट रूप से कैश नहीं होते हैं।

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

आप फ़ंक्शन निष्पादन लागत को संभावित रूप से कम भी कर सकते हैं क्योंकि सामग्री को ट्रिगर किए गए फ़ंक्शन के बजाय सीडीएन से परोसा जाता है। क्लाउड फ़ंक्शंस और क्लाउड रन दस्तावेज़ में फ़ंक्शन निष्पादन और सेवाओं को अनुकूलित करने के बारे में और पढ़ें।

Google के वेब डेवलपर दस्तावेज़ में कैशिंग व्यवहार के बारे में अधिक जानें।

कैश-कंट्रोल सेट करें

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

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

इस उदाहरण हेडर में, निर्देश तीन चीजें करते हैं:

• public - कैश को public के रूप में चिह्नित करता है। इसका मतलब है कि ब्राउज़र और इंटरमीडिएट सर्वर (अर्थात फायरबेस होस्टिंग के लिए सीडीएन) दोनों सामग्री को कैश कर सकते हैं।

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

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

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

आप Mozilla Developer Network पर और Google के वेब डेवलपर दस्तावेज़ में Cache-Control हेडर के बारे में अधिक जान सकते हैं।

संचित सामग्री कब प्रस्तुत की जाती है?

ब्राउज़र और सीडीएन आपकी सामग्री को निम्न के आधार पर कैश करते हैं:

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

अलग हेडर

Vary हेडर यह निर्धारित करता है कि उचित प्रतिक्रिया प्रदान करने के लिए कौन से अनुरोध शीर्षलेखों का उपयोग किया जाना चाहिए (चाहे कैश की गई सामग्री मान्य है या सामग्री को मूल सर्वर के साथ पुन: सत्यापित किया जाना चाहिए)।

फायरबेस होस्टिंग सामान्य परिस्थितियों के लिए आपकी प्रतिक्रिया पर स्वचालित रूप से एक उपयुक्त 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 हेडर वाले दो अन्यथा समान अनुरोध अलग-अलग कैश किए जाते हैं। ध्यान दें कि जब गतिशील सामग्री के लिए अनुरोध किया जाता है तो होस्टिंग डिफ़ॉल्ट रूप से Vary हेडर में Cookie और Authorization जोड़ता है। यह सुनिश्चित करता है कि आपके द्वारा उपयोग किया जाने वाला कोई भी सत्र या कुकी प्राधिकरण शीर्षलेख कैश कुंजी का हिस्सा बना दिया गया है, जो सामग्री के आकस्मिक रिसाव को रोकता है।

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

• केवल GET और HEAD अनुरोधों को कैश किया जा सकता है। अन्य विधियों का उपयोग करने वाले HTTPS अनुरोधों को कभी भी कैश नहीं किया जाता है।

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

कुकीज़ का उपयोग करना

क्लाउड फ़ंक्शंस या क्लाउड रन के साथ फ़ायरबेस होस्टिंग का उपयोग करते समय, कुकीज़ को आम तौर पर आने वाले अनुरोधों से हटा दिया जाता है। कुशल सीडीएन कैश व्यवहार की अनुमति देने के लिए यह आवश्यक है। आपके ऐप के निष्पादन के लिए केवल विशेष रूप से नामित __session कुकी को पास करने की अनुमति है।

मौजूद होने पर, __session कुकी स्वचालित रूप से कैश कुंजी का एक हिस्सा बन जाती है, जिसका अर्थ है कि अलग-अलग कुकी वाले दो उपयोगकर्ताओं के लिए दूसरे की कैश्ड प्रतिक्रिया प्राप्त करना असंभव है। केवल __session कुकी का उपयोग करें यदि आपका ऐप उपयोगकर्ता प्राधिकरण के आधार पर भिन्न सामग्री परोसता है।