अनलोड इवेंट को रोका जा रहा है

Demián Renzulli

Barry Pollard

पब्लिश करने की तारीख: 10 अगस्त, 2023, पिछली बार अपडेट करने की तारीख: 29 जून, 2026

डिफ़ॉल्ट सेटिंग में धीरे-धीरे बदलाव करके, unload इवेंट को धीरे-धीरे बंद कर दिया जाएगा. इससे, unload हैंडलर पेजों पर ट्रिगर होना बंद हो जाएंगे. हालांकि, अगर कोई पेज इन्हें फिर से चालू करने के लिए ऑप्ट इन करता है, तो ये ट्रिगर होना जारी रखेंगे.

सुविधा के बंद होने की टाइमलाइन

हमने बताया था कि अनलोड के व्यवहार में बदलाव हो सकते हैं. हमने जनवरी 2019 में, बैक/फ़ॉरवर्ड कैश मेमोरी लागू करने का एलान किया था. हमने इस सुविधा को लागू करने के साथ-साथ, बड़े पैमाने पर लोगों तक इसकी जानकारी पहुंचाई. इससे अनलोड किए गए पेजों के इस्तेमाल में काफ़ी गिरावट आई. इस आउटरीच के साथ-साथ, हमने Chrome 115 से अनलोड करने की सुविधा हटाने के असर को टेस्ट करने के तरीके भी उपलब्ध कराए:

• Chrome 115 (जुलाई 2023) में, अनलोड करने के लिए Permission-Policy API का इस्तेमाल करके वाइल्ड टेस्टिंग की गई
• Chrome 117 (सितंबर 2023) में फ़्लैग चालू करके, स्थानीय तौर पर टेस्टिंग की जा सकती है

साल 2024 में, हमने कई ऐसी समस्याओं को ठीक किया जिनकी वजह से रोलआउट शुरू नहीं हो पा रहा था. साल 2025 में, हमने इस सुविधा को बंद करने की प्रोसेस को टॉप 50 साइटों पर रोल आउट किया:

साल 2026 में, इसे सभी ऑरिजिन के लिए रोल आउट किया गया. इसमें आठ चरण (या करीब 32 हफ़्ते) लगे. इसके बारे में यहां दी गई टेबल में बताया गया है.

पूरी तरह से रोल आउट करने की प्रोसेस, पेज लोड होने की संख्या पर आधारित होती है. साथ ही, यह समय के साथ एक जैसी रहती है. यह प्रोसेस, अलग-अलग उपयोगकर्ताओं या साइटों पर आधारित नहीं होती, ताकि उपयोगकर्ताओं या साइटों पर दूसरों की तुलना में ज़्यादा असर न पड़े. इसके बारे में 'बंद करने का इरादा' सेक्शन में ज़्यादा जानकारी दी गई है.

ध्यान दें कि अगर इस सुविधा को बंद करने की समयसीमा के दौरान, अनलोड से माइग्रेट करने के लिए आपके पास समय नहीं है, तो हम आपको ऑप्ट-आउट करने के विकल्पों का मेन्यू भी उपलब्ध कराते हैं.

बैकग्राउंड

unload को इस तरह से डिज़ाइन किया गया है कि जब दस्तावेज़ अनलोड हो रहा हो, तब यह ट्रिगर हो. सैद्धांतिक तौर पर, इसका इस्तेमाल तब किया जा सकता है, जब कोई उपयोगकर्ता किसी पेज से नेविगेट कर रहा हो या सेशन के आखिर में कॉलबैक के तौर पर.

इस इवेंट का इस्तेमाल इन स्थितियों में सबसे ज़्यादा किया जाता है:

• उपयोगकर्ता का डेटा सेव करना: पेज छोड़ने से पहले डेटा सेव करें.
• सफ़ाई से जुड़े टास्क पूरे करना: पेज को बंद करने से पहले, खुले हुए संसाधनों को बंद करना.
• Analytics का डेटा भेजना: सेशन के आखिर में, उपयोगकर्ता के इंटरैक्शन से जुड़ा डेटा भेजना.

हालांकि, unload इवेंट बहुत भरोसेमंद नहीं है.

