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

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

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

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

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

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

अपवाद वे अनुरोध हैं जो 404 त्रुटियाँ लौटाते हैं। सीडीएन आपकी सेवा की 404 प्रतिक्रिया को 10 मिनट के लिए एक गैर-मौजूद यूआरएल पर कैश कर देता है, ताकि उस यूआरएल के लिए बाद के अनुरोध सीडीएन से बाहर किए जा सकें। यदि आप अपनी सेवा बदलते हैं ताकि सामग्री अब इस यूआरएल पर मौजूद हो, तो सीडीएन किसी भी कैश्ड 404 को 10 मिनट (अधिकतम) के लिए परोसना जारी रखता है, और फिर सामान्य रूप से उस यूआरएल से सामग्री परोसता है।

यदि 404 प्रतिक्रिया में पहले से ही आपके क्लाउड फ़ंक्शंस या क्लाउड रन सेवा द्वारा सेट किए गए कैशिंग हेडर शामिल हैं, तो वे 10 मिनट के डिफ़ॉल्ट को ओवरराइड करते हैं और सीडीएन के कैशिंग व्यवहार को पूरी तरह से निर्धारित करते हैं।

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 कुकी का उपयोग केवल तभी करें जब आपका ऐप उपयोगकर्ता प्राधिकरण के आधार पर भिन्न सामग्री प्रस्तुत करता हो।