इस पेज का अनुवाद Cloud Translation API से किया गया है.

बैक और फ़ॉरवर्ड कैश मेमोरी

Philip Walton

Barry Pollard

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

इस पेज पर सभी ब्राउज़र पर bfcache के लिए अपने पेजों को ऑप्टिमाइज़ करने का तरीका बताया गया है.

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

bfcache कई सालों सेFirefox और Safari में काम करता है. यह सुविधा डेस्कटॉप और मोबाइल, दोनों पर काम करती है.

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

bfcache की बुनियादी बातें

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

इस वीडियो में दिखाया गया है कि bfcache कितनी तेज़ी से नेविगेशन कर सकता है:

bfcache का इस्तेमाल करने से, बैक और फ़ॉरवर्ड नेविगेशन के दौरान पेज ज़्यादा तेज़ी से लोड होते हैं.

Chrome के इस्तेमाल के बारे में डेटा से पता चलता है कि डेस्कटॉप पर, 10 में से 1 नेविगेशन और मोबाइल पर, 5 में से 1 नेविगेशन, पीछे या आगे की ओर जाता है. इस वजह से bfcache बहुत समय और डेटा खर्च बचा सकता है.

"कैश मेमोरी" कैसे काम करती है

Bfcache के लिए इस्तेमाल किया जाने वाला "कैश", एचटीटीपी कैश मेमोरी से अलग है. यह बार-बार होने वाले नेविगेशन की प्रोसेस को तेज़ करने में अपनी भूमिका निभाता है. bfcache, JavaScript के साथ-साथ मेमोरी में मौजूद पूरे पेज का स्नैपशॉट होता है. वहीं, एचटीटीपी कैश मेमोरी में सिर्फ़ पहले किए गए अनुरोधों के रिस्पॉन्स शामिल होते हैं. ऐसा बहुत कम होता है कि एचटीटीपी कैश से किसी पेज को लोड करने के लिए सभी अनुरोध किए जाएं. इसलिए, bfcache के डेटा को वापस लाने की सुविधा का इस्तेमाल करके, बार-बार होने वाली विज़िट, सबसे अच्छे ऑप्टिमाइज़ किए गए नॉन-bfcache नेविगेशन से भी ज़्यादा तेज़ होती हैं.

हालांकि, मेमोरी में किसी पेज का स्नैपशॉट बनाने से, पहले से चल रहे कोड को सुरक्षित रखने के तरीके में कुछ जटिलता की ज़रूरत पड़ती है. उदाहरण के लिए, पेज के bfcache में होने के दौरान, टाइम आउट की अवधि खत्म होने पर, setTimeout() कॉल को कैसे मैनेज किया जाएगा?

इसका जवाब यह है कि ब्राउज़र, bfcache के पेजों के लिए ऐसे वादों या टाइमर को रोक देते हैं जिन्हें पूरा नहीं किया गया है. इसमें, JavaScript टास्क की सूची में मौजूद तकरीबन सभी बचे हुए टास्क भी शामिल हैं. साथ ही, अगर पेज को bfcache से वापस लाया जाता है, तो टास्क को फिर से शुरू कर दिया जाता है.

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

एपीआई का इस्तेमाल करने से, किसी पेज के बैक-फ़ॉरवर्ड कैश मेमोरी की सुविधा पर पड़ने वाले असर के बारे में ज़्यादा जानने के लिए, bfcache के लिए अपने पेजों को ऑप्टिमाइज़ करें लेख पढ़ें.

Bfcache और सिंगल पेज ऐप्लिकेशन (SPA)

bfcache ब्राउज़र से मैनेज किए जाने वाले नेविगेशन के साथ काम करता है. इसलिए, यह सिंगल-पेज ऐप्लिकेशन (एसपीए) में "सॉफ़्ट नेविगेशन" के लिए काम नहीं करता है. हालांकि, bfcache अब भी एसपीए से जाते और वापस लौटते समय मदद कर सकता है.

bfcache के लिए एपीआई

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

