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

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 को इस तरह सेट करें:

res.set('Cache-Control', 'public, max-age=300, s-maxage=600');

इस उदाहरण हेडर में, डायरेक्टिव ने तीन काम किए हैं:

• public — कैश मेमोरी को public के तौर पर मार्क करता है. इसका मतलब है कि ब्राउज़र और इंटरमीडिएट सर्वर (मतलब, Firebase Hosting के लिए सीडीएन) कैश मेमोरी कर सकते हैं या वीडियो कॉन्टेंट.

• max-age — ब्राउज़र और सीडीएन को बताता है कि वे कितने सेकंड तक कैश मेमोरी में सेव कर सकते हैं या वीडियो कॉन्टेंट. तय समय के खत्म हो जाने पर, ब्राउज़र और सीडीएन को ऑरिजिन सर्वर से कॉन्टेंट की फिर से पुष्टि करें. उदाहरण के तौर पर दिए गए हेडर में, हम ब्राउज़र और सीडीएन को कॉन्टेंट को पांच मिनट के लिए कैश मेमोरी में सेव करने की अनुमति दें (देखें सीडीएन कैश मेमोरी के खास कंट्रोल के लिए यहां s-maxage दिया गया है).

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

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

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

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