Chrome में एक बदलाव किया जा रहा है, ताकि Cache-Control: no-store का इस्तेमाल करने वाले पेजों के लिए, बैक/फ़ॉरवर्ड कैश मेमोरी (bfcache) का इस्तेमाल तब किया जा सके, जब यह सुरक्षित हो. जानें कि डेवलपर के लिए इसका क्या मतलब है.
बैकग्राउंड
Cache-Control: no-store को एचटीटीपी हेडर के तौर पर सेट करने का मतलब है कि पेज को एचटीटीपी कैश मेमोरी में सेव नहीं किया जाना चाहिए. इसका इस्तेमाल उन पेजों के लिए किया जाना चाहिए जिनमें संवेदनशील डेटा शामिल है. उदाहरण के लिए, उन पेजों के लिए जिन पर कोई उपयोगकर्ता लॉग इन है. हालांकि, no-store डायरेक्टिव का इस्तेमाल अक्सर उन पेजों के लिए किया जाता है जिनमें संवेदनशील डेटा नहीं होता.
bfcache की मदद से, जब कोई उपयोगकर्ता किसी दूसरे पेज पर जाता है, तो हम पेज को मिटाने की प्रोसेस को रोक देते हैं. साथ ही, JS को एक्ज़ीक्यूट होने से रोक देते हैं. अगर उपयोगकर्ता जल्द ही वापस आता है, तो हम पेज को फिर से दिखाते हैं और JS को फिर से चलाते हैं. इससे उपयोगकर्ता को झटपट पेज नेविगेशन मिलता है.
एचटीएमएल स्पेसिफ़िकेशन के मुताबिक, Cache-Control: no-store को शामिल करना ज़रूरी नहीं है. हालांकि, आम तौर पर ब्राउज़र, पेज को bfcache में सेव करने से बचने के लिए, Cache-Control: no-store को सिग्नल के तौर पर लेते हैं. 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 टेस्ट पेज का इस्तेमाल किया जा सकता है.
डेवलपर को क्या पता होना चाहिए
बैंक खाते के ज़्यादा इस्तेमाल से होने वाले फ़ायदे पाने के लिए, डेवलपर को अपने उपयोगकर्ताओं के लिए कोई बदलाव करने की ज़रूरत नहीं है. हालांकि, इसके लिए उन्हें कुछ चीज़ों का ध्यान रखना पड़ सकता है. ये ऐसी ही वजहें थीं जिन्हें शायद दिसंबर 2021 में bfcache के शुरुआती लॉन्च के दौरान दूसरी साइटों को अनुभव हुआ हो.
परफ़ॉर्मेंस पर असर
हम यह बदलाव इसलिए कर रहे हैं, ताकि वेब पर उपयोगकर्ताओं को पेज का बेहतर अनुभव मिल सके. जब हमने पहली बार bfcache लॉन्च किया था, तब हमें वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी देने वाली मेट्रिक में काफ़ी सुधार दिखे थे. अब हम इन सुधारों को ज़्यादा साइटों पर उपलब्ध कराना चाहते हैं.
इस सुविधा के रोल आउट होने पर, साइट के मालिकों को वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी में सुधार दिख सकता है. साथ ही, वे CrUX और CrUX डैशबोर्ड में, bfcache के इस्तेमाल को मेज़र कर सकते हैं.
असर के आंकड़े
bfcache से वापस लाए गए पेज, पेज को फिर से लोड करने के बजाय पुराने पेज (जिसमें 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 इवेंट का इस्तेमाल करके और persisted प्रॉपर्टी की जांच करके, Analytics के लिए अतिरिक्त पेज व्यू को लॉग करने के तरीके से ही अपडेट ट्रिगर किए जा सकते हैं.
ध्यान दें कि सारे कॉन्टेंट को अपडेट करने की ज़रूरत नहीं होती है. ऐसा हो सकता है कि उपयोगकर्ता, पिछली बार देखे गए कॉन्टेंट को "वापस जाकर" देखना पसंद करें. उदाहरण के लिए, लेखों की सूची को रीफ़्रेश करने का मतलब यह हो सकता है कि उपयोगकर्ता को वह लेख न दिखे जिसे वह फिर से देखना चाहता था.
विज्ञापनों पर असर
आंकड़ों पर पड़ने वाले असर की तरह ही, अगर विज्ञापन सिर्फ़ पेज लोड होने पर लोड होते हैं, तो साइटों को विज्ञापन इंप्रेशन में कमी दिख सकती है. bfcache को वापस लाने पर, विज्ञापनों को प्रोग्राम के हिसाब से रीफ़्रेश किया जा सकता है. इससे, यह पक्का किया जा सकता है कि पूरे पेज के लोड होने के साथ-साथ विज्ञापन भी लोड हो रहे हों. इसके लिए, pageshow इवेंट का इस्तेमाल करके persisted प्रॉपर्टी की जांच की जाती है. हालांकि, ऐसा हमेशा सही नहीं होता. विज्ञापनों को रीफ़्रेश करने के तरीके के बारे में जानने के लिए, विज्ञापन देने वाली कंपनी के दस्तावेज़ देखें.
bfcache के बारे में ज़्यादा जानकारी
bfcache के बारे में ज़्यादा जानकारी के लिए, हमारी bfcache की तकनीकी गाइड देखें.
सुझाव/राय दें या शिकायत करें
हमें इस बदलाव के बारे में आपका सुझाव, शिकायत या राय चाहिए. इसके लिए, bfcache कॉम्पोनेंट का इस्तेमाल करके, Chrome के समस्या ट्रैकर पर जाएं.
नतीजा
हमें खुशी है कि हम bfcache का फ़ायदा कई और पेजों पर ला रहे हैं, ताकि उपयोगकर्ताओं को पेज का बेहतर अनुभव मिल सके. हमने इस बदलाव को ध्यान से समझा है. हमारा मकसद, इसे ज़्यादा से ज़्यादा सुरक्षित तरीके से रोल आउट करना है. हमें उम्मीद है कि यहां दी गई जानकारी से डेवलपर को इस बदलाव को समझने में मदद मिलेगी. साथ ही, इससे उन्हें किसी भी ज़रूरी बदलाव को करने में मदद मिलेगी, ताकि ऐसा होने पर समस्याओं से बचा जा सके.