कैश मेमोरी में सेव करें ❤️

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

Sam Thorogood

यह पोस्ट, अपनी कैश मेमोरी को प्यार करें वीडियो के साथ है. यह वीडियो, Chrome Dev Summit 2020 के एक्सटेंडेड कॉन्टेंट का हिस्सा है. यह वीडियो ज़रूर देखें:

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

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

ध्यान दें: साइट बनाते समय यह ध्यान रखें कि परफ़ॉर्मेंस मेट्रिक में, वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी देने वाली मेट्रिक के साथ-साथ सभी लोड शामिल होते हैं, सिर्फ़ पहला लोड नहीं. हालांकि, Google के कई दिशा-निर्देश, पहली बार लोड होने में लगने वाले समय को ऑप्टिमाइज़ करने पर फ़ोकस करते हैं. यह समय, उपयोगकर्ताओं को लाने के लिए ज़रूरी है! Lighthouse सिर्फ़ खाली कैश मेमोरी पर आपकी साइट की जांच करता है.

लक्ष्य

जब कोई साइट दूसरी बार लोड होती है, तो आपके पास दो लक्ष्य होते हैं:

1. पक्का करें कि आपके उपयोगकर्ताओं को ऐप्लिकेशन का सबसे नया वर्शन मिलता रहे. अगर आपने कुछ बदलाव किया है, तो वह तुरंत दिखना चाहिए
2. #1 को तब करें, जब नेटवर्क से कम से कम डेटा फ़ेच किया जा रहा हो

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

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

बैकग्राउंड

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

इंटरनेट पर मौजूद सामान्य उपयोगकर्ताओं के पास यह सुविधा नहीं होती. इसलिए, हमारे कुछ मुख्य लक्ष्य यह पक्का करना है कि हमारे उपयोगकर्ताओं को दूसरे लोड के साथ बेहतर अनुभव मिले. साथ ही, यह भी पक्का करना ज़रूरी है कि उन्हें खराब अनुभव न मिले या वे फ़्लैश पेज पर न फ़ंसें. (अगर आपको यह जानना है कि हमने web.dev/live साइट को कैसे लॉन्च किया, तो वीडियो देखें!)

थोड़ा बैकग्राउंड के लिए, "पुराना कैश मेमोरी" की एक बहुत ही सामान्य वजह, असल में कैश मेमोरी के लिए 1999 के दौर का डिफ़ॉल्ट है. यह Last-Modified हेडर पर निर्भर करता है:

अलग-अलग समय पर जनरेट की गई ऐसेट (स्लेटी रंग में) को अलग-अलग समय के लिए कैश मेमोरी में सेव किया जाएगा. इससे, दूसरे पेज पर लोड होने वाली ऐसेट को कैश मेमोरी में सेव की गई और नई ऐसेट, दोनों का कॉम्बिनेशन मिल सकता है

आपके ब्राउज़र में लोड की गई हर फ़ाइल को, उसके मौजूदा लाइफ़टाइम के 10% तक सेव रखा जाता है. उदाहरण के लिए, अगर index.html को एक महीने पहले बनाया गया था, तो इसे आपके ब्राउज़र में करीब तीन दिन तक कैश मेमोरी में सेव रखा जाएगा.

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

अच्छी रोशनी वाला रास्ता

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

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

Cache-Control: max-age=0,must-revalidate,public

इसका मतलब है कि फ़ाइल का इस्तेमाल कभी भी नहीं किया जा सकता. साथ ही, इसे फिर से इस्तेमाल करने से पहले, आपको नेटवर्क से इसकी पुष्टि करनी होगी. ऐसा न करने पर, इसे सिर्फ़ "सुझाया गया" माना जाएगा.

ध्यान दें: max-age=0,must-revalidate के बजाय, no-cache भी दिया जा सकता है: यह वैल्यू एक जैसी है. हालांकि, no-cache एक भ्रमित करने वाला नाम है, क्योंकि इसका मतलब "इस फ़ाइल को कभी कैश मेमोरी में सेव न करें" के तौर पर समझा जा सकता है. हालांकि, ऐसा नहीं है. ज़्यादा जानकारी के लिए, MDN पर Cache-Control लेख पढ़ें.

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