डेस्कटॉप पर Chrome और Firefox में, unload का इस्तेमाल भरोसेमंद तरीके से किया जा सकता है. हालांकि, इससे साइट की परफ़ॉर्मेंस पर बुरा असर पड़ता है. ऐसा इसलिए, क्योंकि यह bfcache (बैक/फ़ॉरवर्ड कैश मेमोरी) के इस्तेमाल को रोकता है.

मोबाइल ब्राउज़र पर unload अक्सर काम नहीं करता, क्योंकि टैब को अक्सर बैकग्राउंड में रखा जाता है और फिर बंद कर दिया जाता है. इस वजह से, ब्राउज़र मोबाइल पर unload के बजाय bfcache को प्राथमिकता देते हैं. इससे unload और भी ज़्यादा भरोसेमंद नहीं रह जाता. Safari भी डेस्कटॉप पर इस व्यवहार का इस्तेमाल करता है.

Chrome टीम का मानना है कि डेस्कटॉप पर unload के बजाय bfcache को प्राथमिकता देने वाले मोबाइल मॉडल का इस्तेमाल करने से, समस्याएं आ सकती हैं. इससे डेस्कटॉप पर भी bfcache कम भरोसेमंद हो जाएगा. हालांकि, पहले Chrome और Firefox पर यह काफ़ी भरोसेमंद था. इसके बजाय, Chrome का मकसद unload इवेंट को पूरी तरह से हटाना है. हालांकि, जिन लोगों ने इस सुविधा को बंद करने से ऑप्ट-आउट किया है वे डेस्कटॉप पर Chrome में इसका इस्तेमाल कर पाएंगे.

unload इवेंट का इस्तेमाल क्यों बंद किया जा रहा है?

unload को बंद करना, वेब को बेहतर बनाने की दिशा में एक अहम कदम है. unload इवेंट से, ऐप्लिकेशन के लाइफ़साइकल को कंट्रोल करने का गलत एहसास होता है. हालांकि, मॉडर्न कंप्यूटिंग की दुनिया में वेब ब्राउज़ करने के तरीके के हिसाब से यह सही नहीं है.

मोबाइल ऑपरेटिंग सिस्टम, मेमोरी बचाने के लिए अक्सर वेब पेजों को फ़्रीज़ या अनलोड कर देते हैं. डेस्कटॉप ब्राउज़र भी अब इसी वजह से ऐसा ज़्यादा से ज़्यादा कर रहे हैं. ऑपरेटिंग सिस्टम के इंटरवेंशन के बिना भी, उपयोगकर्ता अक्सर टैब स्विच करते हैं और पुराने टैब बंद करते हैं. हालांकि, वे औपचारिक तौर पर "पेज नहीं छोड़ते".

unload इवेंट को पुराने इवेंट के तौर पर हटाने का मतलब है कि वेब डेवलपर के तौर पर हमें यह पक्का करना होगा कि हमारा पैराडाइम, असल दुनिया के पैराडाइम से मेल खाता हो. साथ ही, हमें ऐसे पुराने कॉन्सेप्ट पर निर्भर नहीं रहना चाहिए जो अब सही नहीं हैं.

unload इवेंट के विकल्प

unload के बजाय, इनका इस्तेमाल करने का सुझाव दिया जाता है:

• visibilitychange: इससे यह पता चलता है कि पेज के दिखने की सेटिंग कब बदली गई. यह इवेंट तब ट्रिगर होता है, जब उपयोगकर्ता टैब स्विच करता है, ब्राउज़र विंडो को छोटा करता है या कोई नया पेज खोलता है. ऐप्लिकेशन और उपयोगकर्ता का डेटा सेव करने के लिए, hidden की स्थिति को आखिरी भरोसेमंद समय माना जाता है.
• pagehide: यह कुकी यह तय करती है कि उपयोगकर्ता ने पेज कब छोड़ा. यह इवेंट तब ट्रिगर होता है, जब उपयोगकर्ता पेज से बाहर जाता है, पेज को फिर से लोड करता है या ब्राउज़र विंडो बंद करता है. जब पेज को छोटा किया जाता है या किसी दूसरे टैब पर स्विच किया जाता है, तब pagehide इवेंट ट्रिगर नहीं होता. ध्यान दें कि pagehide इवेंट की वजह से, कोई पेज बैक/फ़ॉरवर्ड कैश मेमोरी के लिए ज़रूरी शर्तें पूरी न करने वाला नहीं बन जाता. इसलिए, इस इवेंट के ट्रिगर होने के बाद भी किसी पेज को वापस लाया जा सकता है. अगर इस इवेंट में किसी संसाधन को हटाया जा रहा है, तो पेज को वापस लाने पर उन्हें भी वापस लाना पड़ सकता है.

