एचटीटीपी कैश की मदद से ग़ैर-ज़रूरी नेटवर्क अनुरोधों को रोकें

नेटवर्क पर संसाधनों को फ़ेच करने की प्रोसेस धीमी और महंगी, दोनों होती है:

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

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

यह गाइड आपको एचटीटीपी कैशिंग को लागू करने से जुड़ी बुनियादी जानकारी देती है.

वेबसाइट का अलग-अलग ब्राउज़र पर चलना

एचटीटीपी कैश, वेब प्लैटफ़ॉर्म के एपीआई के संग्रह का सामान्य नाम है. यह सभी ब्राउज़र में काम करता है:

Cache-Control

ETag

Last-Modified

एचटीटीपी कैश कैसे काम करता है

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

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

कॉन्सेप्ट के बारे में ज़्यादा जानने के लिए, एमडीएन का एचटीटीपी कैश मेमोरी लेख पढ़ें.

अनुरोध के हेडर: डिफ़ॉल्ट सेटिंग पर बने रहें (आम तौर पर)

आपके वेब ऐप्लिकेशन के आउटगोइंग अनुरोधों में कई अहम हेडर शामिल होने चाहिए. हालांकि, ब्राउज़र अक्सर अनुरोध करते समय, उन्हें आपकी ओर से सेट कर देता है. अपडेट किए जाने की जांच पर असर डालने वाले अनुरोध हेडर, जैसे कि If-None-Match और If-Modified-Since एचटीटीपी कैश में मौजूद वैल्यू को ब्राउज़र की समझ के हिसाब से दिखाए जाते हैं.

यह अच्छी खबर है: इसका मतलब है कि अब आप अपने एचटीएमएल में <img src="my-image.png"> जैसे टैग शामिल करना जारी रख सकते हैं. साथ ही, ब्राउज़र अपने-आप एचटीटीपी कैश मेमोरी में डेटा सेव करने का काम करता है. इसके लिए, आपको अलग से कोई मेहनत नहीं करनी पड़ती.

रिस्पॉन्स हेडर: अपना वेब सर्वर कॉन्फ़िगर करें

एचटीटीपी कैश सेटअप करने के जो तरीके सबसे ज़्यादा मायने रखते हैं वे हैं हेडर जिन्हें आपका वेब सर्वर हर आउटगोइंग रिस्पॉन्स से जोड़ता है. नीचे दिए गए हेडर, कैश मेमोरी के असरदार व्यवहार पर असर डालते हैं:

Cache-Control

यह बताने के लिए कि सर्वर, ब्राउज़र और इंटरमीडिएट कैश मेमोरी को अलग-अलग रिस्पॉन्स को कैसे और कितनी देर तक कैश मेमोरी में सेव करना चाहिए, Cache-Control निर्देश दे सकता है.

ETag.

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

Last-Modified

इस हेडर का काम ETag जैसा ही है. हालांकि, इसमें ETag की कॉन्टेंट पर आधारित रणनीति के बजाय, समय के हिसाब से बनी रणनीति का इस्तेमाल किया जाता है. इससे यह पता चलता है कि संसाधन में बदलाव हुआ है या नहीं.

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

आपकी कुछ खोज से बचने के लिए, यहां कुछ लोकप्रिय वेब सर्वर कॉन्फ़िगर करने के निर्देश दिए गए हैं:

• एक्सप्रेशन
• Apache
• nginx
• Firebase होस्टिंग
• Netlify

Cache-Control रिस्पॉन्स हेडर को छोड़ने पर, एचटीटीपी कैश मेमोरी में सेव करने की सुविधा बंद नहीं होती! इसके बजाय, ब्राउज़र असरदार तरीके से अनुमान लगाते हैं कि किसी खास तरह के कॉन्टेंट के लिए, किस तरह का कैश मेमोरी में डेटा सेव करना सबसे सही रहेगा. हो सकता है कि आपको उस ऑफ़र से ज़्यादा कंट्रोल चाहिए हो. इसलिए, आपको अपने रिस्पॉन्स हेडर को कॉन्फ़िगर करने के लिए समय देना होगा.

आपको किन रिस्पॉन्स हेडर की वैल्यू का इस्तेमाल करना चाहिए?

अपने वेब सर्वर के रिस्पॉन्स हेडर कॉन्फ़िगर करते समय आपको इन दो स्थितियों पर ध्यान देना चाहिए.

