पब्लिश होने की तारीख: 21 अक्टूबर, 2024, पिछली बार अपडेट किए जाने की तारीख: 9 सितंबर, 2025
Chrome, बैक/फ़ॉरवर्ड कैश (bfcache) के इस्तेमाल में बदलाव कर रहा है. इससे Cache-Control: no-store का इस्तेमाल करने वाले पेजों के लिए, bfcache का इस्तेमाल किया जा सकेगा. हालांकि, ऐसा सिर्फ़ तब किया जाएगा, जब bfcache का इस्तेमाल करना सुरक्षित हो. जानें कि इसका डेवलपर पर क्या असर पड़ेगा.
बैकग्राउंड
Cache-Control: no-store को एचटीटीपी हेडर के तौर पर सेट करने का मतलब है कि पेज को एचटीटीपी कैश मेमोरी में सेव नहीं किया जाना चाहिए. इसका इस्तेमाल उन पेजों के लिए किया जाना चाहिए जिनमें संवेदनशील डेटा मौजूद हो. उदाहरण के लिए, उन पेजों के लिए जब कोई उपयोगकर्ता लॉग इन हो. हालांकि, no-store डायरेक्टिव का इस्तेमाल अक्सर उन पेजों पर किया जाता है जिनमें संवेदनशील डेटा नहीं होता.
bfcache की मदद से, जब उपयोगकर्ता किसी पेज से हट जाता है, तो हम उसे डिस्ट्रॉय करने के बजाय, डिस्ट्रॉय करने की प्रोसेस को कुछ समय के लिए रोक देते हैं. साथ ही, JS के एक्ज़ीक्यूशन को भी रोक देते हैं. अगर उपयोगकर्ता तुरंत वापस आ जाता है, तो हम पेज को फिर से दिखने लगते हैं और JavaScript के एक्ज़ीक्यूशन को फिर से शुरू कर देते हैं. इससे उपयोगकर्ता को पेज पर तुरंत नेविगेट करने में मदद मिलती है.
एचटीएमएल स्पेसिफ़िकेशन के मुताबिक, इसकी ज़रूरत नहीं होती. हालांकि, ब्राउज़र आम तौर पर Cache-Control: no-store को एक सिग्नल के तौर पर लेते हैं, ताकि पेज को बैक/फ़ॉरवर्ड कैश मेमोरी में न रखा जाए. bfcache का इस्तेमाल न करने की यह सबसे बड़ी वजह है. मोबाइल पर, इतिहास में मौजूद पेजों पर नेविगेट करने के करीब 17% मामलों में और डेस्कटॉप पर, इतिहास में मौजूद पेजों पर नेविगेट करने के 7% मामलों में ऐसा होता है. इसका मतलब है कि इन पेजों को तेज़ी से रीस्टोर करने का फ़ायदा नहीं मिलता. साथ ही, इन्हें पूरा पेज फिर से लोड करना पड़ता है. इसमें नेटवर्क कॉल, JavaScript को लागू करना, और रेंडरिंग शामिल है.
अक्सर Cache-Control: no-store को इसलिए सेट किया जाता है, ताकि साइट में बदलाव होने पर कैश मेमोरी से जुड़ी समस्याओं से बचा जा सके. हालांकि, bfcache का इस्तेमाल करने पर यह वजह कम काम की होती है. ऐसा इसलिए, क्योंकि पूरा पेज इस तरह से वापस लाया जाता है जैसे उसे हमेशा खुला रखा गया हो.
Chrome इस व्यवहार में कैसे बदलाव कर रहा है
Chrome ने इस तरीके में बदलाव करने का एलान किया है. हालांकि, वह इस बदलाव को लेकर काफ़ी सतर्क है. हम Chrome 116 से एक्सपेरिमेंट कर रहे हैं. इसमें पेज लोड होने की संख्या को धीरे-धीरे बढ़ाया जा रहा है. उम्मीद है कि मार्च और अप्रैल 2025 तक, यह संख्या 100% तक पहुंच जाएगी.
संवेदनशील डेटा
हमारे विश्लेषण से पता चलता है कि बैक या फ़ॉरवर्ड नेविगेशन के ज़्यादातर मामलों में संवेदनशील डेटा शामिल नहीं होता. इसलिए, इन्हें बैक/फ़ॉरवर्ड कैश मेमोरी में सेव किया जा सकता है. हालांकि, कुछ ऐसे मामले भी होते हैं जिनमें पेजों को बैक/फ़ॉरवर्ड कैश मेमोरी में सेव नहीं किया जाना चाहिए. उदाहरण के लिए, लॉग आउट करने के बाद, आगे या पीछे जाकर लॉग इन किए गए पेज को वापस नहीं लाया जा सकता.
इससे बचने के लिए, कुकी में बदलाव होने या पुष्टि करने के अन्य तरीकों में बदलाव होने पर, Chrome किसी पेज को bfcache से हटा देगा.
इसके अलावा, Cache-Control: no-store का इस्तेमाल करने वाले पेजों के लिए, यहां दिए गए एपीआई का इस्तेमाल करने पर, वे पेज बैक-फ़ॉरवर्ड कैश मेमोरी की सुविधा का इस्तेमाल नहीं कर पाएंगे:
इसके अलावा, अगर कोई Cache-control: no-store पेज फ़ेच या XHR अनुरोध करता है और उसके जवाब में Cache-control: no-store मिलता है, तो इस पेज को भी हटा दिया जाएगा. ऐसा इसलिए, क्योंकि इसमें संवेदनशील डेटा हो सकता है.
ध्यान दें कि यह उन सभी एपीआई की पूरी सूची नहीं है जो बैक/फ़ॉरवर्ड कैश मेमोरी के इस्तेमाल को रोकते हैं. हालांकि, यह उन एपीआई की सूची है जो Cache-Control: no-store पेजों पर बैक/फ़ॉरवर्ड कैश मेमोरी को ब्लॉक करते हैं. भले ही, पेज छोड़ने के समय उनका इस्तेमाल न किया जा रहा हो.
Cache-Control: no-store पेजों के लिए, बैक-फ़ॉरवर्ड कैश मेमोरी के टाइम आउट को भी घटाकर तीन मिनट कर दिया गया है. पहले, Cache-Control: no-store का इस्तेमाल न करने वाले पेजों के लिए यह 10 मिनट था. ऐसा जोखिम को और कम करने के लिए किया गया है.
एंटरप्राइज़ के लिए ऑप्ट आउट करने की सुविधा
उद्यमों के पास अक्सर ऐसे सॉफ़्टवेयर और शेयर किए गए डिवाइस होते हैं जिन्हें अपडेट करना मुश्किल होता है. 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 भी शामिल है.
इंपैक्ट से जुड़े आंकड़े
बैक/फ़ॉरवर्ड कैश मेमोरी से वापस लाए गए पेज, पेज को फिर से लोड करने के बजाय पुराने पेज (इसमें JavaScript हीप भी शामिल है) को "वापस लाते हैं". ऐनलिटिक्स सेवाएं देने वाली कई लोकप्रिय कंपनियां, बीएफ़कैश से वापस लाए गए पेजों को नए पेज व्यू के तौर पर मेज़र नहीं करती हैं. ऐसा इसलिए, क्योंकि वे पेज व्यू को सिर्फ़ तब ट्रिगर करती हैं, जब उन्हें पहली बार लोड किया जाता है.
इसलिए, पहली बार 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 के इश्यू ट्रैकर में सुझाव, शिकायत या राय दी जा सकती है.
नतीजा
हम बीएफ़कैश की सुविधा को ज़्यादा से ज़्यादा पेजों पर उपलब्ध कराने के लिए उत्साहित हैं, ताकि उपयोगकर्ताओं को बेहतर पेज अनुभव मिल सके. हमने इस बदलाव पर काफ़ी सोच-विचार किया है. हमारा तरीका यह है कि इसे ज़्यादा से ज़्यादा सुरक्षित तरीके से रोल आउट किया जाए. हमें उम्मीद है कि यहां दी गई जानकारी से, डेवलपर को इस बदलाव को समझने में मदद मिलेगी. साथ ही, वे इस बदलाव के लागू होने पर आने वाली समस्याओं से बचने के लिए, ज़रूरी बदलाव कर पाएंगे.