beforeunload इवेंट का इस्तेमाल, unload से थोड़ा अलग होता है. ऐसा इसलिए, क्योंकि इसे रद्द किया जा सकता है. इसका इस्तेमाल अक्सर तब किया जाता है, जब उपयोगकर्ता किसी दूसरे पेज पर जाता है और उसे यह चेतावनी देनी होती है कि बदलाव सेव नहीं किए गए हैं. यह इवेंट भी भरोसेमंद नहीं है, क्योंकि बैकग्राउंड टैब बंद होने पर यह ट्रिगर नहीं होगा. हमारा सुझाव है कि beforeunload का इस्तेमाल सीमित तौर पर करें और इसे सिर्फ़ तब जोड़ें, जब इसकी ज़रूरत हो. इसके बजाय, ज़्यादातर unload इवेंट की जगह, ऊपर बताए गए इवेंट का इस्तेमाल करें.

ज़्यादा जानकारी के लिए, unload हैंडलर का इस्तेमाल कभी न करने के बारे में यह सलाह देखें.

unload के इस्तेमाल का पता लगाना

पेजों पर unload इवेंट की मौजूदगी का पता लगाने के लिए, अलग-अलग टूल उपलब्ध हैं. इससे साइटों को यह पता चलता है कि वे इस इवेंट का इस्तेमाल कर रही हैं या नहीं. वे इसका इस्तेमाल अपने कोड में या लाइब्रेरी का इस्तेमाल करके कर सकती हैं. इसलिए, आने वाले समय में इस इवेंट के बंद होने से उन पर असर पड़ सकता है.

Chrome DevTools

Chrome DevTools में back-forward-cache ऑडिट शामिल है. इससे आपको उन समस्याओं की पहचान करने में मदद मिलती है जिनकी वजह से, आपका पेज बैक/फ़ॉरवर्ड कैश मेमोरी में सेव नहीं हो पाता. इसमें unload हैंडलर का इस्तेमाल भी शामिल है.

बैक/फ़ॉरवर्ड कैश मेमोरी की जांच करने के लिए, यह तरीका अपनाएं:

1. अपने पेज पर, DevTools खोलें. इसके बाद, Application > Background services > बैक-फ़ॉरवर्ड कैश मेमोरी पर जाएं.

2. बैक/फ़ॉरवर्ड कैश मेमोरी की जांच करें पर क्लिक करें. Chrome आपको अपने-आप chrome://terms/ पर ले जाएगा और फिर वापस आपके पेज पर ले जाएगा. इसके अलावा, ब्राउज़र के 'वापस जाएं' और 'आगे जाएं' बटन पर क्लिक करके भी ऐसा किया जा सकता है.

अगर आपका पेज बैक/फ़ॉरवर्ड कैश मेमोरी की सुविधा इस्तेमाल करने की ज़रूरी शर्तें पूरी नहीं करता है, तो बैक/फ़ॉरवर्ड कैश मेमोरी टैब में आपको समस्याओं की सूची दिखेगी. कार्रवाई करने की ज़रूरत है में जाकर, यह देखा जा सकता है कि unload का इस्तेमाल किया जा रहा है या नहीं:

रिपोर्टिंग एपीआई

Reporting API का इस्तेमाल, सिर्फ़ पढ़ने की अनुमति वाली अनुमतियों की नीति के साथ किया जा सकता है. इससे आपकी वेबसाइट के उपयोगकर्ताओं के unload के इस्तेमाल का पता लगाया जा सकता है.

ज़्यादा जानकारी के लिए, अनलोड किए गए पेजों का पता लगाने के लिए Reporting API का इस्तेमाल करना लेख पढ़ें

