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

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

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

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

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

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

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

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 Hosting
• Netlify

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

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

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

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

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

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

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

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

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

वेबसाइट पर पहले भी आ चुके लोगों के लिए, कैश मेमोरी के इस्तेमाल को ऑप्टिमाइज़ करने का तरीका जानने के लिए, कैश मेमोरी का सही इस्तेमाल करें लेख पढ़ें.

अपेंडिक्स: कुछ और सलाह

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

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

अन्य जानकारी: Cache-Control फ़्लोचार्ट

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