bfcache का पता लगाने के लिए इस्तेमाल किए जाने वाले मुख्य इवेंट, पेज ट्रांज़िशन इवेंट pageshow और pagehide हैं. ये इवेंट ज़्यादातर ब्राउज़र पर काम करते हैं.

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

देखें कि bfcache से किसी पेज को वापस कब वापस लाया गया है

जब पेज शुरू में लोड होता है और जब भी पेज bfcache से वापस लाया जाता है, तो pageshow इवेंट, load इवेंट के तुरंत बाद फ़ायर हो जाता है. pageshow इवेंट में persisted प्रॉपर्टी है. अगर पेज को bfcache से वापस लाया गया था, तो यह true प्रॉपर्टी होगी. अगर पेज को bfcache से वापस लाया गया था, तो false प्रॉपर्टी होगी. सामान्य पेज लोड और bfcache के तरीके को पहले जैसा करने वाले पेजों में अंतर करने के लिए, persisted प्रॉपर्टी का इस्तेमाल किया जा सकता है. उदाहरण के लिए:

window.addEventListener('pageshow', (event) => {
  if (event.persisted) {
    console.log('This page was restored from the bfcache.');
  } else {
    console.log('This page was loaded normally.');
  }
});

Page Lifecycle API के साथ काम करने वाले ब्राउज़र में resume इवेंट तब ट्रिगर होता है, जब bfcache (pageshow इवेंट के ठीक पहले) पेजों को वापस लाया जाता है. साथ ही, जब कोई उपयोगकर्ता, फ़्रीज़ किए गए बैकग्राउंड टैब पर फिर से जाता है. अगर आपको किसी पेज के स्टेटस को फ़्रीज़ होने के बाद अपडेट करना है (जिसमें bfcache में पेज शामिल हैं), तो resume इवेंट का इस्तेमाल किया जा सकता है. हालांकि, अगर आपको अपनी साइट की bfcache हिट रेट मेज़र करनी है, तो आपको pageshow इवेंट का इस्तेमाल करना होगा. कुछ मामलों में, आपको दोनों का इस्तेमाल करना पड़ सकता है.

Bfcache के मेज़रमेंट के सबसे सही तरीकों के बारे में जानने के लिए, bfcache के आंकड़ों और परफ़ॉर्मेंस को मेज़र करने के सबसे सही तरीकों का तरीका देखें.

देखें कि कोई पेज bfcache में पड़ रहा है या नहीं

pagehide इवेंट तब ट्रिगर होता है, जब कोई पेज अनलोड होता है या जब ब्राउज़र उसे bfcache में डालने की कोशिश करता है.

pagehide इवेंट में, persisted प्रॉपर्टी भी शामिल है. अगर यह false है, तो आपको इस बात का भरोसा है कि वह पेज बैक-फ़ॉरवर्ड कैश मेमोरी में सेव होने वाला नहीं है. हालांकि, persisted का true होना इस बात की गारंटी नहीं है कि पेज को कैश मेमोरी में सेव किया जाएगा. इसका मतलब है कि ब्राउज़र, पेज को कैश मेमोरी में सेव करने की intends रखता है. हालांकि, कुछ दूसरी वजहों से भी पेज को कैश मेमोरी में सेव नहीं करना पड़ सकता है.

window.addEventListener('pagehide', (event) => {
  if (event.persisted) {
    console.log('This page *might* be entering the bfcache.');
  } else {
    console.log('This page will unload normally and be discarded.');
  }
});

इसी तरह, अगर persisted true है, तो freeze इवेंट, pagehide इवेंट के तुरंत बाद ट्रिगर होता है. हालांकि, इसका मतलब यह है कि ब्राउज़र, पेज को कैश मेमोरी में सेव करने का intends लेता है. ऐसा हो सकता है कि इसे बाद में बताई गई कई वजहों से खारिज करना पड़े.

बैक-फ़ॉरवर्ड कैश मेमोरी के लिए, अपने पेजों को ऑप्टिमाइज़ करें

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

`unload` के बजाय, `pagehide` का इस्तेमाल करें

