फायरबेस होस्टिंग आपकी साइट को यथासंभव तेज़ बनाने के लिए एक शक्तिशाली वैश्विक सीडीएन का उपयोग करती है।
कोई भी अनुरोधित स्थिर सामग्री स्वचालित रूप से सीडीएन पर कैश हो जाती है । यदि आप अपनी साइट की सामग्री को फिर से तैनात करते हैं, तो फायरबेस होस्टिंग अगले अनुरोध तक सीडीएन में आपकी सभी कैश्ड स्थिर सामग्री को स्वचालित रूप से साफ़ कर देती है।
हालाँकि, क्योंकि क्लाउड फ़ंक्शंस और क्लाउड रन सेवाएँ गतिशील रूप से सामग्री उत्पन्न करती हैं, किसी दिए गए URL की सामग्री उपयोगकर्ता इनपुट या उपयोगकर्ता की पहचान जैसी चीज़ों के आधार पर भिन्न हो सकती है। इसे ध्यान में रखते हुए, बैकएंड कोड द्वारा संभाले जाने वाले अनुरोध डिफ़ॉल्ट रूप से सीडीएन पर कैश नहीं होते हैं, उन अनुरोधों के अपवाद के साथ जो 404 त्रुटियां लौटाते हैं। कैश्ड 404 परिणामों को साफ़ करने के लिए, फायरबेस होस्टिंग को पुनः तैनात करें; क्लाउड फ़ंक्शंस और क्लाउड रन को फिर से तैनात करने से कैश स्वचालित रूप से अमान्य नहीं होता है।
हालाँकि, आप गतिशील सामग्री के लिए कैशिंग व्यवहार को कॉन्फ़िगर कर सकते हैं। उदाहरण के लिए, यदि कोई फ़ंक्शन केवल समय-समय पर नई सामग्री उत्पन्न करता है, तो आप कम से कम समय के लिए जेनरेट की गई सामग्री को कैश करके अपने ऐप को तेज़ कर सकते हैं।
आप संभावित रूप से फ़ंक्शन निष्पादन लागत को भी कम कर सकते हैं क्योंकि सामग्री ट्रिगर किए गए फ़ंक्शन के बजाय सीडीएन से परोसी जाती है। क्लाउड फ़ंक्शंस और क्लाउड रन दस्तावेज़ में फ़ंक्शन निष्पादन और सेवाओं को अनुकूलित करने के बारे में और पढ़ें।
Google के वेब डेवलपर दस्तावेज़ में कैशिंग व्यवहार के बारे में और जानें।
कैश-कंट्रोल सेट करें
गतिशील सामग्री के लिए कैश को प्रबंधित करने के लिए आप जिस मुख्य उपकरण का उपयोग करते हैं वह Cache-Control
हेडर है। इस हेडर को कॉन्फ़िगर करके, आप ब्राउज़र और सीडीएन दोनों को बता सकते हैं कि आपकी सामग्री को कितने समय तक कैश किया जा सकता है। अपने फ़ंक्शन में, आप Cache-Control
इस प्रकार सेट करते हैं:
res.set('Cache-Control', 'public, max-age=300, s-maxage=600');
इस उदाहरण शीर्षलेख में, निर्देश तीन कार्य करते हैं:
public
- कैश कोpublic
के रूप में चिह्नित करता है। इसका मतलब यह है कि ब्राउज़र और मध्यवर्ती सर्वर (अर्थात् फायरबेस होस्टिंग के लिए सीडीएन) दोनों सामग्री को कैश कर सकते हैं।max-age
- ब्राउज़र और सीडीएन को बताता है कि वे कितने सेकंड में सामग्री को कैश कर सकते हैं। जब निर्धारित समय समाप्त हो जाता है, तो ब्राउज़र और सीडीएन को मूल सर्वर के साथ सामग्री को पुनः सत्यापित करना होगा। उदाहरण शीर्षलेख में, हम ब्राउज़र और सीडीएन को सामग्री को पांच मिनट तक कैश करने की अनुमति दे रहे हैं (सीडीएन कैशिंग के लिए विशिष्ट नियंत्रणों के लिए नीचेs-maxage
देखें)।s-maxage
- केवल सीडीएन-कैशिंग के लिएmax-age
निर्देश को ओवरराइड करता है; सीडीएन को बताता है कि वह कितने सेकंड में सामग्री को कैश कर सकता है। जब निर्धारित समय समाप्त हो जाता है, तो सीडीएन को मूल सर्वर के साथ सामग्री को पुनः सत्यापित करना होगा। उदाहरण शीर्षलेख में, हम केवल सीडीएन के लिएmax-age
की सेटिंग को ओवरराइड कर रहे हैं और सीडीएन को सामग्री को दस मिनट तक कैश करने की अनुमति दे रहे हैं।
max-age
और s-maxage
के लिए, उनके मानों को उस लंबे समय तक सेट करें जिससे आप उपयोगकर्ताओं को पुरानी सामग्री प्राप्त करने में सहज हों। यदि कोई पृष्ठ हर कुछ सेकंड में बदलता है, तो एक छोटे समय मान का उपयोग करें। हालाँकि, अन्य प्रकार की सामग्री को घंटों, दिनों या महीनों तक सुरक्षित रूप से कैश किया जा सकता है।
आप मोज़िला डेवलपर नेटवर्क और 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
कुकी का उपयोग केवल तभी करें जब आपका ऐप उपयोगकर्ता प्राधिकरण के आधार पर भिन्न सामग्री प्रस्तुत करता हो।