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

ब्राउज़र के 'वापस जाएं' और 'आगे बढ़ें' बटन का इस्तेमाल करते समय, अपने पेज को झटपट लोड होने के लिए ऑप्टिमाइज़ करें.

फ़िलिप वॉल्टन

बैरी पोलार्ड

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

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

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

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

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

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

bfcache एक इन-मेमोरी कैश मेमोरी है. जब उपयोगकर्ता नेविगेट करता है, तब यह पेज का पूरा स्नैपशॉट (JavaScript हीप भी शामिल) सेव करता है. मेमोरी में पूरा पेज होने पर, अगर उपयोगकर्ता वापस आकर पेज पर वापस जाता है, तो ब्राउज़र उसे तेज़ी और आसानी से वापस ला सकता है.

किसी वेबसाइट पर जाने और किसी दूसरे पेज पर जाने के लिए, आपने किसी लिंक पर कितनी बार क्लिक किया, लेकिन आपको यह पता होना चाहिए कि वह वेबसाइट आपकी पसंद नहीं है. इसलिए, 'वापस जाएं' बटन पर क्लिक करें? ऐसे में, bfcache इस बात का बड़ा फ़र्क़ डाल सकता है कि पिछला पेज कितनी तेज़ी से लोड होता है:

बैक-फ़ॉरवर्ड कैश मेमोरी की सुविधा का इस्तेमाल करके बनाए गए इस वीडियो को देखें. इससे आपको पता चलेगा कि इससे नेविगेशन में कितनी तेज़ी आएगी:

ऊपर दिए गए वीडियो में, bfcache के साथ दिया गया उदाहरण, इसके बिना दिए गए उदाहरण से काफ़ी तेज़ है.

bfcache न सिर्फ़ नेविगेशन को तेज़ करता है, बल्कि डेटा खर्च को भी कम करता है, क्योंकि संसाधनों को दोबारा डाउनलोड करने की ज़रूरत नहीं होती.

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

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

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

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

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

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

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

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

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

bfcache के लिए एपीआई

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

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

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

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

जब पेज शुरू में लोड होता है और जब भी पेज bfcache से वापस लाया जाता है, तो pageshow इवेंट, load इवेंट के तुरंत बाद फ़ायर हो जाता है. pageshow इवेंट में एक persisted प्रॉपर्टी है, जो true अगर पेज को bfcache से वापस लाया गया था, तो होगा. अगर ऐसा नहीं है, तो false. सामान्य पेज लोड और बैक-फ़ॉरवर्ड कैश मेमोरी की सुविधा में अंतर करने के लिए, 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 में पड़ रहा है या नहीं

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

pagehide इवेंट में persisted प्रॉपर्टी भी है. अगर यह false है, तो आपको पता है कि पेज bfcache डालने वाला नहीं है. हालांकि, अगर 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.');
  }
});

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

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

सभी पेज बैक-फ़ॉरवर्ड कैश मेमोरी में सेव नहीं होते. यहां तक कि किसी पेज के वहां सेव होने के बाद भी, वह हमेशा वहां नहीं रहेगा. डेवलपर के लिए यह समझना ज़रूरी है कि कैश-हिट दर बढ़ाने के लिए, पेज को कौनसी चीज़ें bfcache के लिए ज़रूरी (और शर्तें पूरी न करने वाली) बनाती हैं.

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

unload इवेंट का इस्तेमाल कभी न करें

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

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

ऐसे में ब्राउज़र के सामने दुविधा होती है कि उन्हें ऐसी चीज़ों में से किसी एक को चुनना पड़ता है, जिससे उपयोगकर्ता अनुभव तो बेहतर हो सकता है—लेकिन उससे पेज खराब होने का खतरा भी होता है.

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

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

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

दरअसल, Lighthouse में no-unload-listeners ऑडिट होता है, जो डेवलपर को चेतावनी देगा कि अगर उनके पेजों (इसमें तीसरे पक्ष की लाइब्रेरी का JavaScript भी शामिल है) पर कोई JavaScript unload इवेंट लिसनर को जोड़ता है.

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

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

जो साइटें unload इवेंट हैंडलर का इस्तेमाल नहीं करती हैं वे यह पक्का कर सकती हैं कि इन्हें Chrome 115 की अनुमतियों की नीति का इस्तेमाल करके नहीं जोड़ा गया है.

Permission-Policy: unload()

यह तीसरे पक्षों या एक्सटेंशन को अनलोड हैंडलर जोड़कर और साइट को bfcache के लिए ज़रूरी शर्तों को पूरा नहीं करके, साइट की परफ़ॉर्मेंस को धीमा करने से रोकता है.

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

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

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

