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

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

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

Cache-Control हेडर के बारे में ज़्यादा जानने के लिए, Mozilla Developer Network और Google के वेब डेवलपर के दस्तावेज़ पर जाएं.

कैश मेमोरी में सेव किया गया कॉन्टेंट कब दिखाया जाता है?

ब्राउज़र और सीडीएन, आपके कॉन्टेंट को इनके आधार पर कैश मेमोरी में सेव करते हैं:

• होस्टनेम
• पाथ
• क्वेरी स्ट्रिंग
• 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, रिस्पॉन्स हेडर के बजाय अनुरोध हेडर पर आधारित होता है.

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

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

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