Chrome में एक बदलाव किया जा रहा है, ताकि Cache-Control: no-store का इस्तेमाल करने वाले पेजों के लिए, बैक/फ़ॉरवर्ड कैश मेमोरी (bfcache) का इस्तेमाल तब किया जा सके, जब यह सुरक्षित हो. जानें कि डेवलपर के लिए इसका क्या मतलब है.
बैकग्राउंड
Cache-Control: no-store को एचटीटीपी हेडर के तौर पर सेट करने का मतलब है कि पेज को एचटीटीपी कैश मेमोरी में सेव नहीं किया जाना चाहिए. इसका इस्तेमाल उन पेजों के लिए किया जाना चाहिए जिनमें संवेदनशील डेटा शामिल है. उदाहरण के लिए, उन पेजों के लिए जिन पर कोई उपयोगकर्ता लॉग इन है. हालांकि, no-store डायरेक्टिव का इस्तेमाल अक्सर उन पेजों के लिए किया जाता है जिनमें संवेदनशील डेटा नहीं होता.
bfcache की मदद से, जब कोई उपयोगकर्ता किसी दूसरे पेज पर जाता है, तो हम पेज को मिटाने की प्रोसेस को रोक देते हैं. साथ ही, JS को एक्ज़ीक्यूट होने से रोक देते हैं. अगर उपयोगकर्ता जल्द ही वापस आता है, तो हम पेज को फिर से दिखाते हैं और JS को फिर से चलाते हैं. इससे, उपयोगकर्ता को पेज पर तुरंत नेविगेट करने की सुविधा मिलती है.
एचटीएमएल स्पेसिफ़िकेशन के मुताबिक, यह ज़रूरी नहीं है. हालांकि, ब्राउज़र आम तौर पर Cache-Control: no-store को सिग्नल के तौर पर लेते हैं, ताकि पेज को bfcache में सेव न किया जाए. bfcache का इस्तेमाल न किए जाने की सबसे बड़ी वजह यही है. मोबाइल पर इतिहास के 17% और डेस्कटॉप पर इतिहास के 7% नेविगेशन के लिए, bfcache का इस्तेमाल नहीं किया जाता. इसका मतलब है कि इन पेजों को तुरंत वापस लाने की सुविधा का फ़ायदा नहीं मिलता. साथ ही, इन पेजों को पूरी तरह से रीलोड करना पड़ता है. इसमें नेटवर्क कॉल, JavaScript को लागू करना, और रेंडरिंग शामिल है.
आम तौर पर, साइट में बदलाव होने पर कैश मेमोरी से जुड़ी समस्याओं से बचने के लिए Cache-Control: no-store को सेट किया जाता है. हालांकि, bfcache का इस्तेमाल करने पर यह वजह कम काम की होती है, क्योंकि पूरा पेज ठीक उसी तरह से वापस लाया जाता है जैसे वह पहले से खुला हुआ था.
Chrome इस व्यवहार को कैसे बदल रहा है
Chrome ने इस व्यवहार को बदलने का एलान किया है. हालांकि, वह इस बदलाव को सावधानी से लागू कर रहा है. हम Chrome 116 से एक्सपेरिमेंट कर रहे हैं. हाल ही तक, ये एक्सपेरिमेंट 5% पेज लोड पर चल रहे थे.
हमने 2 अक्टूबर को, पेज लोड के 10% तक इस सुविधा को बढ़ा दिया है. हमारा मकसद, नवंबर में इसे पेज लोड के 20% तक और अगले साल की शुरुआत में 50% तक बढ़ाना है. इसके बाद, हम इसे पूरी तरह से लॉन्च कर देंगे. इसके लिए, कुछ ऑप्ट आउट की सुविधाएं उपलब्ध होंगी. इनके बारे में आगे बताया गया है.
संवेदनशील जानकारी
हमारे विश्लेषण से पता चलता है कि बैक या फ़ॉरवर्ड नेविगेशन के ज़्यादातर पेजों में संवेदनशील डेटा शामिल नहीं होता. इसलिए, उन्हें बैक/फ़ॉरवर्ड कैश मेमोरी में सेव किया जा सकता है. हालांकि, कुछ मामलों में पेजों को बैक/फ़ॉरवर्ड कैश मेमोरी में सेव नहीं किया जाना चाहिए. उदाहरण के लिए, लॉग आउट करने के बाद, पीछे या आगे नेविगेट करके, लॉग इन किए गए पेज को वापस नहीं लाया जा सकता.
इससे बचने के लिए, Chrome कुकी में बदलाव होने या अनुमति देने के अन्य तरीकों के आधार पर, किसी पेज को bfcache से हटा देगा.
इसके अलावा, Cache-Control: no-store का इस्तेमाल करने वाले पेजों के लिए इन एपीआई का इस्तेमाल करने पर, वे पेज bfcache की ज़रूरी शर्तें पूरी नहीं करेंगे:
ध्यान दें कि यह उन एपीआई की पूरी सूची नहीं है जो bfcache के इस्तेमाल को रोकते हैं. हालांकि, यह उन एपीआई की सूची है जो Cache-Control: no-store पेजों पर bfcache को ब्लॉक करते हैं. भले ही, पेज छोड़ने के समय उनका इस्तेमाल न किया जा रहा हो.
Cache-Control: no-store पेजों के लिए, bfcache टाइम आउट को भी तीन मिनट कर दिया गया है. Cache-Control: no-store का इस्तेमाल न करने वाले पेजों के लिए, यह टाइम आउट 10 मिनट का होता है. इससे, जोखिम को और कम किया जा सकता है.
Enterprise के लिए ऑप्ट आउट
अक्सर, एंटरप्राइज़ में ऐसे सॉफ़्टवेयर और शेयर किए गए डिवाइस होते हैं जिन्हें अपडेट करना मुश्किल होता है. Cache-Control: no-store पेजों के लिए bfcache का इस्तेमाल रोकने के लिए, AllowBackForwardCacheForCacheControlNoStorePageEnabled नीति को बंद किया जा सकता है.
बदलाव की जांच करना
डेवलपर इस बदलाव की जांच, इस फ़्लैग की मदद से कर सकते हैं:
--enable-features=CacheControlNoStoreEnterBackForwardCache:level/restore-unless-cookie-change
अगर ऊपर बताई गई कोई भी शर्त लागू होती है, जैसे कि कुकी में बदलाव होना, तो पेज को bfcache का इस्तेमाल करने से रोक दिया जाएगा. इसकी वजह यह होगी कि "जिन पेजों के मुख्य संसाधन में Cache-Control: no-store है वे बैक/फ़ॉरवर्ड कैश मेमोरी में नहीं जा सकते." यह जानकारी, Chrome DevTools के bfcache टेस्टर में दिखेगी.
इस फ़्लैग के साथ और उसके बिना जांच करने के लिए, bfcache टेस्ट पेज का इस्तेमाल किया जा सकता है.
डेवलपर को क्या पता होना चाहिए
डेवलपर को अपने उपयोगकर्ताओं के लिए, bfcache के ज़्यादा इस्तेमाल से फ़ायदा पाने के लिए कोई बदलाव करने की ज़रूरत नहीं है. हालांकि, इस वजह से उन्हें कुछ बातों का ध्यान रखना पड़ सकता है. ये ऐसी ही समस्याएं थीं जिनका सामना, दिसंबर 2021 में bfcache के शुरुआती लॉन्च के दौरान, अन्य साइटों को करना पड़ा था.
परफ़ॉर्मेंस पर असर
हम यह बदलाव इसलिए कर रहे हैं, ताकि वेब पर उपयोगकर्ताओं को पेज की परफ़ॉर्मेंस बेहतर अनुभव मिल सके. जब हमने पहली बार bfcache लॉन्च किया था, तब हमें वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी देने वाली मेट्रिक में काफ़ी सुधार दिखे थे. अब हम इन सुधारों को ज़्यादा साइटों पर उपलब्ध कराना चाहते हैं.
इस सुविधा के रोल आउट होने के बाद, साइट के मालिकों को वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी में सुधार दिख सकता है. साथ ही, वे CrUX और CrUX डैशबोर्ड में, 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');
}
});
पेज को वापस लाने पर अपडेट मैनेज करना
अब साइटों को bfcache का इस्तेमाल दिख सकता है, जबकि पहले ऐसा नहीं होता था. साथ ही, जब पेज को नए डेटा के साथ पूरी तरह से रीलोड किया जाता है, तो डेवलपर bfcache को वापस लाने पर डेटा को रीफ़्रेश करने पर विचार कर सकते हैं.
अपडेट को उसी तरह ट्रिगर किया जा सकता है जिस तरह pageshow इवेंट का इस्तेमाल करके और persisted प्रॉपर्टी की जांच करके, Analytics के लिए अतिरिक्त पेज व्यू को लॉग किया जाता है.
ध्यान दें कि हर कॉन्टेंट को अपडेट करने की ज़रूरत नहीं होती. साथ ही, हो सकता है कि उपयोगकर्ता उस कॉन्टेंट पर "वापस" जाना चाहें जिसे उन्होंने पहले देखा था. उदाहरण के लिए, लेखों की सूची को रीफ़्रेश करने का मतलब यह हो सकता है कि उपयोगकर्ता को वह लेख न दिखे जिसे वह फिर से देखने जा रहा था.
विज्ञापनों पर असर
आंकड़ों पर असर की तरह ही, अगर विज्ञापन सिर्फ़ पेज लोड होने पर लोड होते हैं, तो साइटों को विज्ञापन इंप्रेशन में कमी दिख सकती है. bfcache को वापस लाने पर, विज्ञापनों को प्रोग्राम के हिसाब से रीफ़्रेश किया जा सकता है. इससे यह पक्का किया जा सकता है कि पूरे पेज के लोड होने के साथ-साथ विज्ञापन भी लोड हो रहे हों. इसके लिए, pageshow इवेंट का इस्तेमाल करके persisted प्रॉपर्टी की जांच की जाती है. हालांकि, ऐसा हमेशा सही नहीं होता. विज्ञापनों को रीफ़्रेश करने के तरीके के बारे में जानने के लिए, विज्ञापन देने वाली कंपनी के दस्तावेज़ देखें.
bfcache के बारे में ज़्यादा जानकारी
bfcache के बारे में ज़्यादा जानकारी के लिए, bfcache की पूरी तकनीकी गाइड देखें.
सुझाव/राय दें या शिकायत करें
हमें इस बदलाव के बारे में आपका सुझाव, शिकायत या राय चाहिए. इसके लिए, bfcache कॉम्पोनेंट का इस्तेमाल करके, Chrome के समस्या ट्रैकर पर जाएं.
नतीजा
हमें खुशी है कि हम bfcache का फ़ायदा कई और पेजों पर ला रहे हैं, ताकि उपयोगकर्ताओं को पेज का बेहतर अनुभव मिल सके. हमने इस बदलाव को ध्यान से समझा है. हमारा मकसद, इसे ज़्यादा से ज़्यादा सुरक्षित तरीके से रोल आउट करना है. हमें उम्मीद है कि यहां दी गई जानकारी से, डेवलपर को इस बदलाव को समझने में मदद मिलेगी. साथ ही, इस बदलाव के दौरान होने वाली समस्याओं से बचने के लिए, ज़रूरी बदलाव करने में भी मदद मिलेगी.