Bfcache notRestoredReasons API

notRestoredReasons प्रॉपर्टी को PerformanceNavigationTiming क्लास में जोड़ा गया है. यह प्रॉपर्टी, इस बारे में जानकारी देती है कि नेविगेशन के दौरान, दस्तावेज़ों को bfcache का इस्तेमाल करने से रोका गया था या नहीं. साथ ही, यह भी बताती है कि ऐसा क्यों किया गया था. यहां एक उदाहरण दिया गया है, जिसमें दिखाया गया है कि मौजूदा unload लिसनर की रिस्पॉन्स ऑब्जेक्ट चेतावनी कैसी दिखती है:

{
   children: [],
   id: null,
   name: null,
   reasons: [
     {"reason", "unload-listener"}
   ],
   src: null,
   url: "https://www.example.com/page/"
}

unload का ऐक्सेस कंट्रोल करना

Chrome, unload इवेंट को धीरे-धीरे बंद कर रहा है. इस बीच, इस व्यवहार को कंट्रोल करने के लिए अलग-अलग टूल इस्तेमाल किए जा सकते हैं. साथ ही, इस सुविधा के बंद होने की तैयारी की जा सकती है. ध्यान रखें कि आपको लंबे समय तक इन तकनीकों पर भरोसा नहीं करना चाहिए. इसके बजाय, आपको जल्द से जल्द विकल्पों पर माइग्रेट करने का प्लान बनाना चाहिए.

यहां दिए गए विकल्पों की मदद से, unload हैंडलर को चालू या बंद किया जा सकता है. इससे यह टेस्ट किया जा सकता है कि हैंडलर के बिना आपकी साइट कैसे काम करेगी. इससे, आने वाले समय में हैंडलर के बंद होने की स्थिति के लिए तैयारी की जा सकती है. नीतियां कई तरह की होती हैं:

• अनुमतियों से जुड़ी नीति: यह साइट के मालिकों के लिए एक प्लैटफ़ॉर्म एपीआई है. इसकी मदद से, वे साइट या किसी पेज के लेवल पर, सुविधाओं के ऐक्सेस को कंट्रोल कर सकते हैं. इसके लिए, वे एचटीटीपी हेडर का इस्तेमाल करते हैं.
• Enterprise की नीतियां: आईटी एडमिन के लिए ऐसे टूल जिनकी मदद से वे अपने संगठन या कारोबार के लिए Chrome को कॉन्फ़िगर कर सकते हैं. इन्हें एडमिन पैनल का इस्तेमाल करके कॉन्फ़िगर किया जा सकता है. जैसे, Google Admin Console.
• Chrome फ़्लैग: इससे कोई डेवलपर, unload डेप्रिकेशन सेटिंग में बदलाव कर सकता है, ताकि अलग-अलग साइटों पर इसके असर की जांच की जा सके.

अनुमतियों की नीति

Permissions Policy को Chrome 115 से जोड़ा गया था, ताकि साइटें unload हैंडलर का इस्तेमाल न करने का विकल्प चुन सकें. साथ ही, साइट की परफ़ॉर्मेंस को बेहतर बनाने के लिए, bfcache का तुरंत फ़ायदा पा सकें. अपनी साइट के लिए इसे सेट अप करने के तरीके के बारे में जानने के लिए, ये उदाहरण देखें. इससे साइटों को unload के बंद होने से पहले ही, इससे जुड़ी समस्याओं को ठीक करने का मौका मिल जाता है.

Chrome 117 में इसे बढ़ा दिया गया था, ताकि साइटें इसका इस्तेमाल कर सकें. साथ ही, वे unload हैंडलर को फ़ायर करने की कोशिश जारी रखने के लिए ऑप्ट-इन कर सकें, जैसा कि वे अभी करती हैं. ऐसा इसलिए, क्योंकि Chrome इन हैंडलर के लिए डिफ़ॉल्ट सेटिंग को बदलकर, उन्हें आने वाले समय में फ़ायर न होने की सेटिंग पर सेट कर देगा. अपनी साइट के लिए अनलोड हैंडलर को ट्रिगर करने की अनुमति जारी रखने के तरीके के बारे में ये उदाहरण देखें. हमारा सुझाव है कि साइट के मालिक, unload हैंडलर का इस्तेमाल न करें, क्योंकि ये भरोसेमंद नहीं होते. हालांकि, हम आने वाले समय में उन साइटों के लिए इस ऑप्ट-आउट सुविधा को जारी रखेंगे जिन्हें इसका इस्तेमाल करना है. ध्यान दें कि फिर से ऑप्ट इन करने से, मोबाइल पर unload हैंडलर ज़्यादा भरोसेमंद नहीं हो जाते. इससे सिर्फ़ मौजूदा स्थिति वापस आ जाती है.