सभी ब्राउज़र में bfcache के लिए ऑप्टिमाइज़ करने का सबसे अहम तरीका यह है कि unload इवेंट लिसनर का इस्तेमाल न करें. इसके बजाय pagehide सुनें, क्योंकि यह किसी पेज के bfcache में जाने और unload के ट्रिगर होने पर, दोनों ट्रिगर होता है.

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

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

मोबाइल पर Chrome और Safari, unload इवेंट लिसनर वाले पेजों को कैश मेमोरी में सेव करने की कोशिश करते हैं, क्योंकि मोबाइल पर unload के भरोसेमंद न होने की वजह से, क्रैश होने का जोखिम कम हो जाता है. मोबाइल Firefox उन पेजों को bfcache के लिए अमान्य मानता है जो unload का इस्तेमाल नहीं करते. हालांकि, iOS पर, जिसमें सभी ब्राउज़र को WebKit रेंडरिंग इंजन का इस्तेमाल करना ज़रूरी होता है, ताकि यह Safari की तरह काम करे.

यह पता लगाने के लिए कि आपके पेज पर मौजूद कोई JavaScript, unload का इस्तेमाल करता है या नहीं, हमारा सुझाव है कि आप Lighthouse में no-unload-listeners ऑडिट का इस्तेमाल करें.

unload को रोकने के Chrome के प्लान के बारे में जानकारी के लिए, अनलोड इवेंट को रोकना देखें.

किसी पेज पर अनलोड हैंडलर का इस्तेमाल होने से रोकने के लिए, अनुमति से जुड़ी नीति का इस्तेमाल करना

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

Permission-Policy: unload()

सिर्फ़ शर्त के साथ `beforeunload` लिसनर जोड़ें

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

beforeunload के लिए इस्तेमाल के उदाहरण का एक उदाहरण, उपयोगकर्ता को चेतावनी देना है कि पेज को छोड़ने पर, उसने कुछ बदलाव सेव नहीं किए हैं. ऐसे मामले में, हमारा सुझाव है कि beforeunload लिसनर को सिर्फ़ तब जोड़ें, जब उपयोगकर्ता के बदलावों को सेव न किया गया हो. साथ ही, सेव नहीं किए गए बदलावों के सेव होने के तुरंत बाद उन्हें हटा दें, जैसा कि इस कोड में दिखाया गया है:

function beforeUnloadListener(event) {
  event.preventDefault();
  return event.returnValue = 'Are you sure you want to exit?';
};

// A function that invokes a callback when the page has unsaved changes.
onPageHasUnsavedChanges(() => {
  window.addEventListener('beforeunload', beforeUnloadListener);
});

// A function that invokes a callback when the page's unsaved changes are resolved.
onAllChangesSaved(() => {
  window.removeEventListener('beforeunload', beforeUnloadListener);
});

`Cache-Control: no-store` का इस्तेमाल कम से कम करें

Cache-Control: no-store एक एचटीटीपी हेडर वेब सर्वर है. यह ब्राउज़र को रिस्पॉन्स को किसी भी एचटीटीपी कैश मेमोरी में सेव न करने का निर्देश देता है. इसका इस्तेमाल उन रिसॉर्स के लिए किया जाता है जिनमें उपयोगकर्ता की संवेदनशील जानकारी होती है, जैसे कि लॉगिन के बाद वाले पेज.

हालांकि, bfcache कोई एचटीटीपी कैश मेमोरी नहीं है. हालांकि, अगर Cache-Control: no-store को पेज रिसॉर्स पर सेट किया गया है, तो ब्राउज़र ने पुराने पेजों को bfcache से हटा दिया है. हालांकि, यह किसी सबरिसॉर्स पर नहीं होता. Chrome, उपयोगकर्ता की निजता को बनाए रखते हुए इस तरीके को बदलने के लिए काम कर रहा है. हालांकि, डिफ़ॉल्ट रूप से, Cache-Control: no-store का इस्तेमाल करने वाले पेज बैक-फ़ॉरवर्ड कैश मेमोरी की सुविधा का इस्तेमाल नहीं कर सकते.

