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

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

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

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

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

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

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 के लिए, उनके मानों को उस सबसे लंबे समय तक सेट करें जब तक आप उपयोगकर्ताओं को पुरानी सामग्री प्राप्त करने में सहज महसूस करते हैं। यदि कोई पृष्ठ हर कुछ सेकंड में बदलता है, तो छोटे समय मान का उपयोग करें। हालाँकि, अन्य प्रकार की सामग्री को घंटों, दिनों या महीनों के लिए सुरक्षित रूप से संचित किया जा सकता है।

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