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

Demián Renzulli

Barry Pollard

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

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

अपडेट: इस टाइमलाइन को 13 नवंबर, 2023 तक अपडेट कर दिया गया है.

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

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