Enterprise की नीति

जिन एंटरप्राइज़ के सॉफ़्टवेयर, सही तरीके से काम करने के लिए unload इवेंट पर निर्भर करते हैं वे ForcePermissionPolicyUnloadDefaultEnabled नीति का इस्तेमाल करके, अपने कंट्रोल में मौजूद डिवाइसों के लिए इवेंट हैंडलर को धीरे-धीरे बंद किए जाने की प्रोसेस को रोक सकते हैं. इस नीति को चालू करने पर, सभी ऑरिजिन के लिए unload डिफ़ॉल्ट रूप से चालू रहेगा. हालांकि, कोई पेज अब भी ज़्यादा पाबंदी वाली नीति सेट कर सकता है. अनुमतियों की नीति से ऑप्ट-आउट करने की तरह, यह भी संभावित बड़े बदलावों को कम करने का एक टूल है. हम साइट के मालिकों को एक बार फिर यह सुझाव देंगे कि वे unload हैंडलर पर निर्भर न रहें. हालांकि, Chrome का प्लान है कि वह आने वाले समय में, उन साइटों के लिए एंटरप्राइज़ के ऑप्ट-आउट करने की सुविधा उपलब्ध कराता रहेगा जिन्हें इसका इस्तेमाल करना है.

Chrome फ़्लैग और कमांड लाइन स्विच

एंटरप्राइज़ नीति के साथ-साथ, Chrome फ़्लैग और कमांड लाइन स्विच का इस्तेमाल करके, अलग-अलग उपयोगकर्ताओं के लिए इस सुविधा को बंद किया जा सकता है:

इसे enabled पर सेट करने से, chrome://flags/#deprecate-unload डिफ़ॉल्ट रूप से बंद हो जाएगा. साथ ही, unload हैंडलर ट्रिगर नहीं होंगे. इन्हें अब भी साइट के हिसाब से, अनुमतियों की नीति का इस्तेमाल करके बदला जा सकता है. हालांकि, ये डिफ़ॉल्ट रूप से ट्रिगर होते रहेंगे.

इन सेटिंग को कमांड लाइन स्विच से भी कंट्रोल किया जा सकता है.

विकल्पों की तुलना करना

यहां दी गई टेबल में, ऊपर बताए गए विकल्पों के अलग-अलग इस्तेमाल के बारे में खास जानकारी दी गई है:

नतीजा

unload हैंडलर बंद किए जा रहे हैं. ये लंबे समय से भरोसेमंद नहीं हैं. साथ ही, इस बात की कोई गारंटी नहीं है कि जब कोई दस्तावेज़ मिटाया जाता है, तो ये सभी मामलों में ट्रिगर होंगे. इसके अलावा, unload हैंडलर, bfcache के साथ काम नहीं करते.

unload हैंडलर का इस्तेमाल करने वाली साइटों को, इस सुविधा के बंद होने से पहले तैयारी कर लेनी चाहिए. इसके लिए, उन्हें मौजूदा unload हैंडलर की जांच करनी चाहिए. साथ ही, उन्हें हटाना या माइग्रेट करना चाहिए. अगर ज़्यादा समय की ज़रूरत है, तो सुविधा के बंद होने की तारीख को आगे बढ़ाया जा सकता है.

Acknowledgements

समीक्षा के बारे में मददगार सुझाव देने के लिए, केन्जी बाहेक्स, फ़र्गल डेली, एड्रियाना जारा, और जेरेमी वैगनर का धन्यवाद.

Unsplash पर Anja Bauermann की हीरो इमेज