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

Demián Renzulli

Barry Pollard

पब्लिश किया गया: 10 अगस्त, 2023, पिछली बार अपडेट किया गया: 14 जुलाई, 2026

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

`अनलोड` इवेंट को बंद करने की टाइमलाइन

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

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

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

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

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

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

बैकग्राउंड

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Chrome DevTools

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

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

1. अपने पेज पर, DevTools खोलें. इसके बाद, ऐप्लिकेशन > बैकग्राउंड सेवाएं > बैक/फ़ॉरवर्ड कैश मेमोरी पर जाएं.

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

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

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

रिपोर्टिंग एपीआई का इस्तेमाल, रीड-ओनली Permission Policy के साथ किया जा सकता है. इससे आपकी वेबसाइट के उपयोगकर्ताओं के लिए, unload के इस्तेमाल का पता लगाया जा सकता है.

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

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

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

Permissions Policy

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

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

Enterprise की नीति

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

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

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

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

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

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

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

नतीजा

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

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

Acknowledgements

समीक्षा के लिए सुझाव और राय देने के लिए, Kenji Baheux, Fergal Daly, Adriana Jara, और Jeremy Wagner का धन्यवाद.

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