आपका एनालिटिक्स स्क्रिप्ट शायद बैक/फॉरवर्ड कैश को डिसेबल कर रहा है
बैक/फॉरवर्ड कैश बैक-बटन नेविगेशन को लगभग तुरंत बना देता है, लेकिन एक भी unload listener इसे पूरे पेज के लिए बंद कर देता है। ट्रैकिंग स्क्रिप्ट्स आमतौर पर इसके दोषी होते हैं — और अब CrUX इस नुकसान को मापता है।
वेब पर सबसे तेज़ नेविगेशन वही है जिसमें कुछ भी लोड नहीं होता। बैक/फॉरवर्ड कैश (bfcache) ठीक यही देता है — और आपके एनालिटिक्स वेंडर के स्क्रिप्ट में एक ही लाइन इसे आपकी साइट के हर पेज के लिए बंद कर सकती है।
bfcache एक ब्राउज़र ऑप्टिमाइज़ेशन है जो किसी पेज का पूरा इन-मेमोरी स्नैपशॉट — JavaScript heap सहित — तब रख लेता है जब यूज़र दूसरी जगह नेविगेट करता है। बैक बटन दबाइए और ब्राउज़र उस स्नैपशॉट को रीस्टोर कर देता है और एक्ज़ीक्यूशन को फिर से शुरू कर देता है, जिससे बिना किसी नेटवर्क रिक्वेस्ट के लगभग तुरंत लोड होता है। बैक और फॉरवर्ड नेविगेशन अनुमानित रूप से सभी नेविगेशन का 10–20% होते हैं, इसलिए यह कोई edge case नहीं है।
एक ही Listener पूरे पेज को अयोग्य कर देता है
bfcache की पात्रता डिज़ाइन के हिसाब से ही नाज़ुक है। ब्राउज़र ऐसे किसी पेज को फ़्रीज़ नहीं करेगा जिसने unload event listener रजिस्टर किया हो, क्योंकि unload का मतलब है कि पेज को नष्ट किए जाने की उम्मीद है। डेस्कटॉप पर, Chrome और Firefox किसी भी ऐसे पेज को bfcache के लिए अयोग्य बना देते हैं जिसमें unload listener हो — कोई अपवाद नहीं, कोई आंशिक छूट नहीं।
यह listener आपका हो, ज़रूरी नहीं। आपके पेज के अंदर से, या किसी subframe के अंदर से भी, unload रजिस्टर करने वाले थर्ड-पार्टी स्क्रिप्ट टॉप-लेवल डॉक्यूमेंट को अयोग्य कर देते हैं। Lighthouse एक समर्पित no-unload-listeners audit देता है, ठीक इसलिए क्योंकि दोषी कोड अक्सर ऐसा कोड होता है जो साइट के लेखक ने कभी लिखा ही नहीं।
आधुनिक ब्राउज़रों में beforeunload अब अयोग्य नहीं करता, लेकिन यह भरोसेमंद नहीं है और जब तक यूज़र के पास सहेजे न गए बदलाव न हों, तब तक इससे बचना ही बेहतर है।
ट्रैकिंग स्क्रिप्ट्स आमतौर पर दोषी होते हैं
unload event एक आखिरी beacon भेजने की पारंपरिक जगह है — किसी session को flush करना, "page closed" event भेजना — इसलिए व्यवहार-ट्रैकिंग और विज्ञापन स्क्रिप्ट लगातार इसका सहारा लेते हैं।
HTTP Archive के अनुसार, Facebook का fbevents.js एक unload handler रजिस्टर करता है और लगभग सभी वेब पेजों के 9% पर दिखाई देता है। PayPal का tag एक iframe इंजेक्ट करता है जो unload event जोड़ता है, जिससे कई checkout flows पर bfcache ब्लॉक हो जाता है। hCaptcha जैसे subframe स्क्रिप्ट भी यही करते आए हैं। इनमें से किसी को भी आपको नुकसान पहुँचाना शुरू करने के लिए आपके अपने कोड में बदलाव की ज़रूरत नहीं — किसी वेंडर का एक अपडेट पुश करना ही काफी है।
CrUX अब आपको बिल दिखाता है
पहले यह field data में अदृश्य था। March 2024 के dataset से, Chrome User Experience Report (CrUX) एक navigation_types breakdown रिपोर्ट करता है — जिसमें बैक/फॉरवर्ड कैश से सर्व किए गए विज़िट्स का अंश भी शामिल है — ताकि आप देख सकें कि कितने असली यूज़र उस तुरंत वाले रास्ते से चूक रहे हैं।
यह सहसंबंध साफ़ है। CrUX विश्लेषण में एक मज़बूत सांख्यिकीय संबंध (ρ=0.87) पाया गया, ऊँचे back_forward_cache अंश और instant_lcp_density — यानी 200 ms से कम LCP वाले लोड का अंश — के बीच। Google के March 2026 अपडेट ने LCP, INP, और CLS के रैंकिंग वज़न को बढ़ाया, उसके बाद खुद से लगाया गया bfcache ब्लॉक 75वें percentile पर एक मापने लायक नुकसान है, कोई rounding error नहीं।
इसका पता लगाना और ठीक करना
DevTools खोलिए, Application → Back/forward cache पर जाइए, और Run Test क्लिक कीजिए। Chrome हर ब्लॉकिंग कारण की सूची देता है, जिसमें थर्ड पार्टियों द्वारा जोड़े गए unload handlers भी शामिल हैं।
अपने कोड में bfcache रीस्टोर का पता लगाने के लिए, कभी भी unload का इस्तेमाल मत कीजिए। pageshow का इस्तेमाल कीजिए और persisted जाँचिए:
window.addEventListener('pageshow', (event) => {
if (event.persisted) {
// restored from bfcache — no fresh page load fired
}
})
थर्ड पार्टियों को आपको अयोग्य करने से रोकने के लिए, एक response header सेट कीजिए जो unload listeners को पूरी तरह मना कर दे:
Permissions-Policy: unload=()
यह किसी भी स्क्रिप्ट के unload handlers को निष्क्रिय कर देता है — वेंडर tags, extensions, या आपका अपना पुराना कोड — ताकि जो भी लोड हो, उसके बावजूद पेज bfcache के लिए पात्र बना रहे।
वह ट्रैकर जो इसे कभी छूता ही नहीं
संरचनात्मक हल यह है कि ऐसी instrumentation का इस्तेमाल किया जाए जिसके पास unload को सुनने की कोई वजह ही न हो। एक privacy-first ट्रैकर एक ही keepalive रिक्वेस्ट के साथ pageview दर्ज करता है और रिक्वेस्ट को पेज के बाद भी अपने आप ज़िंदा रहने देता है — कोई teardown beacon नहीं, कोई unload handler नहीं, ब्राउज़र के flag करने लायक कुछ भी नहीं:
fetch('/collect', {
method: 'POST',
keepalive: true,
body: JSON.stringify({ site_id, path: location.pathname })
})
जब किसी ट्रैकर को पेज के background में जाने पर प्रतिक्रिया देनी होती है, तो सही संकेत visibilitychange या pagehide होता है, और ये दोनों पेज को bfcache के लिए अयोग्य बनाए बिना fire होते हैं। Monoid का ट्रैकर लगभग 2 KB का है, कोई cookies सेट नहीं करता, और पेज lifecycle के बजाय SPA route बदलावों के लिए history.pushState को hook करता है — इसलिए इसके पास रजिस्टर करने को कोई unload listener नहीं है और आपके बैक/फॉरवर्ड कैश को डिसेबल करने को कुछ भी नहीं।
Surveillance एनालिटिक्स performance पर ऐसे तरीकों से कर लगाता है जो किसी lab run में नहीं दिखते। bfcache ब्लॉक उनमें सबसे शांत है: कोई error नहीं, कोई धीमा render नहीं, बस एक बैक बटन जो नेटवर्क से फिर से लोड करता है जबकि उसे मेमोरी से रीस्टोर करना चाहिए था।
Comments
Loading comments…