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

नेटवर्क पर संसाधनों को पाना धीमा और महँगा है:

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

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

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

ब्राउज़र के साथ काम करना

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

Cache-Control

ETag

Last-Modified

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

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

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

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

अनुरोध के हेडर: आम तौर पर, डिफ़ॉल्ट हेडर का इस्तेमाल करें

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

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

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

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

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

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

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

• Express
• Apache
• nginx
• Firebase होस्टिंग
• Netlify

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

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

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

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

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

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

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

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

माफ़ करें, आपके लोड किए गए सभी यूआरएल के वर्शन नहीं होते. ऐसा हो सकता है कि आप अपने वेब ऐप्लिकेशन को डिप्लॉय करने से पहले, बिल्ड चरण को शामिल न कर पा रहे हों. इसलिए, अपनी एसेट के यूआरएल में हैश नहीं जोड़े जा सकते. साथ ही, हर वेब ऐप्लिकेशन को HTML फ़ाइलों की ज़रूरत होती है. इन फ़ाइलों में, वर्शन की जानकारी कभी शामिल नहीं की जाएगी. ऐसा इसलिए, क्योंकि अगर किसी को यह याद रखना पड़े कि 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 एचटीटीपी रिस्पॉन्स के साथ जवाब दे सकता है. यह जवाब, "अरे, पहले से मौजूद का इस्तेमाल करते रहो!" के बराबर होता है. इस तरह का जवाब भेजते समय, बहुत कम डेटा ट्रांसफ़र करना पड़ता है. इसलिए, आम तौर पर यह जवाब, अनुरोध किए गए असल संसाधन की कॉपी भेजने के मुकाबले काफ़ी तेज़ी से भेजा जा सकता है.

खास जानकारी

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

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 उदाहरण