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

नेटवर्क पर संसाधन फ़ेच करने में ज़्यादा समय भी लगता है. साथ ही, यह तरीका महंगा भी है:

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

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

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

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

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

Cache-Control

ETag

Last-Modified

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

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

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

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

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

आपके वेब ऐप्लिकेशन के आउटगोइंग अनुरोधों में कई अहम हेडर शामिल किए जाने चाहिए. हालांकि, जब अनुरोध करता है, तो ब्राउज़र करीब-करीब हमेशा आपकी ओर से उन्हें सेट करने का ध्यान रखता है. अनुरोध के हेडर, जैसे कि If-None-Match और If-Modified-Since जैसे अनुरोध हेडर, एचटीटीपी कैश में मौजूद मौजूदा वैल्यू के बारे में ब्राउज़र की समझ के आधार पर दिखते हैं. जैसे, 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 सेकंड; अधिकतम समर्थित मान) में किसी भी समय समान URL लोड करने की आवश्यकता हो, तो वह आपके वेब सर्वर पर नेटवर्क अनुरोध किए बिना तुरंत HTTP कैश में मान का उपयोग कर सकता है. बहुत बढ़िया—आपने नेटवर्क से बचने की वजह से तुरंत विश्वसनीयता और रफ़्तार हासिल कर ली है!

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

खास जानकारी

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

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