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

Demián Renzulli

Barry Pollard

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

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

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

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

इन आउटरीच और ट्रायल के इन चरणों के बाद, हम सॉफ़्ट रूप से बंद होने की सुविधा के रोल आउट होने की उम्मीद कर सकते हैं:

• एक स्कोप वाला चरण, जिसमें अनलोड करने की सुविधा धीरे-धीरे टॉप 50 लोकप्रिय साइटों के लिए काम करना बंद कर देगी. साइटों का रेफ़रंस, लिखने के समय का है.
  • इसकी शुरुआत, Chrome 120 के 1% उपयोगकर्ताओं से हो रही है (नवंबर 2023 के आखिर में).
  • साल 2024 की तीसरी तिमाही के आखिर तक, यह सुविधा आपके 100% उपयोगकर्ताओं के साथ खत्म हो जाएगी
• इसके अलावा, साल 2024 की तीसरी तिमाही से, हम एक सामान्य चरण शुरू करना चाहते हैं. इसके बाद, किसी भी साइट पर अनलोड करना धीरे-धीरे बंद हो जाएगा. इसकी शुरुआत, 1% उपयोगकर्ताओं से होगी और साल 2025 की पहली तिमाही के आखिर तक, इसका इस्तेमाल 100% उपयोगकर्ताओं से होगा.

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

बैकग्राउंड

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

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

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

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

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

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

Chrome की टीम का मानना है कि डेस्कटॉप पर unload से ज़्यादा 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 एपीआई

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

• अनुमतियों से जुड़ी नीति: यह साइट के मालिकों के लिए एक प्लैटफ़ॉर्म एपीआई है. इसकी मदद से, वे साइट या किसी पेज के लेवल पर सुविधाओं के ऐक्सेस को कंट्रोल कर सकते हैं. ऐसा करने के लिए, वे एचटीटीपी हेडर का इस्तेमाल कर सकते हैं.
• एंटरप्राइज़ नीतियां: आईटी एडमिन के लिए ऐसे टूल जो अपने संगठन या कारोबार के लिए 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 हैंडलर की जांच करनी चाहिए या उन्हें हटाना या माइग्रेट करना चाहिए. इसके अलावा, हो सकता है कि ज़्यादा समय लेने पर, साइट को कुछ समय के लिए बंद कर दिया जाए.

स्वीकार की गई

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

Unस्प्लैश पर अंजा बॉरमैन की हीरो इमेज