वर्शन वाले यूआरएल को लंबे समय तक कैश मेमोरी में सेव करना

ऐसे यूआरएल के अनुरोधों का जवाब देते समय जिनमें "फ़िंगरप्रिंट" या वर्शन की जानकारी है और जिनके कॉन्टेंट में कभी बदलाव नहीं किया जाना चाहिए. अपने जवाबों में Cache-Control: max-age=31536000 जोड़ें.

इस वैल्यू को सेट करने से, ब्राउज़र को पता चलता है कि जब अगले साल (31,536,000 सेकंड, ज़्यादा से ज़्यादा वैल्यू) में उसी यूआरएल को लोड करने की ज़रूरत होगी, तो वह एचटीटीपी कैश में मौजूद वैल्यू का तुरंत इस्तेमाल कर सकता है. इसके लिए, उसे आपके वेब सर्वर से नेटवर्क अनुरोध करने की ज़रूरत नहीं पड़ेगी. बहुत बढ़िया—आपने तुरंत ही भरोसा और स्पीड हासिल कर ली है.

वेबपैक जैसे बिल्ड टूल आपकी एसेट के यूआरएल में हैश फ़िंगरप्रिंट असाइन करने की प्रोसेस अपने-आप में बदल सकते हैं.

बिना वर्शन वाले यूआरएल के लिए सर्वर की फिर से पुष्टि

माफ़ करें, आपके लोड किए गए सभी यूआरएल के वर्शन नहीं हैं. हो सकता है कि अपने वेब ऐप्लिकेशन को डिप्लॉय करने से पहले, बिल्ड स्टेप शामिल न किया जा सके. इसलिए, एसेट यूआरएल में हैश नहीं जोड़ा जा सकता. हर वेब ऐप्लिकेशन को एचटीएमएल फ़ाइलों की ज़रूरत होती है, जिनमें वर्शन की जानकारी नहीं होती. ऐसा इसलिए होता है, क्योंकि अगर किसी को यह याद रखना है कि वह https://example.com/index.34def12.html यूआरएल है, तो उसे वेब ऐप्लिकेशन इस्तेमाल करने की चिंता नहीं करनी पड़ेगी. तो उन यूआरएल के लिए क्या किया जा सकता है?

