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

Firebase Hosting आपकी साइट को ज़्यादा से ज़्यादा तेज़ बनाने के लिए, एक असरदार ग्लोबल सीडीएन का इस्तेमाल करता है.

अनुरोध किया गया कोई भी स्टैटिक कॉन्टेंट, सीडीएन पर अपने-आप कैश मेमोरी में सेव हो जाता है. अपनी साइट का कॉन्टेंट फिर से डिप्लॉय करने पर, Firebase Hosting अगले अनुरोध तक सीडीएन पर मौजूद आपका सारा कैश मेमोरी में सेव किया गया कॉन्टेंट अपने-आप मिटा देता है.

हालांकि, Cloud Functions और Cloud Run सेवाएं डाइनैमिक तरीके से कॉन्टेंट जनरेट करती हैं. इसलिए, किसी यूआरएल के लिए कॉन्टेंट अलग-अलग हो सकता है. जैसे, उपयोगकर्ता का इनपुट या उसकी पहचान. इस वजह से, बैकएंड कोड से हैंडल किए जाने वाले अनुरोधों को डिफ़ॉल्ट रूप से सीडीएन पर कैश मेमोरी में सेव नहीं किया जाता है.

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

इसी तरह, फ़ंक्शन के एक्ज़ीक्यूशन की लागत को कम करने के लिए, कैश मेमोरी में सेव करने के तरीके को कॉन्फ़िगर किया जा सकता है. ऐसा इसलिए, क्योंकि कॉन्टेंट को ट्रिगर किए गए फ़ंक्शन के बजाय, सीडीएन से दिखाया जाता है. Cloud Functions और Cloud Run दस्तावेज़ में, फ़ंक्शन को लागू करने और सेवाओं को ऑप्टिमाइज़ करने के बारे में ज़्यादा पढ़ें.

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

अगर 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 डायरेक्टिव को बदलता है. इससे सीडीएन को यह पता चलता है कि वह कॉन्टेंट को कितने सेकंड तक कैश कर सकता है. सेट किया गया समय खत्म होने पर, सीडीएन को ओरिजन सर्वर के साथ कॉन्टेंट की फिर से पुष्टि करनी होगी. इस हेडर के उदाहरण में, हम max-age की सेटिंग को सिर्फ़ सीडीएन के लिए बदल रहे हैं. साथ ही, सीडीएन को कॉन्टेंट को दस मिनट के लिए कैश मेमोरी में सेव करने की अनुमति दे रहे हैं.

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

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

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

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

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