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

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

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

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

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

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

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

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