पब्लिश होने की तारीख: 21 अक्टूबर, 2024, पिछली बार अपडेट किए जाने की तारीख: 9 सितंबर, 2025
Chrome, बैक/फ़ॉरवर्ड कैश मेमोरी (bfcache) के इस्तेमाल में बदलाव कर रहा है. इससे Cache-Control: no-store का इस्तेमाल करने वाले पेजों के लिए, bfcache का इस्तेमाल किया जा सकेगा. हालांकि, ऐसा सिर्फ़ तब किया जाएगा, जब यह सुरक्षित हो. जानें कि इसका डेवलपर पर क्या असर पड़ेगा.
बैकग्राउंड
Cache-Control: no-store को एचटीटीपी हेडर के तौर पर सेट करने का मतलब है कि पेज को एचटीटीपी कैश मेमोरी में सेव नहीं किया जाना चाहिए. इसका इस्तेमाल उन पेजों के लिए किया जाना चाहिए जिनमें संवेदनशील डेटा होता है. उदाहरण के लिए, उन पेजों के लिए जब कोई उपयोगकर्ता लॉग इन होता है. हालांकि, no-store डायरेक्टिव का इस्तेमाल अक्सर उन पेजों पर किया जाता है जिनमें संवेदनशील डेटा नहीं होता.
bfcache की मदद से, जब कोई उपयोगकर्ता किसी पेज से हटता है, तो हम उसे डिस्ट्रॉय करने के बजाय, डिस्ट्रॉय करने की प्रोसेस को कुछ समय के लिए रोक देते हैं. साथ ही, JS के एक्ज़ीक्यूशन को भी रोक देते हैं. अगर उपयोगकर्ता तुरंत वापस आ जाता है, तो हम पेज को फिर से दिखने लगते हैं और JavaScript के एक्ज़ीक्यूशन को फिर से शुरू कर देते हैं. इससे उपयोगकर्ता को पेज पर तुरंत नेविगेट करने में मदद मिलती है.
एचटीएमएल स्पेसिफ़िकेशन के मुताबिक, इसकी ज़रूरत नहीं होती. हालांकि, ब्राउज़र आम तौर पर Cache-Control: no-store को एक सिग्नल के तौर पर लेते हैं, ताकि पेज को बैक/फ़ॉरवर्ड कैश मेमोरी में न रखा जाए. bfcache का इस्तेमाल न करने की यह सबसे बड़ी वजह है. मोबाइल पर, इतिहास में मौजूद पेजों पर नेविगेट करने के करीब 17% मामलों में और डेस्कटॉप पर, इतिहास में मौजूद पेजों पर नेविगेट करने के 7% मामलों में ऐसा होता है. इसका मतलब है कि इन पेजों को तेज़ी से वापस लाने की सुविधा का फ़ायदा नहीं मिलता. इसलिए, इन्हें पूरी तरह से फिर से लोड करना होगा. इसमें नेटवर्क कॉल, JavaScript को लागू करना, और रेंडरिंग शामिल है.
अक्सर साइट में बदलाव होने पर, कैश मेमोरी से जुड़ी समस्याओं से बचने के लिए Cache-Control: no-store को सेट किया जाता है. हालांकि, बैक/फ़ॉरवर्ड कैश मेमोरी का इस्तेमाल करने पर, यह वजह कम काम की होती है. ऐसा इसलिए, क्योंकि पूरा पेज इस तरह से वापस लाया जाता है जैसे उसे हमेशा खुला रखा गया हो.
Chrome इस व्यवहार में कैसे बदलाव कर रहा है
Chrome ने इस तरीके में बदलाव करने का एलान किया है. हालांकि, वह इस बदलाव को लेकर सावधानी बरत रहा है. हम Chrome 116 के बाद से एक्सपेरिमेंट कर रहे हैं. इसमें, पेज लोड होने की संख्या को धीरे-धीरे बढ़ाया जा रहा है. हमें उम्मीद है कि मार्च और अप्रैल 2025 तक, यह संख्या 100% तक पहुंच जाएगी.
संवेदनशील जानकारी
हमारे विश्लेषण से पता चलता है कि बैक या फ़ॉरवर्ड नेविगेशन के ज़्यादातर मामलों में संवेदनशील डेटा शामिल नहीं होता. इसलिए, उन्हें बैक/फ़ॉरवर्ड कैश मेमोरी में सेव किया जा सकता है. हालांकि, कुछ ऐसे मामले भी होते हैं जिनमें पेजों को बैक/फ़ॉरवर्ड कैश मेमोरी में सेव नहीं किया जाना चाहिए. उदाहरण के लिए, लॉग आउट करने के बाद, आगे या पीछे जाकर लॉग इन किए गए पेज को वापस नहीं लाया जा सकता.
इससे बचने के लिए, कुकी में बदलाव होने या पुष्टि करने के अन्य तरीकों में बदलाव होने पर, Chrome किसी पेज को bfcache से हटा देगा.
इसके अलावा, Cache-Control: no-store का इस्तेमाल करने वाले पेजों के लिए, इन एपीआई का इस्तेमाल करने पर, वे पेज बैक-फ़ॉरवर्ड कैश मेमोरी की सुविधा का इस्तेमाल नहीं कर पाएंगे:
ध्यान दें कि यह उन सभी एपीआई की पूरी सूची नहीं है जो बैक/फ़ॉरवर्ड कैश मेमोरी के इस्तेमाल को रोकते हैं. हालांकि, यह उन एपीआई की सूची है जो Cache-Control: no-store पेजों पर बैक/फ़ॉरवर्ड कैश मेमोरी को ब्लॉक करते हैं. भले ही, पेज छोड़ने के समय उनका इस्तेमाल न किया जा रहा हो.
जो पेज Cache-Control: no-store का इस्तेमाल नहीं करते हैं उनके लिए, बैक-फ़ॉरवर्ड कैश मेमोरी का टाइम आउट 10 मिनट होता है. हालांकि, Cache-Control: no-store का इस्तेमाल करने वाले पेजों के लिए, इसे घटाकर तीन मिनट कर दिया गया है. इससे जोखिम को और कम किया जा सकेगा.
Enterprise के लिए ऑप्ट-आउट करने वाले लोग
उद्यमों के पास अक्सर ऐसे सॉफ़्टवेयर और शेयर किए गए डिवाइस होते हैं जिन्हें अपडेट करना मुश्किल होता है. Cache-Control: no-store पेजों के लिए बैक-फ़ॉरवर्ड कैश मेमोरी के इस्तेमाल को रोकने के लिए, AllowBackForwardCacheForCacheControlNoStorePageEnabled नीति को बंद किया जा सकता है.
बदलाव की जांच करना
डेवलपर, इस बदलाव को इस फ़्लैग की मदद से टेस्ट कर सकते हैं:
--enable-features=CacheControlNoStoreEnterBackForwardCache:level/restore-unless-cookie-change
अगर इनमें से कोई भी अपवाद लागू होता है, जैसे कि कुकी बदलना, तो इससे पेज को बैक/फ़ॉरवर्ड कैश मेमोरी का इस्तेमाल करने से रोका जाएगा. Chrome DevTools bfcache टेस्टर में, "जिन पेजों के मुख्य संसाधन में Cache-Control: no-store है वे बैक/फ़ॉरवर्ड कैश मेमोरी में सेव नहीं किए जा सकते" की वजह दिखेगी.
इस फ़्लैग के साथ और इसके बिना जांच करने के लिए, इस bfcache टेस्ट पेज का इस्तेमाल किया जा सकता है.
डेवलपर को क्या पता होना चाहिए
ज़्यादा bfcache इस्तेमाल करने से उपयोगकर्ताओं को फ़ायदा मिलेगा. इसके लिए, डेवलपर को कोई बदलाव करने की ज़रूरत नहीं होगी. हालांकि, इस वजह से उन्हें कुछ बातों का ध्यान रखना पड़ सकता है. ये ऐसी ही समस्याएं हैं जो अन्य साइटों को दिसंबर 2021 में bfcache के शुरुआती लॉन्च के दौरान हुई थीं.
क्या डेवलपर को अब भी Cache-Control: no-store का इस्तेमाल कम करने की कोशिश करनी चाहिए?
ऊपर बताई गई सीमित शर्तों के तहत, Cache-Control: no-store के लिए bfcache की सुविधा चालू होती है. यह सुविधा सिर्फ़ Chrome के लिए उपलब्ध है. Cache-Control: no-store का इस्तेमाल करने पर, अन्य ब्राउज़र अब भी bfcache के इस्तेमाल को ब्लॉक कर सकते हैं.
सबसे सही तरीका यह है कि इन अनुमानित तरीकों पर भरोसा करने के बजाय, Cache-Control: no-store का इस्तेमाल कम से कम किया जाए.
परफ़ॉर्मेंस पर असर
हम यह बदलाव इसलिए कर रहे हैं, ताकि वेब पर लोगों को बेहतर पेज अनुभव मिल सके. जब हमने पहली बार bfcache लॉन्च किया था, तब हमने वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी देने वाली मेट्रिक में काफ़ी सुधार देखे थे. अब हम उन सुधारों को ज़्यादा साइटों पर लागू करना चाहते हैं.
इस सुविधा के लॉन्च होने के बाद, साइट के मालिकों को अपनी साइट की परफ़ॉर्मेंस की जानकारी में सुधार दिख सकता है. साथ ही, वे CrUX में bfcache के इस्तेमाल को मेज़र कर सकते हैं. इसमें CrUX Vis भी शामिल है.
इंपैक्ट से जुड़े आंकड़े
bfcache से वापस लाए गए पेज, पेज को फिर से लोड करने के बजाय पुराने पेज (इसमें JavaScript हीप भी शामिल है) को "वापस लाते हैं". ऐनलिटिक्स की सेवाएं देने वाली कई लोकप्रिय कंपनियां, bfcache से वापस लाए गए पेजों को नए पेज व्यू के तौर पर मेज़र नहीं करती हैं. ऐसा इसलिए, क्योंकि वे सिर्फ़ शुरुआती तौर पर लोड किए गए पेजों के लिए पेज व्यू ट्रिगर करती हैं.
इसलिए, पहली बार bfcache का इस्तेमाल करने पर, साइटों को अपने आंकड़ों में पेज लोड होने की संख्या में कमी दिख सकती है. हमारा सुझाव है कि इन्हें पेजव्यू के तौर पर माना जाए. इसके लिए, pageshow इवेंट के लिए लिसनर सेट करें और persisted प्रॉपर्टी की जांच करें:
// Send a pageview when the page is first loaded.
gtag('event', 'page_view');
// Send another pageview if the page is restored from bfcache.
window.addEventListener('pageshow', (event) => {
if (event.persisted) {
// Page was restored from bfcache, sent another page view.
gtag('event', 'page_view');
}
});
पेज को वापस लाने पर अपडेट मैनेज करना
ऐसा हो सकता है कि साइटों को अब बैक-फ़ॉरवर्ड कैश मेमोरी के इस्तेमाल के बारे में पता चले. पहले उन्हें इसके बारे में पता नहीं था. साथ ही, ऐसा भी हो सकता है कि पेज को नए डेटा के साथ पूरी तरह से फिर से लोड किया गया हो. ऐसे में, डेवलपर को बैक-फ़ॉरवर्ड कैश मेमोरी से पेज वापस लाने पर डेटा को रीफ़्रेश करने के बारे में सोचना चाहिए.
pageshow इवेंट का इस्तेमाल करके, Analytics के लिए अतिरिक्त पेज व्यू लॉग करने के तरीके से ही अपडेट ट्रिगर किए जा सकते हैं. साथ ही, persisted प्रॉपर्टी की जांच की जा सकती है.
ध्यान दें कि सभी कॉन्टेंट को अपडेट करने की ज़रूरत नहीं है. ऐसा हो सकता है कि उपयोगकर्ता, उस कॉन्टेंट पर वापस जाना चाहें जिसे उन्होंने पहले देखा था. उदाहरण के लिए, लेखों की सूची को रीफ़्रेश करने का मतलब यह हो सकता है कि उपयोगकर्ता को वह लेख अब न दिखे जिसे वह वापस देखना चाहता था.
विज्ञापनों पर असर
Analytics पर पड़ने वाले असर की तरह ही, अगर विज्ञापन सिर्फ़ पेज लोड होने पर लोड होते हैं, तो साइटों को विज्ञापन इंप्रेशन में कमी दिख सकती है. bfcache को रीस्टोर करने पर, विज्ञापनों को प्रोग्राम के हिसाब से रीफ़्रेश किया जा सकता है. इससे यह पक्का होता है कि वे पूरे पेज लोड के साथ काम करें. इसके लिए, pageshow इवेंट का इस्तेमाल किया जाता है और persisted प्रॉपर्टी की जांच की जाती है. हालांकि, ऐसा करना हमेशा सही नहीं होता. विज्ञापन देने वाली कंपनी के दस्तावेज़ देखें. इसमें बताया गया है कि विज्ञापन फिर से लोड करने की सुविधा को कैसे ट्रिगर किया जाता है.
bfcache के बारे में ज़्यादा जानकारी
bfcache के बारे में ज़्यादा जानने के लिए, bfcache से जुड़ी हमारी तकनीकी गाइड देखें.
सुझाव/राय दें या शिकायत करें
हम इस बदलाव के बारे में आपके सुझाव, शिकायत या राय का इंतज़ार कर रहे हैं. इसके लिए, bfcache कॉम्पोनेंट का इस्तेमाल करके, Chrome के इश्यू ट्रैकर में सुझाव, शिकायत या राय दी जा सकती है.
नतीजा
हमें इस बात की खुशी है कि हम ज़्यादा से ज़्यादा पेजों पर बीएफ़कैश की सुविधा उपलब्ध करा रहे हैं, ताकि उपयोगकर्ताओं को बेहतर अनुभव मिल सके. हमने इस बदलाव पर काफ़ी सोच-विचार किया है. हमारा तरीका यह है कि इसे ज़्यादा से ज़्यादा सुरक्षित तरीके से रोल आउट किया जाए. हमें उम्मीद है कि यहां दी गई जानकारी से, डेवलपर को इस बदलाव को समझने में मदद मिलेगी. साथ ही, वे इस बदलाव के लागू होने पर आने वाली समस्याओं से बचने के लिए ज़रूरी बदलाव कर पाएंगे.