बैक-फ़ॉरवर्ड कैश मेमोरी को ऑप्टिमाइज़ करने के लिए, Cache-Control: no-store का इस्तेमाल सिर्फ़ उन पेजों पर करें जिनमें संवेदनशील जानकारी मौजूद है. इस जानकारी को कैश मेमोरी में सेव नहीं करना चाहिए.

ऐसे पेज जो हमेशा अप-टू-डेट कॉन्टेंट दिखाना चाहते हैं, लेकिन संवेदनशील जानकारी शामिल नहीं करना चाहते हैं, उनके लिए Cache-Control: no-cache या Cache-Control: max-age=0 का इस्तेमाल करें. ये ब्राउज़र को कॉन्टेंट दिखाने से पहले, उसे दोबारा पुष्टि करने के लिए कहते हैं. साथ ही, पेज की बैक-फ़ॉरवर्ड कैश मेमोरी की सुविधा को इस्तेमाल करने की ज़रूरी शर्तों पर कोई असर नहीं पड़ता, क्योंकि bfcache से किसी पेज को वापस लाने में एचटीटीपी कैश मेमोरी शामिल नहीं होती है.

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

bfcache रीस्टोर के बाद पुराना या संवेदनशील डेटा अपडेट करें

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

उदाहरण के लिए, अगर कोई उपयोगकर्ता किसी सार्वजनिक कंप्यूटर पर किसी साइट से साइन आउट करता है और अगला उपयोगकर्ता 'वापस जाएं' बटन पर क्लिक करता है, तो bfcache के पुराने डेटा में ऐसा निजी डेटा शामिल हो सकता है जो सबसे पहले उपयोगकर्ता ने लॉग आउट करते समय मिटाया था.

इस तरह की स्थितियों से बचने के लिए, pageshow इवेंट के बाद पेज को हमेशा अपडेट करें, अगर event.persisted true है:

window.addEventListener('pageshow', (event) => {
  if (event.persisted) {
    // Do any checks and updates to the page
  }
});

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

window.addEventListener('pageshow', (event) => {
  if (event.persisted && !document.cookie.match(/my-cookie)) {
    // Force a reload if the user has logged out.
    location.reload();
  }
});

विज्ञापन और बैक-फ़ॉरवर्ड कैश मेमोरी की सुविधा को पहले जैसा करना

bfcache के इस्तेमाल से बचना मुश्किल हो सकता है. इससे आपके पेज पर, बैक या फ़ॉरवर्ड नेविगेशन वाले हर नेविगेशन पर नए विज्ञापन दिख सकते हैं. हालांकि, यह साइट की परफ़ॉर्मेंस पर बुरा असर डालता है और विज्ञापन के साथ जुड़ाव में लगातार बढ़ोतरी नहीं करता. उदाहरण के लिए, ऐसा हो सकता है कि कोई उपयोगकर्ता किसी विज्ञापन पर क्लिक करने के लिए किसी पेज पर वापस जाए, लेकिन अगर पेज को bfcache से वापस लाने के बजाय फिर से लोड किया जाता है, तो हो सकता है कि वह दूसरा विज्ञापन दिखे. हमारा सुझाव है कि आप अपने पेज के लिए सबसे सही रणनीति तय करने के लिए, A/B टेस्टिंग का इस्तेमाल करें.

जिन साइटों को bfcache के डेटा को वापस लाने की सुविधा पर विज्ञापनों को रीफ़्रेश करना है उनके लिए, पेज की परफ़ॉर्मेंस पर असर डाले बिना event.persisted के true होने पर, सिर्फ़ pageshow इवेंट के विज्ञापनों को रीफ़्रेश किया जा सकता है. Google पब्लिशिंग टैग के इस उदाहरण में, इस उदाहरण में बताया गया है. अपनी साइट के लिए सबसे सही तरीकों के बारे में ज़्यादा जानने के लिए, अपने विज्ञापन देने वाली कंपनी से संपर्क करें.