भले ही, यह एक आधुनिक तरीका है, लेकिन यह लोकप्रिय सीडीएन, Netlify पर डिफ़ॉल्ट रूप से उपलब्ध है. इसे किसी भी सीडीएन पर कॉन्फ़िगर किया जा सकता है. Firebase होस्टिंग के लिए, अपनी firebase.json फ़ाइल के होस्टिंग सेक्शन में यह हेडर शामिल किया जा सकता है:

"headers": [
  // Be sure to put this last, to not override other headers
  {
    "source": "**",
    "headers": [ {
      "key": "Cache-Control",
      "value": "max-age=0,must-revalidate,public"
    }
  }
]

इसलिए, हमारा सुझाव है कि आप इसे डिफ़ॉल्ट के तौर पर इस्तेमाल करें. हालांकि, यह सिर्फ़ डिफ़ॉल्ट है! डिफ़ॉल्ट सेटिंग को अपग्रेड करने और उनमें बदलाव करने का तरीका जानने के लिए, आगे पढ़ें.

फ़िंगरप्रिंट वाले यूआरएल

अपनी साइट पर दिखाई जाने वाली एसेट, इमेज वगैरह के नाम में फ़ाइल के कॉन्टेंट का हैश शामिल करके, यह पक्का किया जा सकता है कि इन फ़ाइलों में हमेशा यूनीक कॉन्टेंट होगा. उदाहरण के लिए, इससे sitecode.af12de.js नाम वाली फ़ाइलें बन जाएंगी. जब आपका सर्वर इन फ़ाइलों के अनुरोधों का जवाब देता है, तो आपके पास अपने आखिरी उपयोगकर्ता के ब्राउज़र को, इन फ़ाइलों को लंबे समय तक कैश मेमोरी में सेव रखने का निर्देश देने का विकल्प होता है. इसके लिए, आपको इस हेडर के साथ ब्राउज़र को कॉन्फ़िगर करना होगा:

Cache-Control: max-age=31536000,immutable

यह वैल्यू, सेकंड में एक साल होती है. और खास जानकारी के मुताबिक, यह "हमेशा के लिए" के बराबर है.

अहम बात यह है कि इन हैश को मैन्युअल तरीके से जनरेट न करें. यह मैन्युअल तरीके से किया जाने वाला काम है! इसमें आपकी मदद करने के लिए, Webpack, Rollup वगैरह जैसे टूल इस्तेमाल किए जा सकते हैं. टूलिंग रिपोर्ट में इनके बारे में ज़्यादा जानकारी ज़रूर पढ़ें.

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

ध्यान दें: हमने ऊपर दिए गए Cache-Control सुझाव में कीवर्ड immutable शामिल किया है. इस कीवर्ड के बिना, हमारे लंबे Cache-Control को सिर्फ़ एक सुझाव माना जाता है. साथ ही, कुछ ब्राउज़र अब भी इसे अनदेखा कर सर्वर पर जाएंगे. (Chrome ने 2017 में अपने काम करने के तरीके में बदलाव किया, इसलिए यह हमेशा वैसा ही काम करता है जैसे कि अपरिवर्तनीय कीवर्ड चालू हो. इसलिए, फ़िलहाल इसकी ज़रूरत सिर्फ़ Safari और Firefox के लिए है).

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

हालांकि, हम उपयोगकर्ताओं के लिए बनाए गए 'फ़्रेंडली' पेजों का नाम इस तरह नहीं बदल सकते: अपनी index.html फ़ाइल का नाम बदलकर index.abcd12.html करना—यह नाम बदलना मुमकिन नहीं है. आपके पास उपयोगकर्ताओं से यह कहने का विकल्प नहीं है कि वे हर बार आपकी साइट लोड करने पर, किसी नए यूआरएल पर जाएं! इन 'फ़्रेंडली' यूआरएल का नाम इस तरह नहीं बदला जा सकता और न ही इन्हें कैश मेमोरी में सेव किया जा सकता है. इसलिए, मुझे एक मध्यम रास्ता अपनाना पड़ा.

बीच का रास्ता

कैश मेमोरी का इस्तेमाल करने के लिए, बीच का रास्ता भी अपनाया जा सकता है. मैंने दो बेहतरीन विकल्प दिए हैं; कैश कभी नहीं या कैश हमेशा के लिए. साथ ही, ऐसी कई फ़ाइलें होंगी जिन्हें आपको कुछ समय के लिए कैश मेमोरी में सेव रखना हो सकता है. जैसे, मैंने ऊपर बताए गए "फ़्रेंडली" यूआरएल.

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

<img src="/images/foo.jpeg" loading="lazy" />

अगर इस लेज़ी-लोड की गई इमेज को मिटाकर या बदलकर अपनी साइट को अपडेट या बदला जाता है, तो हो सकता है कि आपके एचटीएमएल के कैश मेमोरी में सेव किए गए वर्शन को देखने वाले उपयोगकर्ताओं को गलत या इमेज न दिखे. ऐसा इसलिए, क्योंकि जब वे आपकी साइट पर फिर से आते हैं, तब भी उनके पास ओरिजनल /images/foo.jpeg कैश मेमोरी में सेव होता है.

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

आम तौर पर, कैश मेमोरी में डेटा सेव करने से जुड़ी ज़्यादातर गाइड, इस तरह की सेटिंग के बारे में बताती हैं. क्या आपको एक घंटे, कई घंटों वगैरह के लिए कैश मेमोरी में सेव करना है. इस तरह की कैश मेमोरी को सेट अप करने के लिए, इस तरह के हेडर का इस्तेमाल करें (जो 3, 600 सेकंड या एक घंटे के लिए कैश मेमोरी में सेव होता है):

Cache-Control: max-age=3600,immutable,public

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

एचटीएमएल के अलावा अन्य विकल्प

एचटीएमएल के अलावा, बीच में मौजूद फ़ाइलों के कुछ अन्य विकल्पों में ये शामिल हैं:

• आम तौर पर, ऐसी एसेट खोजें जिनसे दूसरों पर असर न पड़े

  • उदाहरण के लिए: सीएसएस का इस्तेमाल न करें, क्योंकि इससे आपके एचटीएमएल को रेंडर करने के तरीके में बदलाव होता है

• समय-समय पर लेखों के हिस्से के रूप में इस्तेमाल की गई बड़ी इमेज

  • आपके उपयोगकर्ता शायद किसी लेख पर कुछ ही बार जाएं. इसलिए, फ़ोटो या हीरो इमेज को हमेशा के लिए कैश मेमोरी में सेव न करें और स्टोरेज बर्बाद न करें

• ऐसी ऐसेट जो किसी ऐसे आइटम के बारे में बताती है जिसका लाइफ़साइकल होता है

  • मौसम के बारे में JSON डेटा, शायद हर घंटे पब्लिश किया जाता हो. इसलिए, आपके पास पिछले नतीजे को एक घंटे के लिए कैश मेमोरी में सेव करने का विकल्प है. यह आपकी विंडो में नहीं बदलेगा
  • ओपन-सोर्स प्रोजेक्ट के बिल्ड की दर सीमित हो सकती है. इसलिए, बिल्ड की स्थिति की इमेज को तब तक कैश मेमोरी में सेव रखें, जब तक कि स्थिति में बदलाव न हो जाए

खास जानकारी

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

कैश मेमोरी का इस्तेमाल करना, वेब पर कोई नया कॉन्सेप्ट नहीं है. हालांकि, शायद इसे डिफ़ॉल्ट तौर पर इस्तेमाल करने की ज़रूरत है. इसलिए, किसी एक कैश मेमोरी का इस्तेमाल करें और ज़रूरत पड़ने पर, कैश मेमोरी से जुड़ी बेहतर रणनीतियों के लिए ऑप्ट-इन करें. पढ़ने के लिए धन्यवाद!

इन्हें भी देखें

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