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

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

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

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

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

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

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

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

अनलोड होने को रोकने की टाइमलाइन.

बैकग्राउंड

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

लाइटहाउस

Lighthouse में no-unload-listeners ऑडिट होता है, जो डेवलपर को चेतावनी देता है कि अगर उनके पेजों (इसमें तीसरे पक्ष की लाइब्रेरी का JavaScript भी शामिल है) पर किसी unload इवेंट लिसनर को जोड़ा जाता है, तो उन्हें चेतावनी मिलती है.

लाइटहाउस ऑडिट, जिसमें यह दिखाया गया है कि अनलोड हैंडलर का इस्तेमाल किया जा रहा है

Chrome DevTools

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

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

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

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

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

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

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

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

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

Bfcache notRestoredReasons एपीआई

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

{
   blocked: true,
   children: [],
   id: "",
   name: "",
   reasons: [ "Internal Error", "Unload handler" ],
   src: "",
   url: "a.com"
}

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

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

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

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