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

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

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

समर्थन बंद होने की टाइमलाइन

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

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

Milestone माइलस्टोन की तारीख टॉप-50 साइटें अन्य ऑरिजिन का प्रतिशत
135 26 मार्च, 2025 1 (www.google.com) 0
139 30 जुलाई, 2025 5 0
140 27 अगस्त, 2025 10 0
141 24 सितंबर, 2025 25 0
142 22 अक्टूबर, 2025 50 0
टॉप-50 साइटों के बंद होने की समयावधि.

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

Milestone माइलस्टोन की तारीख टॉप-50 साइटें सभी साइटों के लिए, Chrome में पेज लोड होने का प्रतिशत
146 10 मार्च, 2026 50 1
147 7 अप्रैल, 2026 50 5
148 5 मई, 2026 50 10
149 2 जून, 2026 50 20
150 30 जून, 2026 50 40
151 28 जुलाई, 2026 50 60
152 25 अगस्त, 2026 50 80
153 22 सितंबर, 2026 50 100
सभी साइटों के लिए बंद होने की टाइमलाइन.

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

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

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

बैकग्राउंड

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

इस इवेंट का इस्तेमाल आम तौर पर इन स्थितियों में किया जाता है:

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

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

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

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

Chrome टीम का मानना है कि डेस्कटॉप पर unload के बजाय bfcache को प्राथमिकता देने वाले मोबाइल मॉडल का इस्तेमाल करने से, समस्याएं आ सकती हैं. ऐसा इसलिए, क्योंकि इससे डेस्कटॉप पर भी bfcache कम भरोसेमंद हो जाएगा. हालांकि, पहले Chrome और Firefox में bfcache काफ़ी भरोसेमंद था. इसके बजाय, 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 खोलें. इसके बाद, Application > Background services > Back/forward cache पर जाएं.

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

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

Chrome DevTools के बैक/फ़ॉरवर्ड कैश मेमोरी टेस्टिंग टूल में दिखाया गया है कि अनलोड हैंडलर का इस्तेमाल किया गया था
Chrome DevTools का बैक/फ़ॉरवर्ड कैश टेस्टिंग टूल.

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

Reporting API का इस्तेमाल, सिर्फ़ पढ़ने की अनुमति वाली Permission Policy के साथ किया जा सकता है. इससे आपकी वेबसाइट के उपयोगकर्ताओं के 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 हैंडलर से माइग्रेट करने के लिए समय देने के लिए किया जाना चाहिए.

Enterprise की नीति

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

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

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

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

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

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

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

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

नतीजा

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

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

Acknowledgements

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

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