एचटीटीपी कैश मेमोरी में डेटा सेव करने की सुविधा, नेटवर्क से पूरी तरह से बचने के लिए काफ़ी नहीं है. (चिंता न करें—आपको जल्द ही सर्विस वर्कर के बारे में जानकारी मिलेगी, जिससे आपको अतिरिक्त सहायता मिलेगी. हालांकि, यह पक्का करने के लिए कि नेटवर्क अनुरोध ज़्यादा से ज़्यादा तेज़ और असरदार हों, आपको कुछ तरीके अपनाने होंगे.

यहां दिए गए Cache-Control वैल्यू की मदद से, यह ठीक से तय किया जा सकता है कि अपग्रेड नहीं किए गए यूआरएल को कैश मेमोरी में कहां और कैसे कैश मेमोरी में सेव किया जाता है:

• no-cache, ब्राउज़र को बताता है कि कैश मेमोरी में सेव किए गए यूआरएल का वर्शन इस्तेमाल करने से पहले, ब्राउज़र को हर बार सर्वर से दोबारा पुष्टि करनी होगी.
• no-store, ब्राउज़र और बीच के लेवल पर सेव की गई अन्य कैश मेमोरी (जैसे कि सीडीएन) को बताता है कि फ़ाइल का कोई भी वर्शन कभी सेव न किया जाए.
• private: ब्राउज़र, फ़ाइल को कैश मेमोरी में सेव कर सकते हैं, लेकिन बीच के लेवल पर कैश मेमोरी में सेव नहीं कर सकते.
• public: रिस्पॉन्स को किसी भी कैश मेमोरी में सेव किया जा सकता है.

इस्तेमाल की जाने वाली Cache-Control वैल्यू तय करने की प्रोसेस को विज़ुअलाइज़ करने के लिए, अपेंडिक्स: Cache-Control फ़्लोचार्ट देखें. Cache-Control में निर्देशों की कॉमा-सेपरेटेड लिस्ट भी स्वीकार की जा सकती है. ज़्यादा जानकारी: Cache-Control उदाहरण देखें.

ETag या Last-Modified को सेट करने से भी मदद मिल सकती है. जैसा कि रिस्पॉन्स हेडर में बताया गया है, ETag और Last-Modified दोनों एक ही मकसद से काम करते हैं: यह तय करना कि ब्राउज़र को ऐसी कैश फ़ाइल फिर से डाउनलोड करने की ज़रूरत है या नहीं जिसकी समयसीमा खत्म हो चुकी है. हम ETag का इस्तेमाल करने का सुझाव देते हैं, क्योंकि यह ज़्यादा सटीक है.

ETag या Last-Modified को सेट करने पर, फिर से पुष्टि करने के अनुरोध को और बेहतर बनाने के लिए, यह If-Modified-Since या If-None-Match अनुरोध के हेडर को ट्रिगर करता है, जिनके बारे में अनुरोध के हेडर में बताया गया है.

जब सही तरीके से कॉन्फ़िगर किया गया वेब सर्वर उन इनकमिंग अनुरोध हेडर को देखता है, तो वह इस बात की पुष्टि कर सकता है कि ब्राउज़र के एचटीटीपी कैश में पहले से मौजूद संसाधन का वर्शन, वेब सर्वर पर सबसे नए वर्शन से मेल खाता है या नहीं. अगर कोई क्वेरी मैच होती है, तो सर्वर 304 Not Modified एचटीटीपी रिस्पॉन्स के साथ जवाब दे सकता है. यह रिस्पॉन्स, "Ok, पहले से उपलब्ध टेस्टिंग का इस्तेमाल करते रहें!" इस तरह का जवाब भेजते समय, ट्रांसफ़र करने के लिए बहुत कम डेटा होता है. इसलिए, अनुरोध किए जा रहे असल संसाधन की कॉपी को वापस भेजने के मुकाबले, यह प्रोसेस ज़्यादा तेज़ होती है.

खास जानकारी

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

ये Cache-Control कॉन्फ़िगरेशन अच्छी शुरुआत के लिए हैं:

• ऐसे संसाधनों के लिए Cache-Control: no-cache जिन्हें हर बार इस्तेमाल करने से पहले, सर्वर की मदद से दोबारा पुष्टि की जानी चाहिए.
• Cache-Control: no-store में ऐसे रिसॉर्स मिलेंगे जिन्हें कभी कैश मेमोरी में सेव नहीं किया जाना चाहिए.
• वर्शन वाले संसाधनों के लिए Cache-Control: max-age=31536000.

ETag या Last-Modified हेडर की मदद से, खत्म हो चुकी कैश मेमोरी के रिसॉर्स की बेहतर तरीके से फिर से पुष्टि की जा सकती है.

ज़्यादा जानें

अगर आपको Cache-Control हेडर का इस्तेमाल करने से जुड़ी बुनियादी बातों के बारे में जानना है, तो जेक आर्चिबाल्ड की कैशिंग के सबसे सही तरीके और ज़्यादा से ज़्यादा उम्र की जानकारी वाली गाइड देखें.

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

अपेंडिक्स: अन्य सलाह

अगर आपके पास ज़्यादा समय है, तो एचटीटीपी कैश के इस्तेमाल को ऑप्टिमाइज़ करने के कुछ और तरीके यहां बताए गए हैं:

• एक जैसे यूआरएल इस्तेमाल करें. अगर एक ही कॉन्टेंट को अलग-अलग यूआरएल पर दिखाया जाता है, तो ब्राउज़र उस कॉन्टेंट को कई बार फ़ेच और सेव करता है.
• चर्न आउट कम करें. अगर किसी संसाधन (जैसे कि सीएसएस फ़ाइल) का एक हिस्सा अक्सर अपडेट होता है, जबकि बाकी फ़ाइल (लाइब्रेरी कोड के साथ) अपडेट नहीं होती है, तो बार-बार अपडेट होने वाले कोड को एक अलग फ़ाइल में बांटें. बार-बार अपडेट होने वाले कोड के लिए कम अवधि कैश मेमोरी में सेव करने की रणनीति और बार-बार न बदलने वाले कोड को कैश मेमोरी में सेव करने की लंबी रणनीति इस्तेमाल करें.
• अगर आपकी Cache-Control नीति में कुछ पुरानी जानकारी स्वीकार की जाती है, तो नया stale-while-revalidate डायरेक्टिव इस्तेमाल करें .

अपेंडिक्स: Cache-Control फ़्लोचार्ट

अपेंडिक्स: Cache-Control के उदाहरण