पब्लिश होने की तारीख: 10 अगस्त, 2023, पिछली बार अपडेट होने की तारीख: 28 अप्रैल, 2026
unload इवेंट को धीरे-धीरे बंद किया जाएगा. इसके लिए, डिफ़ॉल्ट सेटिंग में धीरे-धीरे बदलाव किया जाएगा, ताकि पेजों पर unload हैंडलर ट्रिगर न हों. हालांकि, अगर कोई पेज इन्हें फिर से चालू करने के लिए साफ़ तौर पर ऑप्ट-इन करता है, तो उस पेज पर ये ट्रिगर हो सकते हैं.
`अनलोड` इवेंट को बंद करने की टाइमलाइन
हमने नोट किया था कि अनलोड के व्यवहार में बदलाव होने की संभावना है. यह बदलाव जनवरी 2019 में ही हो सकता है, जब हमने बैक/फ़ॉरवर्ड कैश मेमोरी को लागू करने के अपने इरादे के बारे में बताया था. हमने इसे लागू करने के साथ-साथ, लोगों तक पहुंचने के लिए एक बड़ा आउटरीच किया. इससे अनलोड के इस्तेमाल में काफ़ी कमी आई. इस आउटरीच के अलावा, हमने Chrome 115 से अनलोड को बंद करने के असर की जांच करने के तरीके भी उपलब्ध कराए:
- Chrome 115 में अनलोड के लिए, Permission-Policy API का इस्तेमाल करके इन-द-वाइल्ड टेस्टिंग (जुलाई 2023)
- Chrome 117 में फ़्लैग चालू करके लोकल टेस्टिंग (सितंबर 2023)
हमने 2024 में, डिप्लॉयमेंट शुरू करने में आने वाली कई समस्याओं को हल किया. इसके बाद, 2025 में हमने टॉप 50 साइटों के लिए, अनलोड को बंद करने की प्रोसेस शुरू की.
| Milestone | Milestone की तारीख | टॉप-50 साइटें | अन्य ऑरिजिन का प्रतिशत |
|---|---|---|---|
| 135 | 26 मार्च, 2025 | 1 (www.google.com) |
0 |
| 139 | 30 जुलाई, 2025 | 5 | 0 |
| 140 | 27 अगस्त, 2025 | 10 | 0 |
| 141 | 24 सितंबर, 2025 | 25 | 0 |
| 142 | 22 अक्टूबर, 2025 | 50 | 0 |
हमने टॉप-50 साइटों के लिए, अनलोड को बंद करने की प्रोसेस पूरी कर ली है. अब हमें सभी ऑरिजिन के लिए, इसे रोल आउट करने की अनुमति मिल गई है. इसके लिए, आठ माइलस्टोन (या करीब 32 हफ़्ते) लगेंगे. इसकी जानकारी, यहां दी गई टेबल में दी गई है.
| Milestone | Milestone की तारीख | टॉप-50 साइटें | सभी साइटों के लिए, Chrome पर पेज लोड होने का प्रतिशत |
|---|---|---|---|
| 146 | 10 मार्च, 2026 | 50 | 1 |
| 147 | 7 अप्रैल, 2026 | 50 | 5 |
| 148 | 5 मई, 2026 | 50 | 10 |
| 149 | 2 जून, 2026 | 50 | 20 |
| 150 | 30 जून, 2026 | 50 | 40 |
| 151 | 28 जुलाई, 2026 | 50 | 60 |
| 152 | 25 अगस्त, 2026 | 50 | 80 |
| 153 | 22 सितंबर, 2026 | 50 | 100 |
ध्यान दें कि हम ऑप्ट-आउट के विकल्प भी उपलब्ध कराते हैं. ऐसा इसलिए, ताकि अगर अनलोड को बंद करने की इस टाइमलाइन में, माइग्रेट करने के लिए ज़रूरत के मुताबिक समय न मिले, तो ऑप्ट-आउट किया जा सके. हमारा लक्ष्य है कि अनलोड को धीरे-धीरे बंद करने की इस प्रोसेस का इस्तेमाल करके, आखिरी चरण (अनलोड को पूरी तरह से बंद करना) की टाइमलाइन के बारे में बताया जाए. इस चरण में, ऑप्ट-आउट के इन विकल्पों को हटा दिया जाएगा या इनकी संख्या कम कर दी जाएगी.
बैकग्राउंड
unload को तब ट्रिगर करने के लिए डिज़ाइन किया गया था, जब दस्तावेज़ अनलोड हो रहा हो. सैद्धांतिक तौर पर, इसका इस्तेमाल तब किया जा सकता है, जब कोई उपयोगकर्ता किसी पेज से हट रहा हो या सेशन खत्म होने पर कॉलबैक के तौर पर कोड चलाने के लिए किया जा सकता है.
इस इवेंट का इस्तेमाल, आम तौर पर इन स्थितियों में किया जाता था:
- उपयोगकर्ता का डेटा सेव करना: पेज छोड़ने से पहले डेटा सेव करना.
- सफ़ाई से जुड़े टास्क पूरे करना: पेज छोड़ने से पहले, खुले हुए संसाधनों को बंद करना.
- Analytics भेजना: सेशन के आखिर में, उपयोगकर्ता के इंटरैक्शन से जुड़ा डेटा भेजना.
हालांकि, unload इवेंट पर भरोसा नहीं किया जा सकता.
डेस्कटॉप पर Chrome और Firefox में, unload पर भरोसा किया जा सकता है. हालांकि, इससे साइट की परफ़ॉर्मेंस पर बुरा असर पड़ता है, क्योंकि इसकी वजह से bfcache (बैक/फ़ॉरवर्ड कैश मेमोरी) का इस्तेमाल नहीं किया जा सकता.
मोबाइल ब्राउज़र पर, unload अक्सर काम नहीं करता, क्योंकि टैब को अक्सर बैकग्राउंड में ले जाया जाता है और फिर बंद कर दिया जाता है. इस वजह से, ब्राउज़र मोबाइल पर unload के बजाय bfcache को प्राथमिकता देते हैं. इससे unload पर और भी कम भरोसा किया जा सकता है. Safari भी डेस्कटॉप पर इसी तरह काम करता है.
Chrome की टीम का मानना है कि डेस्कटॉप पर, bfcache को unload पर प्राथमिकता देने वाले मोबाइल मॉडल का इस्तेमाल करने से, Chrome की परफ़ॉर्मेंस पर बुरा असर पड़ेगा. ऐसा इसलिए, क्योंकि पहले Chrome (और Firefox) में इस पर भरोसा किया जा सकता था. इसके बजाय, Chrome का लक्ष्य unload इवेंट को पूरी तरह से हटाना है. जब तक ऐसा नहीं होता, तब तक डेस्कटॉप पर यह भरोसेमंद बना रहेगा. हालांकि, यह सिर्फ़ उन लोगों के लिए होगा जिन्होंने अनलोड को बंद करने की प्रोसेस से ऑप्ट-आउट किया है.
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 हैंडलर का इस्तेमाल भी शामिल है.
बैक/फ़ॉरवर्ड कैश मेमोरी की जांच करने के लिए, यह तरीका अपनाएं:
अपने पेज पर, DevTools खोलें. इसके बाद, ऐप्लिकेशन > बैकग्राउंड सेवाएं > बैक/फ़ॉरवर्ड कैश मेमोरी पर जाएं.
बैक/फ़ॉरवर्ड कैश मेमोरी की जांच करें पर क्लिक करें. 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 में, इसे इस तरह से बढ़ाया गया है, ताकि साइटें इसके उलट काम कर सकें. साथ ही, वे unload हैंडलर को ट्रिगर करने की कोशिश जारी रखने के लिए ऑप्ट-इन कर सकें. Chrome, आने वाले समय में इनके लिए डिफ़ॉल्ट सेटिंग में बदलाव करेगा, ताकि ये ट्रिगर न हों. अपनी साइट के लिए, अनलोड हैंडलर को ट्रिगर करने की अनुमति जारी रखने का तरीका जानने के लिए, ये उदाहरण देखें. हमारा सुझाव है कि साइट के मालिक, unload हैंडलर का इस्तेमाल न करें, क्योंकि इन पर भरोसा नहीं किया जा सकता. हालांकि, हम उन साइटों के लिए, ऑप्ट-आउट के इस विकल्प को आने वाले समय में भी उपलब्ध कराएंगे जिन्हें इसका इस्तेमाल करना है. इसके अलावा, ऑप्ट-इन करने से, मोबाइल पर unload हैंडलर ज़्यादा भरोसेमंद नहीं होते. इससे सिर्फ़ मौजूदा स्थिति बहाल होती है.
Enterprise की नीति
जिन कंपनियों के पास ऐसा सॉफ़्टवेयर है जो सही तरीके से काम करने के लिए unload इवेंट पर निर्भर करता है वे ForcePermissionPolicyUnloadDefaultEnabled नीति का इस्तेमाल करके, अपने कंट्रोल वाले डिवाइसों के लिए, अनलोड को धीरे-धीरे बंद करने की प्रोसेस को रोक सकती हैं. इस नीति को चालू करने पर, unload सभी ऑरिजिन के लिए डिफ़ॉल्ट रूप से चालू रहेगा. अगर कोई पेज चाहे, तो ज़्यादा सख्त नीति सेट कर सकता है. Permissions Policy के ऑप्ट-आउट की तरह, यह संभावित बड़े बदलावों को कम करने का एक टूल है. हमारा सुझाव है कि साइट के मालिक, unload हैंडलर पर निर्भर न रहें. हालांकि, Chrome, उन साइटों के लिए, Enterprise के ऑप्ट-आउट के इस विकल्प को आने वाले समय में भी उपलब्ध कराएगा जिन्हें इसका इस्तेमाल करना है.
Chrome फ़्लैग और कमांड लाइन स्विच
Enterprise की नीति के अलावा, Chrome फ़्लैग और कमांड लाइन स्विच का इस्तेमाल करके, अलग-अलग उपयोगकर्ताओं के लिए, अनलोड को बंद करने की प्रोसेस को रोका जा सकता है:
इसे chrome://flags/#deprecate-unload पर सेट करने से, अनलोड को बंद करने की डिफ़ॉल्ट सेटिंग पहले से लागू हो जाएगी. साथ ही, enabled हैंडलर ट्रिगर नहीं होंगे.unload Permissions Policy का इस्तेमाल करके, इन्हें साइट के हिसाब से बदला जा सकता है. हालांकि, ये डिफ़ॉल्ट रूप से ट्रिगर होते रहेंगे.
इन सेटिंग को कमांड लाइन स्विच से भी कंट्रोल किया जा सकता है.
विकल्पों की तुलना
यहां दी गई टेबल में, पहले बताए गए विकल्पों के अलग-अलग इस्तेमाल की खास जानकारी दी गई है:
| अनलोड को बंद करने की प्रोसेस को पहले से लागू करना | अनलोड को बंद करने की प्रोसेस को पहले से लागू करना (कुछ अपवादों के साथ) | माइग्रेशन के लिए समय पाने के लिए, अनलोड को बंद करने की प्रोसेस को रोकना | |
|---|---|---|---|
| Permissions Policy (पेजों/साइटों पर लागू होती है) |
हां | हां | हां |
| Enterprise की नीति (डिवाइसों पर लागू होती है) |
नहीं | नहीं | हां |
| Chrome फ़्लैग (अलग-अलग उपयोगकर्ताओं पर लागू होते हैं) |
हां | नहीं | नहीं |
| Chrome कमांड लाइन स्विच (अलग-अलग उपयोगकर्ताओं पर लागू होते हैं) |
हां | नहीं | हां |
नतीजा
unload हैंडलर को बंद किया जा रहा है. ये लंबे समय से भरोसेमंद नहीं रहे हैं. साथ ही, इस बात की कोई गारंटी नहीं है कि दस्तावेज़ के बंद होने पर, ये सभी मामलों में ट्रिगर होंगे. इसके अलावा, unload हैंडलर, bfcache के साथ काम नहीं करते.
जिन साइटों पर unload हैंडलर का इस्तेमाल किया जाता है उन्हें, अनलोड को बंद करने की प्रोसेस के लिए तैयारी करनी चाहिए. इसके लिए, उन्हें मौजूदा unload हैंडलर की जांच करनी चाहिए. साथ ही, उन्हें हटाना या माइग्रेट करना चाहिए. अगर ज़्यादा समय की ज़रूरत है, तो अनलोड को बंद करने की प्रोसेस को टाला जा सकता है.
Acknowledgements
इस लेख की समीक्षा करने में मदद करने के लिए, Kenji Baheux, Fergal Daly, Adriana Jara, और Jeremy Wagner का धन्यवाद.
Unsplashपर Anja Bauermann की हीरो इमेज