`window.opener` रेफ़रंस का इस्तेमाल करने से बचें

पुराने ब्राउज़र में, अगर किसी पेज को target=_blank वाले लिंक से window.open() का इस्तेमाल करके खोला गया था, तो rel="noopener" को इससे जुड़ी जानकारी दिए बिना, शुरुआती पेज में खुले हुए पेज के विंडो ऑब्जेक्ट की जानकारी मिलेगी.

सुरक्षा जोखिम होने के अलावा, शून्य window.opener रेफ़रंस वाले पेज को सुरक्षित तरीके से बैक-फ़ॉरवर्ड कैश मेमोरी में नहीं रखा जा सकता. ऐसा इसलिए, क्योंकि इससे उन पेजों को ऐक्सेस नहीं किया जा सकता जो इसे ऐक्सेस करने की कोशिश करते हैं.

इन खतरों से बचने के लिए, rel="noopener" का इस्तेमाल करें, ताकि window.opener पहचान फ़ाइलें न बनाई जा सकें. यह सभी मॉडर्न ब्राउज़र में डिफ़ॉल्ट व्यवहार है. अगर आपकी साइट को कोई विंडो खोलनी है और window.postMessage() का इस्तेमाल करके या सीधे तौर पर विंडो ऑब्जेक्ट का इस्तेमाल करके, उसे कंट्रोल करना है, तो खुली विंडो या ओपनर, दोनों में से कोई भी ब्राउज़र को bfcache के लिए इस्तेमाल नहीं कर सकता.

उपयोगकर्ता के बाहर जाने से पहले, खुले कनेक्शन बंद करें

जैसा कि पहले बताया गया है, जब किसी पेज को बैक-फ़ॉरवर्ड कैश मेमोरी में सेव किया जाता है, तो शेड्यूल किए गए सभी JavaScript टास्क रोक दिए जाते हैं. साथ ही, जब पेज को कैश मेमोरी से हटा दिया जाता है, तो वह टास्क फिर से शुरू कर देता है.

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

हालांकि, अगर ये टास्क ऐसे एपीआई से कनेक्ट किए गए हैं जिन्हें एक ही ऑरिजिन के दूसरे पेजों से भी ऐक्सेस किया जा सकता है (उदाहरण के लिए: IndexedDB, Web Locks, और WebSockets), तो उन्हें रोकने से वे पेज टूट सकते हैं. इससे उन पेजों पर मौजूद कोड काम करना बंद कर सकते हैं.

इस वजह से, कुछ ब्राउज़र किसी पेज को bfcache में सेव करने की कोशिश नहीं करेंगे. ऐसा तब होगा, जब उस पेज में इनमें से कोई भी चीज़ हो:

ओपन IndexedDB कनेक्शन
पहले से मौजूद fetch() या XMLHttpRequest
ओपन WebSocket या WebRTC कनेक्शन

अगर आपका पेज इनमें से किसी भी एपीआई का इस्तेमाल कर रहा है, तो हमारा सुझाव है कि pagehide या freeze इवेंट के दौरान, कनेक्शन बंद करें और ऑब्ज़र्वर को हटाएं या डिसकनेक्ट करें. इससे ब्राउज़र, खुले हुए दूसरे टैब पर असर डाले बिना, पेज को सुरक्षित तरीके से कैश मेमोरी में सेव कर लेता है. इसके बाद, अगर पेज को bfcache से वापस लाया जाता है, तो pageshow या resume इवेंट के दौरान, उन एपीआई को फिर से खोला जा सकता है या उनसे फिर से कनेक्ट किया जा सकता है.

इस उदाहरण में यह पक्का करने का तरीका बताया गया है कि IndexedDB का इस्तेमाल करने वाले पेज, pagehide इवेंट सुनने वाले में ओपन कनेक्शन को बंद करके bfcache के लिए ज़रूरी शर्तें पूरी करें या नहीं:

