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

Demián Renzulli

Barry Pollard

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

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

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

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

इस तरह के आउटरीच और ट्रायल के बाद, हमें उम्मीद है कि धीरे-धीरे बंद होने की सुविधा इस तरह से रोल आउट होगी:

• यह एक ऐसा फ़ेज़ है जिसमें 50 सबसे लोकप्रिय साइटों के लिए, अनलोड करने की सुविधा धीरे-धीरे काम करना बंद कर देगी. यह जानकारी, लेख लिखने के समय के रेफ़रंस के तौर पर दी गई है.
  • यह सुविधा, Chrome 120 (नवंबर 2023 के आखिर में) के 1% उपयोगकर्ताओं के लिए शुरू की जाएगी.
  • साल 2024 की तीसरी तिमाही के आखिर तक, सभी उपयोगकर्ताओं के लिए बंद कर दिया जाएगा
• इसके अलावा, साल 2024 की तीसरी तिमाही से, हम एक सामान्य फ़ेज़ शुरू करने जा रहे हैं. इसमें, किसी भी साइट पर धीरे-धीरे अनलोड की सुविधा बंद हो जाएगी. यह सुविधा 1% उपयोगकर्ताओं के लिए साल 2024 की तीसरी तिमाही से और साल 2025 की पहली तिमाही के आखिर तक 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 का इस्तेमाल किया जा रहा है या नहीं:

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

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

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

Bfcache notRestoredReasons API

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

नतीजा

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

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

धन्यवाद

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

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