सोमवार, 9 दिसंबर, 2024
कृपया हमें कैश मेमोरी में सेव करने की अनुमति दें.
पिछले कुछ सालों में इंटरनेट का इस्तेमाल तेज़ी से बढ़ने लगा है. इस वजह से, Google ने भी क्रॉल करने की संख्या बढ़ा दी है. Google का क्रॉल करने वाला इन्फ़्रास्ट्रक्चर, हेयुरिस्टिक्स कैश मेकेनिज़्म के साथ काम करता है. असल में, यह हमेशा से ऐसा करता रहा है. हालांकि, लोकल कैश मेमोरी से वापस भेजे जा सकने वाले अनुरोधों की संख्या कम हो गई है: 10 साल पहले, कुल फ़ेच किए गए डेटा में से करीब 0.026% डेटा को कैश मेमोरी में सेव किया जा सकता था, जो कि पहले से ही काफ़ी कम थी. आज यह संख्या 0.017% है.
कैश मेमोरी का इस्तेमाल करना क्यों ज़रूरी है?
इंटरनेट का पूरा फ़ायदा लेने के लिए कैश मेमोरी का इस्तेमाल करना बेहद ज़रूरी है. कैश मेमोरी की मदद से, पेजों को फिर से खोलने पर तेज़ी से लोड किया जा सकता है. इससे कंप्यूटिंग रिसॉर्स के साथ-साथ, प्राकृतिक संसाधनों की बचत होती है. साथ ही, क्लाइंट और सर्वर, दोनों के लिए महंगे बैंडविड्थ की भी काफ़ी बचत होती है.
खास तौर पर, अगर आपकी साइट बड़ी है और अलग-अलग यूआरएल में मौजूद कॉन्टेंट में बहुत कम बदलाव होता है, तो स्थानीय तौर पर कैश मेमोरी सेव करने की अनुमति देने से, आपकी साइट को ज़्यादा बेहतर तरीके से क्रॉल किया जा सकता है. Google का क्रॉल करने वाला इन्फ़्रास्ट्रक्चर, एचटीटीपी कैश मेमोरी के स्टैंडर्ड के मुताबिक, एचटीटीपी कैश मेमोरी का इस्तेमाल करता है. यह खास तौर पर, ETag रिस्पॉन्स- और If-None-Match अनुरोध हेडर के साथ-साथ, Last-Modified रिस्पॉन्स- और If-Modified-Since अनुरोध हेडर के ज़रिए ऐसा करता है.
हमारा सुझाव है कि आप ETag का इस्तेमाल करें, क्योंकि इसमें गड़बड़ियों और गलतियों की संभावना कम होती है. इसकी वैल्यू, Last-Modified वैल्यू की तरह स्ट्रक्चर्ड नहीं होती. अगर आपके पास विकल्प है, तो दोनों को सेट करें: इंटरनेट को फ़ायदा होगा. शायद.
आपको जिस बदलाव के लिए क्लाइंट की कैश मेमोरी रीफ़्रेश करनी है वह आपके हिसाब से तय किया जा सकता है. हमारा सुझाव है कि अपने कॉन्टेंट में अहम बदलाव करने पर, कैश मेमोरी को रीफ़्रेश करें. अगर आपने सिर्फ़ अपने पेज पर सबसे नीचे मौजूद कॉपीराइट की तारीख अपडेट की है, तो शायद यह ज़रूरी न हो.
ETag और If-None-Match
Google के क्रॉलर, ETag पर आधारित शर्तों के अनुरोधों के साथ ठीक वैसे ही काम करते हैं. इस बारे में, एचटीटीपी कैश मेमोरी स्टैंडर्ड में बताया गया है.
इसका मतलब है कि Google के क्रॉलर को कैश मेमोरी में सेव करने की प्राथमिकता का सिग्नल देने के लिए, Etag वैल्यू को किसी भी मनमुताबिक ASCII स्ट्रिंग पर सेट करें. आम तौर पर, यह कॉन्टेंट या वर्शन नंबर का हैश होता है. हालांकि, यह π का कोई हिस्सा भी हो सकता है. यह आप पर निर्भर करता है. यह स्ट्रिंग, ऐक्सेस किए गए यूआरएल से होस्ट किए गए कॉन्टेंट के दिखाए जाने के लिए यूनीक होनी चाहिए.
उदाहरण के लिए, अगर एक ही यूआरएल (जैसे, मोबाइल और डेस्कटॉप वर्शन) के तहत एक ही कॉन्टेंट के अलग-अलग वर्शन होस्ट किए जाते हैं, तो हर वर्शन की अपनी यूनीक ETag वैल्यू हो सकती है.
Google के वे क्रॉलर जो कैश मेमोरी का इस्तेमाल करते हैं वे If-None-Match header में उस यूआरएल के पिछले क्रॉल के लिए मिली ETag वैल्यू भेजेंगे. अगर क्रॉलर से भेजी गई ETag
वैल्यू, सर्वर से जनरेट की गई मौजूदा वैल्यू से मेल खाती है, तो आपके सर्वर को एचटीटीपी 304 (बदलाव नहीं किया गया) स्टेटस कोड दिखाना चाहिए. साथ ही, इसमें एचटीटीपी बॉडी नहीं होनी चाहिए. यह आखिरी हिस्सा, एचटीटीपी बॉडी नहीं है. यह कुछ वजहों से अहम हिस्सा है:
- आपके सर्वर को कॉन्टेंट जनरेट करने के लिए, कंप्यूटिंग रिसॉर्स खर्च करने की ज़रूरत नहीं होती. इसका मतलब है कि आपके पास पैसे बचाने का विकल्प होता है
- आपके सर्वर को एचटीटीपी बॉडी ट्रांसफ़र करने की ज़रूरत नहीं होती. इसका मतलब है कि आपके पास पैसे बचाने का विकल्प होता है
क्लाइंट साइड पर, उपयोगकर्ता के ब्राउज़र या Googlebot जैसे यूआरएल के तहत मौजूद कॉन्टेंट को क्लाइंट के इंटरनल कैश मेमोरी से हासिल किया जाता है. इसमें डेटा ट्रांसफ़र नहीं होता, इसलिए यह प्रोसेस तेज़ी से पूरी होती है. इससे उपयोगकर्ता खुश होते हैं और हो सकता है कि इससे उनके कुछ संसाधन भी बचें.
Last-Modified और If-Modified-Since
ETag की तरह ही, Google के क्रॉलर Last-Modified based के साथ काम करते हैं. शर्तों के साथ किए जाने वाले अनुरोधों के बारे में एचटीटीपी कैश मेमोरी स्टैंडर्ड में बताया गया है. यह सिमेंटिक के हिसाब से, ETag की तरह ही काम करता है — यह तय करने के लिए कि रिसॉर्स को कैश मेमोरी में सेव किया जा सकता है या नहीं, किसी आइडेंटिफ़ायर का इस्तेमाल किया जाता है — और क्लाइंट साइड पर, ETag के जैसे ही फ़ायदे देता है.
अगर कैश मेमोरी सेव करने के निर्देश के तौर पर Last-Modified का इस्तेमाल किया जा रहा है, तो हमारे पास आपके लिए कुछ सुझाव हैं:
-
Last-Modifiedहेडर में तारीख को एचटीटीपी स्टैंडर्ड के हिसाब से फ़ॉर्मैट किया जाना चाहिए. पार्स करने से जुड़ी समस्याओं से बचने के लिए, हमारा सुझाव है कि आप तारीख के लिए इस फ़ॉर्मैट का इस्तेमाल करें: "Weekday, DD Mon YYYY HH:MM:SS Timezone". उदाहरण के लिए, "Fri, 4 Sep 1998 19:15:56 GMT". -
हालांकि,
Cache-Controlहेडर काmax-ageफ़ील्ड सेट करना ज़रूरी नहीं है. हालांकि, इसे सेट करने से क्रॉलर को यह तय करने में मदद मिलती है कि किसी खास यूआरएल को फिर से कब क्रॉल किया जाए.max-ageफ़ील्ड की वैल्यू को उन सेकंड की संख्या पर सेट करें जिनमें कॉन्टेंट में कोई बदलाव नहीं होगा. उदाहरण के लिए,Cache-Control: max-age=94043.
उदाहरण
अगर आप भी मेरी तरह हैं, तो हेयुरिस्टिक्स कैश मेमोरी के काम करने के तरीके को समझना मुश्किल है. हालांकि, अनुरोधों और जवाबों की चेन का उदाहरण दिखाने से मुझे मदद मिलती है. यहां दो चेन दी गई हैं — एक ETag/If-None-Match के लिए और एक Last-Modified/If-Modified-Since के लिए — ताकि यह देखा जा सके कि यह कैसे काम करती है:
ETag/If-None-Match |
Last-Modified/If-Modified-Since |
|
|---|---|---|
क्रॉल के लिए सर्वर का जवाब: यह वह जवाब है जिससे क्रॉलर, पहले से तय शर्त वाले हेडर फ़ील्ड ETag और Last-Modified को सेव कर सकता है.
|
HTTP/1.1 200 OK Content-Type: text/plain Date: Fri, 4 Sep 1998 19:15:50 GMT ETag: "34aa387-d-1568eb00" ... |
HTTP/1.1 200 OK Content-Type: text/plain Date: Fri, 4 Sep 1998 19:15:50 GMT Last-Modified: Fri, 4 Sep 1998 19:15:56 GMT Cache-Control: max-age=94043 ... |
क्रॉलर का शर्तों के साथ किया जाने वाला अनुरोध: शर्तों के साथ किया जाने वाला अनुरोध, पिछले अनुरोध से सेव की गई शर्तों के हेडर की वैल्यू पर आधारित होता है. वैल्यू को If-None-Match और If-Modified-Since के अनुरोध हेडर में पुष्टि के लिए, सर्वर पर वापस भेजा जाता है.
|
GET /hello.world HTTP/1.1 Host: www.example.com Accept-Language: en, hu User-Agent: Googlebot/2.1 (+http://www.google.com/bot.html) If-None-Match: "34aa387-d-1568eb00" ... |
GET /hello.world HTTP/1.1 Host: www.example.com Accept-Language: en, hu User-Agent: Googlebot/2.1 (+http://www.google.com/bot.html) If-Modified-Since: Fri, 4 Sep 1998 19:15:56 GMT ... |
शर्त के साथ किए गए अनुरोध का सर्वर रिस्पॉन्स: क्रॉलर से भेजी गई शर्त के साथ हेडर वैल्यू की पुष्टि, सर्वर की ओर से की जाती है. इसलिए, सर्वर क्रॉलर को 304 एचटीटीपी स्टेटस कोड (एचटीटीपी बॉडी के बिना) दिखाता है. ऐसा हर अनुरोध के लिए तब तक होगा, जब तक कि ज़रूरी शर्तों की पुष्टि नहीं हो जाती. जैसे, सर्वर साइड पर ETag या Last-Modified की तारीख में बदलाव होना.
|
HTTP/1.1 304 Not Modified Date: Fri, 4 Sep 1998 19:15:50 GMT Expires: Fri, 4 Sep 1998 19:15:52 GMT Vary: Accept-Encoding If-None-Match: "34aa387-d-1568eb00" ... |
HTTP/1.1 304 Not Modified Date: Fri, 4 Sep 1998 19:15:50 GMT Expires: Fri, 4 Sep 1998 19:15:51 GMT Vary: Accept-Encoding If-Modified-Since: Fri, 4 Sep 1998 19:15:56 GMT ... |
अगर आपको अपने उपयोगकर्ताओं को खुश करना है और होस्टिंग के बिल पर कुछ पैसे बचाने हैं, तो अपनी साइट के लिए एचटीटीपी कैश मेमोरी चालू करने के तरीके के बारे में, होस्टिंग या कॉन्टेंट मैनेजमेंट सिस्टम (सीएमएस) की सेवा देने वाली कंपनी या अपने डेवलपर से बात करें. इससे ज़्यादा कुछ नहीं, लेकिन आपके उपयोगकर्ता आपसे थोड़ा ज़्यादा जुड़ पाएंगे.
अगर आपको कैश मेमोरी में सेव करने के बारे में बात करनी है, तो अपने आस-पास के Search Central के सहायता समुदाय पर जाएं. अगर आपको कैश मेमोरी में सेव करने के तरीके के बारे में कोई टिप्पणी करनी है, तो इस ब्लॉग पोस्ट के साथ पब्लिश किए गए कैश मेमोरी में सेव करने के बारे में दस्तावेज़ पर सुझाव/राय दें या शिकायत करें.