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

Demián Renzulli

Barry Pollard

पब्लिश करने की तारीख: 10 अगस्त, 2023, पिछली बार अपडेट किए जाने की तारीख: 11 मार्च, 2025

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

बंद होने की टाइमलाइन

अपडेट: इस टाइमलाइन को 11 मार्च, 2025 तक अपडेट किया गया है.

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

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

हमने 2024 में पूरे साल, इस सुविधा को लॉन्च करने से जुड़ी कई समस्याओं को हल किया.

unload इवेंट के बंद होने की मौजूदा टाइमलाइन यहां दी गई है:

अहम जानकारी: वर्शन नंबर और तारीखों में बदलाव हो सकता है. ऐसा इसलिए, क्योंकि हम रोल आउट के असर को मॉनिटर और आकलन करते हैं.

Milestone	माइलस्टोन की तारीख	टॉप-50 साइटें	अन्य ऑरिजिन का %
135	26 मार्च, 2025	पहला (www.google.com)	0
136	23 अप्रैल, 2025	5	0
137	21 मई, 2025	25	0
138	18 जून, 2025	50	0

टॉप-50 साइटों के बंद होने की टाइमलाइन.

टॉप-50 साइटों के लिए रोल आउट पूरा होने के बाद, हम इसे रोक देंगे और एक या दो माइलस्टोन के लिए इसे सोखने देंगे. इसके बाद, अगले आठ माइलस्टोन (या करीब 32 हफ़्ते) में, सभी ऑरिजिन के लिए इसे रोल आउट करने की अनुमति ले लेंगे. यह प्रोसेस कुछ इस तरह होगी:

Milestone	माइलस्टोन की तारीख	टॉप-50 साइटें	अन्य ऑरिजिन का प्रतिशत
140	27 अगस्त, 2025	50	1
141	24 सितंबर, 2025	50	5
142	22 अक्टूबर, 2025	50	10
143	19 नवंबर, 2025	50	20
144	17 जनवरी, 2026	50	40
145	4 फ़रवरी, 2026	50	60
146	4 मार्च, 2026	50	80
147	1 अप्रैल, 2026	50	100

सभी साइटों के लिए, बंद होने की टाइमलाइन.

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

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

बैकग्राउंड

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

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

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

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

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

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

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

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 खोलें. इसके बाद, ऐप्लिकेशन > बैकग्राउंड सेवाएं > बैक/फ़ॉरवर्ड कैश मेमोरी पर जाएं.

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

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

Chrome DevTools का बैक/फ़ॉरवर्ड कैश टेस्टिंग टूल.

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

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 के बंद होने की सेटिंग में बदलाव कर सकता है, ताकि अलग-अलग साइटों पर होने वाले असर की जांच की जा सके.

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

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

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

एंटरप्राइज़ नीति

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

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

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

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

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

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

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

	बंद होने की तारीख को आगे बढ़ाना	अपग्रेड की सुविधा बंद करने की तारीख को पहले करना (अपवादों के साथ)	माइग्रेशन के लिए समय सुरक्षित करने के लिए, प्रॉपर्टी के बंद होने से रोकना
अनुमतियों से जुड़ी नीति (यह पेजों/साइटों पर लागू होती है)	हां	हां	हां
एंटरप्राइज़ नीति (यह डिवाइसों पर लागू होती है)	नहीं	नहीं	हां
Chrome फ़्लैग (यह सुविधा हर उपयोगकर्ता के लिए उपलब्ध है)	हां	नहीं	नहीं
Chrome के कमांड लाइन स्विच (यह सेटिंग हर उपयोगकर्ता के लिए अलग-अलग हो सकती है)	हां	नहीं	हां

नतीजा

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

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

आभार

इस लेख की समीक्षा करने में मदद करने के लिए, केंजी बहेक्स, फ़र्गल डाली, अड्रियऩा जारा, और जेरेमी वॉगनर का धन्यवाद.

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