let dbPromise;
function openDB() {
  if (!dbPromise) {
    dbPromise = new Promise((resolve, reject) => {
      const req = indexedDB.open('my-db', 1);
      req.onupgradeneeded = () => req.result.createObjectStore('keyval');
      req.onerror = () => reject(req.error);
      req.onsuccess = () => resolve(req.result);
    });
  }
  return dbPromise;
}

// Close the connection to the database when the user leaves.
window.addEventListener('pagehide', () => {
  if (dbPromise) {
    dbPromise.then(db => db.close());
    dbPromise = null;
  }
});

// Open the connection when the page is loaded or restored from bfcache.
window.addEventListener('pageshow', () => openDB());

जांच करके, यह पक्का करें कि आपके पेजों को कैश मेमोरी में सेव किया जा सकता है

Chrome DevTools की मदद से आपके पेजों की जांच की जा सकती है, ताकि यह पक्का किया जा सके कि उन्हें बैक-फ़ॉरवर्ड कैश मेमोरी के लिए ऑप्टिमाइज़ किया गया है. साथ ही, Chrome DevTools की मदद से उन समस्याओं की पहचान की जा सकती है जो उन्हें Google Search के नतीजों में दिखने से रोक सकती हैं.

किसी पेज की जांच करने के लिए:

Chrome में पेज पर जाएं.
DevTools में, ऐप्लिकेशन > बैक-फ़ॉरवर्ड कैश मेमोरी पर जाएं.
टेस्ट चलाएं बटन पर क्लिक करें. इसके बाद DevTools यह तय करने के लिए पेज पर वापस जाता है कि पेज को बैक-फ़ॉरवर्ड कैश मेमोरी से वापस लाया जा सकता है या नहीं.

DevTools में बैक-फ़ॉरवर्ड कैश मेमोरी पैनल — DevTools में **बैक-फ़ॉरवर्ड कैश मेमोरी** पैनल.

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

अगर डेवलपर के तौर पर इसे ठीक करने की वजह है, तो पैनल इसे कार्रवाई करने लायक के तौर पर मार्क करता है.

DevTools रिपोर्टिंग से, पेज को bfcache से वापस नहीं लाया जा सका — बैक-फ़ॉरवर्ड कैश मेमोरी की जांच नहीं हो सकी, लेकिन कार्रवाई करने लायक नतीजा मिला.

इस इमेज में दिखाया गया है कि unload इवेंट लिसनर का इस्तेमाल करने से पेज, bfcache के लिए ज़रूरी नहीं है. इसे ठीक करने के लिए, unload से pagehide पर स्विच करें:

ऐसा करें

window.addEventListener('pagehide', ...);

यह न करें

window.addEventListener('unload', ...);

Lighthouse 10.0 ने bfcache ऑडिट भी जोड़ा है. यह ऐसा ही जांच करता है. ज़्यादा जानकारी के लिए, bfcache ऑडिट के दस्तावेज़ देखें.

Bfcache कैसे आंकड़े और परफ़ॉर्मेंस मेज़रमेंट पर असर डालता है

अगर आपने अपनी साइट पर होने वाली विज़िट को ट्रैक करने के लिए किसी आंकड़ों वाले टूल का इस्तेमाल किया है, तो आपको रिपोर्ट किए गए पेज व्यू की कुल संख्या में कमी दिख सकती है. इसकी वजह यह है कि Chrome ज़्यादा उपयोगकर्ताओं के लिए bfcache की सुविधा चालू करता है.

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

अपने पेज व्यू की संख्या में bfcache के तरीके को पहले जैसा करने के लिए, pageshow इवेंट के लिए लिसनर सेट करें और persisted प्रॉपर्टी की जांच करें.

नीचे दिए गए उदाहरण में, Google Analytics की मदद से ऐसा करने का तरीका बताया गया है. दूसरे Analytics टूल शायद इसी तरह के लॉजिक का इस्तेमाल करते हों:

// Send a pageview when the page is first loaded.
gtag('event', 'page_view');

window.addEventListener('pageshow', (event) => {
  // Send another pageview if the page is restored from bfcache.
  if (event.persisted) {
    gtag('event', 'page_view');
  }
});

