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

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

Sam Thorogood

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

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

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

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

लक्ष्य

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

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

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

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

बैकग्राउंड

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

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

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

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

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

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

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

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

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

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

बुनियादी तौर पर, यह कहा जाता है; फ़ाइल बिना किसी समय के के लिए मान्य हो. साथ ही, आपको उस नेटवर्क से दोबारा इस्तेमाल नहीं किया जा सकेगा (नहीं तो यह सिर्फ़ "सुझाया गया").

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

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

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

"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 को सिर्फ़ एक सुझाव माना जाएगा और कुछ ब्राउज़र फिर भी इसे अनदेखा करके सर्वर पर चले जाएंगे. (साल 2017 में, Chrome ने अपना व्यवहार बदल दिया, इसलिए यह हमेशा ऐसे ही काम करता है जैसे कि नहीं बदले जा सकने वाले कीवर्ड का इस्तेमाल किया जा रहा हो—इसलिए, फ़िलहाल इसकी ज़रूरत सिर्फ़ Safari और Firefox के लिए है).

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

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

बीच का हिस्सा

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

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

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

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

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

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

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

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

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

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

• आम तौर पर, ऐसी ऐसेट ढूंढना जिनका असर दूसरों पर नहीं पड़ता

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

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

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

• ऐसी ऐसेट जो किसी ऐसी चीज़ को दिखाती है जो अपने-आप में सेव रहती है

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

खास जानकारी

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

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

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

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