window.addEventListener('beforeunload', (event) => {
  if (pageHasUnsavedChanges()) {
    event.preventDefault();
    return event.returnValue = 'Are you sure you want to exit?';
  }
});

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 को पेज रिसॉर्स पर (किसी भी सबरिसॉर्स के बजाय) सेट किया जाता है, तो ब्राउज़र ने पेज को बैक-फ़ॉरवर्ड कैश मेमोरी में सेव न करने का विकल्प चुना है. निजता बनाए रखने के लिए, Chrome के लिए इस तरीके को बदलने पर काम चल रहा है. फ़िलहाल, Cache-Control: no-store का इस्तेमाल करने वाले सभी पेज बैक-फ़ॉरवर्ड कैश मेमोरी की सुविधा का इस्तेमाल नहीं कर पाएंगे.

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

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

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

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

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

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

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

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

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

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 के लिंक से, rel="noopener" को बताए बिना ही window.open() का इस्तेमाल करके खोला गया था, तो शुरुआती पेज पर, खुले हुए पेज के विंडो ऑब्जेक्ट की जानकारी मिलेगी.

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

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

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

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

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

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

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

• ओपन 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 is leaving.
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 की मदद से उन समस्याओं की पहचान की जा सकती है जो उन्हें मंज़ूरी नहीं दे पा रही हैं.

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

अगर बदलाव हो जाता है, तो पैनल को "बैक-फ़ॉरवर्ड कैश मेमोरी से वापस लाया गया" रिपोर्ट दिखेगा:

अगर ऐसा नहीं हो पाता है, तो पैनल दिखाएगा कि पेज को वापस नहीं लाया गया था. साथ ही, इसमें इसकी वजह भी बताई जाएगी.

अगर डेवलपर के तौर पर वजह से आप इसे ठीक कर सकते हैं, तो यह भी बताया जाएगा:

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

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

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

Lighthouse 10.0 ने bfcache ऑडिट भी जोड़ा है. यह एक DevTools की तरह ही जांच करता है. साथ ही, यह भी बताता है कि अगर ऑडिट पूरा नहीं हो पाता है, तो पेज को मंज़ूरी क्यों नहीं मिलती. ज़्यादा जानकारी के लिए bfcache ऑडिट के दस्तावेज़ देखें.

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

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

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

अगर आप नहीं चाहते कि Chrome में bfcache चालू होने की वजह से आपके पेज व्यू की संख्या कम हो, तो pageshow इवेंट को सुनकर और persisted प्रॉपर्टी की जांच करके, bfcache को वापस लाने की रिपोर्ट पेज व्यू (सुझाया गया) के तौर पर रिपोर्ट की जा सकती है.

नीचे दिए गए उदाहरण में Google 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 का इस्तेमाल किया गया था या नहीं. इससे, उन पेजों की पहचान की जा सकेगी जो 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 के अनुपात को देखकर, बैक-फ़ॉरवर्ड कैश मेमोरी के अनुपात का पता लगाया जा सकता है.

इस बात का ध्यान रखना ज़रूरी है कि ऐसी कई स्थितियां हैं जो साइट के मालिकों के कंट्रोल के बाहर हैं, जब बैक/फ़ॉरवर्ड नेविगेशन की सुविधा bfcache का इस्तेमाल नहीं करेगी, जिनमें ये शामिल हैं:

• जब उपयोगकर्ता ब्राउज़र से बाहर निकलकर उसे फिर से शुरू करता है
• जब उपयोगकर्ता किसी टैब का डुप्लीकेट बनाता है
• जब उपयोगकर्ता किसी टैब को बंद करके उसे खोलता है

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

इन एक्सक्लूज़न के बिना भी मेमोरी बचाने के लिए, एक तय समय के बाद bfcache को खारिज कर दिया जाएगा.

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

Chrome की टीम एक NotRestoredReasons एपीआई पर काम कर रही है. इससे डेवलपर को यह समझने में मदद मिलेगी कि bfcache के इस्तेमाल न होने की वजहें क्या हैं. इससे, डेवलपर को यह समझने में मदद मिलेगी कि कैश मेमोरी का इस्तेमाल क्यों नहीं किया गया है. साथ ही, वे यह भी समझ पाएंगे कि वे अपनी साइटों को बेहतर बनाने के लिए, किन चीज़ों पर काम कर सकते हैं.

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

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

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

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

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

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

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

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

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

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

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

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

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

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