अपने बैक-फ़ॉरवर्ड कैश मेमोरी के हिट का अनुपात मापें

ऐसे पेजों की पहचान करने के लिए जिनमें अब तक bfcache का इस्तेमाल नहीं हुआ है, पेज लोड के लिए नेविगेशन टाइप को इस तरह मापें:

// Send a navigation_type when the page is first loaded.
gtag('event', 'page_view', {
   'navigation_type': performance.getEntriesByType('navigation')[0].type;
});

window.addEventListener('pageshow', (event) => {
  if (event.persisted) {
    // Send another pageview if the page is restored from bfcache.
    gtag('event', 'page_view', {
      'navigation_type': 'back_forward_cache';
    });
  }
});

back_forward नेविगेशन और back_forward_cache नेविगेशन की संख्या का इस्तेमाल करके अपने बैक-फ़ॉरवर्ड कैश मेमोरी के हिट अनुपात की गिनती करें.

बैक या फ़ॉरवर्ड नेविगेशन, बैक-फ़ॉरवर्ड कैश मेमोरी की सुविधा का इस्तेमाल न करने की कई वजहों से ऐसा कर सकता है. जैसे: उपयोगकर्ता का यह व्यवहार:

ब्राउज़र को बंद करके उसे रीस्टार्ट करना.
किसी टैब का डुप्लीकेट बनाया जा रहा है.
टैब को बंद करना और वापस लाना.

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

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

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

परफ़ॉर्मेंस मेज़रमेंट

bfcache फ़ील्ड में इकट्ठा की गई परफ़ॉर्मेंस मेट्रिक पर भी बुरा असर डाल सकता है. खास तौर पर, यह उन मेट्रिक पर असर डाल सकता है जो पेज लोड होने में लगने वाले समय को मापती हैं.

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

इस समस्या को हल करने के कुछ तरीके हैं. पहला तरीका है, पेज लोड होने वाली सभी मेट्रिक की जानकारी उनसे जुड़े नेविगेशन टाइप के साथ: navigate, reload, back_forward या prerender. इसकी मदद से, इस तरह के नेविगेशन में अपनी परफ़ॉर्मेंस पर नज़र रखी जा सकती है, भले ही पूरे डिस्ट्रिब्यूशन की वैल्यू खराब हो. हमारा सुझाव है कि आप यह तरीका टाइम टू फ़र्स्ट बाइट (TTFB) जैसी गैर-उपयोगकर्ता पर आधारित पेज लोड मेट्रिक के लिए इस्तेमाल करें.

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

वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी पर असर

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

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

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

bfcache हर मेट्रिक पर कैसे असर डालता है, इस बारे में ज़्यादा जानने के लिए, वेबसाइट की परफ़ॉर्मेंस को बेहतर बनाने वाले हर मेट्रिक की जानकारी देने वाले पेजों पर जाएं. इन मेट्रिक के bfcache वर्शन को लागू करने के खास उदाहरण के लिए, उन्हें वेब की अहम जानकारी वाली JS लाइब्रेरी में जोड़ना पेज देखें.

जानकारी पाने के दूसरे तरीके

Firefox कैशिंग (Firefox में bfcache)
पेज कैश (Safari में bfcache)
बैक/फ़ॉरवर्ड कैश मेमोरी: वेब एक्सपोज़्ड व्यवहार (अलग-अलग ब्राउज़र पर बैक-फ़ॉरवर्ड कैश मेमोरी में अंतर)
bfcache टेस्टर (टेस्ट करें कि ब्राउज़र में अलग-अलग एपीआई और इवेंट, बैक-फ़ॉरवर्ड कैश मेमोरी पर कैसे असर डालते हैं)
परफ़ॉर्मेंस गेम बदलने वाला टूल: ब्राउज़र का बैक/फ़ॉरवर्ड कैश मेमोरी (Smazing पत्रिका की एक केस स्टडी, जिसमें bfcache को चालू करके, वेबसाइट की परफ़ॉर्मेंस की जानकारी में बड़े पैमाने पर सुधार किया गया है)