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

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

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

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

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

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

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

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

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

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

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

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

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

• होस्टनेम
• रास्ता
• क्वेरी स्ट्रिंग
• अनुरोध के हेडर का कॉन्टेंट जिसकी जानकारी Vary हेडर में दी गई है

अलग-अलग हेडर

कॉन्टेंट बनाने Vary हेडर तय करती है कि सही जानकारी देने के लिए किस अनुरोध हेडर का इस्तेमाल किया जाना चाहिए रिस्पॉन्स (कैश मेमोरी में सेव किया गया कॉन्टेंट मान्य है या नहीं ऑरिजिन सर्वर से दोबारा पुष्टि की गई हो.

Firebase होस्टिंग की मदद से, आपकी वेबसाइट के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 अनुरोध कैश मेमोरी में सेव किए जा सकते हैं. अन्य का इस्तेमाल करने वाले एचटीटीपीएस अनुरोध तरीकों को कभी कैश मेमोरी में सेव नहीं किया जाता.

• Vary हेडर में सेटिंग जोड़ते समय सावधानी बरतें. ज़्यादा सेटिंग तो इस बात की संभावना कम हो जाती है कि सीडीएन कैश मेमोरी में सेव किया गया कॉन्टेंट दिखा सकता है. यह भी याद रखें कि Vary, अनुरोध हेडर पर आधारित होता है, न कि रिस्पॉन्स पर हेडर.

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

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

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