প্রকাশিত: ১০ আগস্ট, ২০২৩, সর্বশেষ হালনাগাদ: ২৮ এপ্রিল, ২০২৬
ডিফল্ট সেটিংস পর্যায়ক্রমে পরিবর্তন করার মাধ্যমে unload ইভেন্টটি ধীরে ধীরে অপ্রচলিত করা হবে, যাতে কোনো পেজ স্পষ্টভাবে পুনরায় চালু করার সিদ্ধান্ত না নিলে, সেই পেজে unload হ্যান্ডলারগুলো আর কাজ না করে।
অবচয় সময়রেখা
আমরা ২০১৯ সালের জানুয়ারিতেই উল্লেখ করেছিলাম যে আনলোড আচরণে সম্ভবত পরিবর্তন আসবে, যখন আমরা একটি ব্যাক/ফরোয়ার্ড ক্যাশে বাস্তবায়নের অভিপ্রায় ঘোষণা করি। এই বাস্তবায়নের কাজের পাশাপাশি, আমরা একটি ব্যাপক প্রচার অভিযান পরিচালনা করি, যার ফলে আনলোডের ব্যবহার উল্লেখযোগ্যভাবে কমে যায়। এই প্রচারের পরিপূরক হিসেবে, আমরা ক্রোম ১১৫ থেকে আনলোডকে অপ্রচলিত ঘোষণা করার প্রভাব পরীক্ষা করার উপায়ও প্রদান করতে শুরু করি:
- ক্রোম ১১৫ (জুলাই ২০২৩)-এ আনলোড করার জন্য পারমিশন-পলিসি এপিআই ব্যবহার করে বাস্তব প্রয়োগে পরীক্ষা।
- ক্রোম ১১৭ (সেপ্টেম্বর ২০২৩)-এ একটি ফ্ল্যাগ সক্রিয় করে স্থানীয় পরীক্ষা
২০২৪ সাল জুড়ে আমরা রোলআউট শুরু হতে বাধা সৃষ্টিকারী বেশ কিছু সমস্যার সমাধান করেছি এবং ২০২৫ সাল জুড়ে শীর্ষ ৫০টি সাইটে ডেপ্রিকেশনটি রোল আউট করেছি।
| মাইলফলক | মাইলফলক তারিখ | শীর্ষ ৫০টি সাইট | অন্যান্য উৎসের % |
|---|---|---|---|
| ১৩৫ | ২৬ মার্চ, ২০২৫ | ১ ( www.google.com ) | ০ |
| ১৩৯ | ৩০ জুলাই, ২০২৫ | ৫ | ০ |
| ১৪০ | ২৭ আগস্ট, ২০২৫ | ১০ | ০ |
| ১৪১ | ২৪ সেপ্টেম্বর, ২০২৫ | ২৫ | ০ |
| ১৪২ | ২২ অক্টোবর, ২০২৫ | ৫০ | ০ |
শীর্ষ ৫০টি সাইটের জন্য বাতিলকরণ সম্পন্ন করার পর, আমরা এখন ৮টি মাইলস্টোন (বা প্রায় ৩২ সপ্তাহ) জুড়ে সমস্ত অরিজিনে এটি চালু করার জন্য আরও অনুমোদন পেয়েছি, যা নিম্নলিখিত সারণীতে বিস্তারিতভাবে উল্লেখ করা হয়েছে।
| মাইলফলক | মাইলফলক তারিখ | শীর্ষ ৫০টি সাইট | সমস্ত সাইটের জন্য ক্রোম পেজ লোডের শতাংশ |
|---|---|---|---|
| ১৪৬ | ১০ মার্চ, ২০২৬ | ৫০ | ১ |
| ১৪৭ | ৭ এপ্রিল, ২০২৬ | ৫০ | ৫ |
| ১৪৮ | ৫ মে, ২০২৬ | ৫০ | ১০ |
| ১৪৯ | ২ জুন, ২০২৬ | ৫০ | ২০ |
| ১৫০ | ৩০ জুন, ২০২৬ | ৫০ | ৪০ |
| ১৫১ | ২৮ জুলাই, ২০২৬ | ৫০ | ৬০ |
| ১৫২ | ২৫ আগস্ট, ২০২৬ | ৫০ | ৮০ |
| ১৫৩ | ২২ সেপ্টেম্বর, ২০২৬ | ৫০ | ১০০ |
‘Intent to Deprecate’-এ বিস্তারিতভাবে বর্ণিত বিষয় অনুযায়ী, কোনো ব্যবহারকারী বা সাইট যাতে অন্যদের তুলনায় বেশি প্রভাবিত না হয়, তা এড়ানোর জন্য সম্পূর্ণ রোলআউটটি কোনো স্বতন্ত্র ব্যবহারকারী বা সাইটের উপর ভিত্তি করে না করে, বরং পেজ লোডের উপর ভিত্তি করে (সময়ের সাথে সামঞ্জস্য রেখে) করা হচ্ছে।
উল্লেখ্য যে, যদি এই অবলুপ্তির সময়সীমা আনলোড থেকে সরে আসার জন্য পর্যাপ্ত সময় না দেয়, তবে আমরা অপ্ট-আউট বিকল্পগুলির একটি মেনুও প্রদান করি। আমাদের লক্ষ্য হলো এই সফট অবলুপ্তি ব্যবহার করে শেষ পর্যায়ের ( আনলোডের হার্ড অবলুপ্তি ) সময়সীমা সম্পর্কে জানানো, যে পর্যায়ে এই অপ্ট-আউটগুলি সরিয়ে ফেলা হবে বা কমিয়ে আনা হবে।
পটভূমি
ডকুমেন্ট আনলোড করার সময় unload চালু হওয়ার জন্য ডিজাইন করা হয়েছিল। তত্ত্বগতভাবে, ব্যবহারকারী যখনই কোনো পৃষ্ঠা থেকে অন্য পৃষ্ঠায় চলে যান, তখন কোড চালানোর জন্য অথবা সেশন শেষের কলব্যাক হিসেবেও এটি ব্যবহার করা যেতে পারে।
যেসব পরিস্থিতিতে এই ইভেন্টটি সবচেয়ে বেশি ব্যবহৃত হয়েছে, সেগুলো হলো:
- ব্যবহারকারীর তথ্য সংরক্ষণ : পৃষ্ঠাটি ছাড়ার আগে তথ্য সংরক্ষণ করুন।
- পরিষ্করণমূলক কাজ সম্পাদন করা : পৃষ্ঠাটি পরিত্যাগ করার আগে খোলা রিসোর্সগুলো বন্ধ করা।
- অ্যানালিটিক্স পাঠানো : সেশনের শেষে ব্যবহারকারীর কার্যকলাপ সম্পর্কিত ডেটা পাঠানো।
তবে unload ইভেন্টটি অত্যন্ত অনির্ভরযোগ্য ।
ডেস্কটপ ক্রোম এবং ফায়ারফক্সে, unload মোটামুটি নির্ভরযোগ্য হলেও এটি বিএফক্যাশ (ব্যাক/ফরোয়ার্ড ক্যাশে) ব্যবহারে বাধা দিয়ে সাইটের পারফরম্যান্সে নেতিবাচক প্রভাব ফেলে।
মোবাইল ব্রাউজারে প্রায়শই ট্যাবগুলো ব্যাকগ্রাউন্ডে চলে যায় এবং পরে বন্ধ হয়ে যায় বলে unload চলে না। এই কারণে ব্রাউজারগুলো মোবাইলে unload চেয়ে বিএফক্যাশকে (bfcache) বেশি অগ্রাধিকার দেয়, যা সেগুলোকে আরও বেশি অনির্ভরযোগ্য করে তোলে। সাফারিও ডেস্কটপে এই একই আচরণ করে।
ক্রোম টিমের মতে, ডেস্কটপে unload চেয়ে বিএফক্যাশকে (bfcache) অগ্রাধিকার দেওয়ার মোবাইল মডেলটি ব্যবহার করলে তা বিঘ্ন ঘটাবে, কারণ এতে ডেস্কটপেও এটি আরও অনির্ভরযোগ্য হয়ে পড়বে, যেখানে আগে এটি ক্রোম (এবং ফায়ারফক্স)-এ যথেষ্ট নির্ভরযোগ্য ছিল। এর পরিবর্তে, ক্রোমের লক্ষ্য হলো unload ইভেন্টটি সম্পূর্ণরূপে সরিয়ে ফেলা। ততদিন পর্যন্ত, যারা স্পষ্টভাবে এই ডেপ্রিকেশন থেকে অপ্ট-আউট করেছেন, তাদের জন্য এটি ডেস্কটপে নির্ভরযোগ্য থাকবে।
unload ইভেন্টটি কেন অপ্রচলিত করা হচ্ছে?
আনলোড unload অপ্রচলিত ঘোষণা করা হলো আমরা এখন যে ওয়েব জগতে বাস করি, তার একটি বৃহত্তর উপলব্ধির দিকে একটি গুরুত্বপূর্ণ পদক্ষেপ। unload ইভেন্টটি অ্যাপের জীবনচক্রের উপর নিয়ন্ত্রণের একটি ভ্রান্ত ধারণা দেয়, যা আধুনিক কম্পিউটিং জগতে আমরা যেভাবে ওয়েব ব্রাউজ করি তার ক্ষেত্রে ক্রমশ অসত্য হয়ে উঠছে।
মোবাইল অপারেটিং সিস্টেমগুলো মেমরি সাশ্রয়ের জন্য প্রায়শই ওয়েব পেজ ফ্রিজ বা আনলোড করে দেয় এবং একই কারণে ডেস্কটপ ব্রাউজারগুলোও এখন দিন দিন এমনটা করছে। এমনকি অপারেটিং সিস্টেমের হস্তক্ষেপ ছাড়াও, ব্যবহারকারীরা নিজেরাই প্রায়শই আনুষ্ঠানিকভাবে 'পেজ ত্যাগ' না করেই ট্যাব পরিবর্তন করেন এবং পুরোনো ট্যাব বন্ধ করে দেন।
unload ইভেন্টকে অপ্রচলিত হিসেবে অপসারণ করার অর্থ হলো এই স্বীকৃতি দেওয়া যে, ওয়েব ডেভেলপার হিসেবে আমাদের কর্মপদ্ধতি যেন বাস্তব জগতের সাথে সামঞ্জস্যপূর্ণ হয় এবং এমন পুরোনো ধারণার উপর নির্ভর না করি যা এখন আর সত্য নয়—যদি আদৌ কখনো সত্য হয়ে থাকে।
ইভেন্ট unload বিকল্প
unload পরিবর্তে এটি ব্যবহার করার পরামর্শ দেওয়া হয়:
-
visibilitychange: কোনো পৃষ্ঠার দৃশ্যমানতা কখন পরিবর্তিত হয় তা নির্ধারণ করার জন্য। এই ইভেন্টটি ঘটে যখন ব্যবহারকারী ট্যাব পরিবর্তন করেন, ব্রাউজার উইন্ডো মিনিমাইজ করেন, বা একটি নতুন পৃষ্ঠা খোলেন। অ্যাপ এবং ব্যবহারকারীর ডেটা সংরক্ষণের জন্যhiddenঅবস্থাকেই শেষ নির্ভরযোগ্য সময় হিসেবে বিবেচনা করুন। -
pagehide: ব্যবহারকারী কখন পৃষ্ঠা থেকে অন্য কোথাও চলে গেছেন তা নির্ধারণ করার জন্য। এই ইভেন্টটি ঘটে যখন ব্যবহারকারী পৃষ্ঠা থেকে অন্য কোথাও চলে যান, পৃষ্ঠাটি রিলোড করেন, বা ব্রাউজার উইন্ডো বন্ধ করেন। পৃষ্ঠাটি মিনিমাইজ করা হলে বা অন্য ট্যাবে সুইচ করা হলেpagehideইভেন্টটি ফায়ার হয় না। মনে রাখবেন, যেহেতুpagehideকোনো পৃষ্ঠাকে ব্যাক/ফরোয়ার্ড ক্যাশের জন্য অযোগ্য করে না, তাই এই ইভেন্টটি ফায়ার হওয়ার পরেও পৃষ্ঠাটি পুনরুদ্ধার করা সম্ভব। আপনি যদি এই ইভেন্টে কোনো রিসোর্স পরিষ্কার করেন, তাহলে পৃষ্ঠা পুনরুদ্ধারের সময় সেগুলিও পুনরুদ্ধার করতে হতে পারে।
beforeunload ইভেন্টের ব্যবহার unload থেকে কিছুটা ভিন্ন, কারণ এটি একটি বাতিলযোগ্য ইভেন্ট। অন্য ট্যাবে যাওয়ার সময় সেভ না করা পরিবর্তন সম্পর্কে ব্যবহারকারীদের সতর্ক করতে এটি প্রায়শই ব্যবহৃত হয়। এই ইভেন্টটি নির্ভরযোগ্যও নয়, কারণ ব্যাকগ্রাউন্ড ট্যাব বন্ধ করে দিলে এটি ফায়ার হয় না। beforeunload এর ব্যবহার সীমিত রাখার এবং শুধুমাত্র শর্তসাপেক্ষে এটি যোগ করার পরামর্শ দেওয়া হয়। এর পরিবর্তে, বেশিরভাগ unload প্রতিস্থাপনের জন্য পূর্বে উল্লিখিত ইভেন্টগুলো ব্যবহার করুন।
আরও বিস্তারিত জানতে, unload হ্যান্ডলার কখনই ব্যবহার না করার বিষয়ে এই পরামর্শটি দেখুন।
unload ব্যবহার শনাক্ত করুন
পেজগুলিতে unload ইভেন্টের উপস্থিতি খুঁজে বের করার জন্য বিভিন্ন টুল রয়েছে। এর মাধ্যমে সাইটগুলি জানতে পারে যে তারা এই ইভেন্টটি ব্যবহার করছে কিনা—তাদের নিজস্ব কোডে বা লাইব্রেরি ব্যবহার করে—এবং এর ফলে আসন্ন ডেপ্রিকেশনের দ্বারা প্রভাবিত হতে পারে কিনা।
ক্রোম ডেভটুলস
ক্রোম ডেভটুলস-এ একটি back-forward-cache অডিট অন্তর্ভুক্ত রয়েছে, যা আপনাকে এমন সব সমস্যা শনাক্ত করতে সাহায্য করে যা আপনার পেজকে ব্যাক/ফরোয়ার্ড ক্যাশের জন্য যোগ্য হতে বাধা দিতে পারে, যার মধ্যে unload হ্যান্ডলারের ব্যবহারও রয়েছে।
ব্যাক/ফরোয়ার্ড ক্যাশে পরীক্ষা করতে, এই ধাপগুলো অনুসরণ করুন:
আপনার পেজে DevTools খুলুন , তারপর Application > Background services > Back/forward cache- এ যান।
‘টেস্ট ব্যাক/ফরোয়ার্ড ক্যাশে’ ক্লিক করলে ক্রোম স্বয়ংক্রিয়ভাবে আপনাকে
chrome://terms/নিয়ে যাবে এবং আপনার পেজে ফিরিয়ে আনবে। বিকল্পভাবে, আপনি ব্রাউজারের ব্যাক এবং ফরোয়ার্ড বাটনগুলোতেও ক্লিক করতে পারেন।
যদি আপনার পেজটি ব্যাক/ফরোয়ার্ড ক্যাশিংয়ের জন্য উপযুক্ত না হয়, তাহলে 'ব্যাক/ফরোয়ার্ড ক্যাশ' ট্যাবটি আপনাকে সমস্যাগুলোর একটি তালিকা দেখাবে। 'অ্যাকশনেবল' এর অধীনে, আপনি দেখতে পারবেন যে আপনি unload ব্যবহার করছেন কিনা।
রিপোর্টিং এপিআই
আপনার ওয়েবসাইটের ব্যবহারকারীদের দ্বারা unload ব্যবহার শনাক্ত করতে রিপোর্টিং এপিআই একটি রিড-অনলি পারমিশন পলিসির সাথে একত্রে ব্যবহার করা যেতে পারে।
আরও বিস্তারিত জানতে, আনলোডগুলি খুঁজে পেতে রিপোর্টিং এপিআই-এর ব্যবহার দেখুন।
Bfcache notRestoredReasons API
PerformanceNavigationTiming ক্লাসে যুক্ত হওয়া notRestoredReasons প্রপার্টিটি জানায় যে, ন্যাভিগেশনের সময় ডকুমেন্টগুলোকে bfcache ব্যবহার করা থেকে ব্লক করা হয়েছিল কিনা এবং কেন। একটি বিদ্যমান unload লিসেনারের রেসপন্স অবজেক্ট ওয়ার্নিং দেখতে কেমন হয়, তার একটি উদাহরণ নিচে দেওয়া হলো:
{
children: [],
id: null,
name: null,
reasons: [
{"reason", "unload-listener"}
],
src: null,
url: "https://www.example.com/page/"
}
unload জন্য প্রবেশাধিকার নিয়ন্ত্রণ করুন
ক্রোম পর্যায়ক্রমে unload ইভেন্টটি বাতিল করে দেবে। এই সময়ের মধ্যে, আপনি এই আচরণটি নিয়ন্ত্রণ করতে এবং আসন্ন বাতিলকরণের জন্য প্রস্তুত হতে বিভিন্ন টুল ব্যবহার করতে পারেন। মনে রাখবেন যে দীর্ঘমেয়াদে আপনার এই কৌশলগুলির উপর নির্ভর করা উচিত নয়, এবং যত তাড়াতাড়ি সম্ভব এর পরিবর্তে বিকল্পগুলিতে স্থানান্তরিত হওয়ার পরিকল্পনা করা উচিত।
নিম্নলিখিত বিকল্পগুলি আপনাকে unload হ্যান্ডলারগুলি সক্ষম বা নিষ্ক্রিয় করার সুযোগ দেয়, যাতে আপনি সেগুলি ছাড়া আপনার সাইট কীভাবে কাজ করবে তা পরীক্ষা করতে পারেন এবং আসন্ন অবলুপ্তির জন্য প্রস্তুতি নিতে পারেন। বিভিন্ন ধরণের নীতি রয়েছে:
- অনুমতি নীতি : এটি একটি প্ল্যাটফর্ম এপিআই, যার মাধ্যমে সাইটের মালিকরা HTTP হেডার ব্যবহার করে একটি সাইট বা স্বতন্ত্র পেজ পর্যায়ে বিভিন্ন ফিচারের অ্যাক্সেস নিয়ন্ত্রণ করতে পারেন।
- এন্টারপ্রাইজ পলিসি : আইটি অ্যাডমিনদের জন্য তাদের সংস্থা বা ব্যবসার জন্য ক্রোম কনফিগার করার টুল। এগুলো গুগল অ্যাডমিন কনসোলের মতো একটি অ্যাডমিনিস্ট্রেটর প্যানেল ব্যবহার করে কনফিগার করা যায়।
- ক্রোম ফ্ল্যাগ : এটি একজন স্বতন্ত্র ডেভেলপারকে বিভিন্ন সাইটে এর প্রভাব পরীক্ষা করার জন্য
unloadডেপ্রিকেশন সেটিং পরিবর্তন করার সুযোগ দেয়।
অনুমতি নীতি
ক্রোম ১১৫ থেকে একটি অনুমতি নীতি (Permissions Policy) যোগ করা হয়েছে, যা সাইটগুলোকে unload হ্যান্ডলার ব্যবহার না করার সুযোগ দেয় এবং সাইটের পারফরম্যান্স উন্নত করার জন্য তাৎক্ষণিকভাবে বিএফক্যাশ (bfcache) থেকে সুবিধা পেতে সাহায্য করে। আপনার সাইটের জন্য এটি কীভাবে সেট করবেন, তা জানতে এই উদাহরণগুলো দেখুন। এর ফলে সাইটগুলো unload অপ্রচলিত হওয়ার আগেই প্রস্তুতি নিতে পারে।
ক্রোম ১১৭-এ এই সুবিধাটি প্রসারিত করা হয়েছে , যাতে সাইটগুলো এর বিপরীত কাজটি করতে পারে এবং এখনকার মতোই unload হ্যান্ডলার চালু করার চেষ্টা চালিয়ে যাওয়ার জন্য অপ্ট-ইন করতে পারে, কারণ ভবিষ্যতে ক্রোম এগুলোর ডিফল্ট চালু না করার নিয়ম পরিবর্তন করবে। আপনার সাইটের জন্য কীভাবে আনলোড হ্যান্ডলার চালু রাখা চালিয়ে যাবেন, তা জানতে এই উদাহরণগুলো দেখুন। যদিও আমরা সাইটের মালিকদের unload হ্যান্ডলারের অনির্ভরযোগ্যতার কারণে এটি ব্যবহার করা থেকে সরে আসতে উৎসাহিত করব, তবুও যেসব সাইটের এটি ব্যবহার করা প্রয়োজন, তাদের জন্য আমরা ভবিষ্যতেও এই অপ্ট-আউট সুবিধাটি সমর্থন করার পরিকল্পনা করছি। এছাড়াও, পুনরায় অপ্ট-ইন করলে মোবাইলে unload হ্যান্ডলারগুলো আরও নির্ভরযোগ্য হয়ে ওঠে না—এটি কেবল বর্তমান স্থিতাবস্থা পুনরুদ্ধার করে।
এন্টারপ্রাইজ নীতি
যেসব প্রতিষ্ঠানের সফটওয়্যার সঠিকভাবে কাজ করার জন্য unload ইভেন্টের উপর নির্ভর করে, তারা তাদের নিয়ন্ত্রণে থাকা ডিভাইসগুলোর জন্য এই সুবিধাটির পর্যায়ক্রমিক বিলুপ্তি রোধ করতে ForcePermissionPolicyUnloadDefaultEnabled পলিসিটি ব্যবহার করতে পারে। এই পলিসিটি সক্রিয় করার মাধ্যমে, সমস্ত অরিজিনের জন্য unload ডিফল্টরূপে সক্রিয় থাকবে। কোনো পেজ চাইলে আরও কঠোর পলিসি সেট করতে পারে। পারমিশন পলিসি অপ্ট-আউটের মতোই, এটিও সম্ভাব্য বড় ধরনের পরিবর্তনগুলো প্রশমিত করার একটি উপায়। আবারও, আমরা সাইটের মালিকদের unload হ্যান্ডলারের উপর নির্ভর করা বন্ধ করতে উৎসাহিত করব, কিন্তু যেসব সাইটের এটি ব্যবহার করার প্রয়োজন আছে, তাদের জন্য ক্রোম ভবিষ্যতে এই এন্টারপ্রাইজ অপ্ট-আউটটি সমর্থন করার পরিকল্পনা করছে।
ক্রোম ফ্ল্যাগ এবং কমান্ড লাইন সুইচ
এন্টারপ্রাইজ পলিসির পাশাপাশি, আপনি ক্রোম ফ্ল্যাগ এবং কমান্ড লাইন সুইচ ব্যবহার করে স্বতন্ত্র ব্যবহারকারীদের জন্য ডেপ্রিকেশন নিষ্ক্রিয় করতে পারেন:
chrome://flags/#deprecate-unload কে ` enabled এ সেট করলে ডেপ্রিকেশনের ডিফল্টটি এগিয়ে আসবে এবং unload হ্যান্ডলারগুলো ফায়ার হওয়া বন্ধ করে দেবে। পারমিশন পলিসি ব্যবহার করে সাইট-বাই-সাইট ভিত্তিতে এগুলোকে ওভাররাইড করা গেলেও, ডিফল্টভাবে এগুলো ফায়ার হতে থাকবে।
এই সেটিংগুলো কমান্ড লাইন সুইচের মাধ্যমেও নিয়ন্ত্রণ করা যায়।
বিকল্প তুলনা
নিম্নলিখিত সারণিতে পূর্বে আলোচিত অপশনগুলোর বিভিন্ন ব্যবহার সংক্ষেপে তুলে ধরা হলো:
| অবচয়কে সামনে আনুন | ব্যতিক্রম সাপেক্ষে অবচয়কে এগিয়ে আনুন | মাইগ্রেশনের জন্য সময় সুরক্ষিত করতে অপ্রচলিত হওয়া রোধ করুন। | |
|---|---|---|---|
| অনুমতি নীতি (পৃষ্ঠা/সাইটগুলির ক্ষেত্রে প্রযোজ্য) | হ্যাঁ | হ্যাঁ | হ্যাঁ |
| এন্টারপ্রাইজ নীতি (ডিভাইসগুলির ক্ষেত্রে প্রযোজ্য) | না | না | হ্যাঁ |
| ক্রোম পতাকা (ব্যক্তিগত ব্যবহারকারীদের জন্য প্রযোজ্য) | হ্যাঁ | না | না |
| ক্রোম কমান্ড লাইন সুইচ (ব্যক্তিগত ব্যবহারকারীদের জন্য প্রযোজ্য) | হ্যাঁ | না | হ্যাঁ |
উপসংহার
unload হ্যান্ডলারগুলো এখন আর ব্যবহার করা হচ্ছে না। এগুলো দীর্ঘদিন ধরে নির্ভরযোগ্য নয় এবং কোনো ডকুমেন্ট ধ্বংস হওয়ার সব ক্ষেত্রে যে এগুলো কার্যকর হবে, তার কোনো নিশ্চয়তা নেই। এছাড়াও, unload হ্যান্ডলারগুলো বিএফক্যাশ (bfcache) -এর সাথে সামঞ্জস্যপূর্ণ নয়।
যেসব সাইট unload হ্যান্ডলার ব্যবহার করে, তাদের এই আসন্ন ডেপ্রিকেশনের জন্য প্রস্তুত হওয়া উচিত। এর জন্য তাদের বিদ্যমান unload হ্যান্ডলারগুলো পরীক্ষা করতে হবে, সেগুলোকে সরিয়ে ফেলতে বা মাইগ্রেট করতে হবে, অথবা শেষ উপায় হিসেবে, আরও সময়ের প্রয়োজন হলে ডেপ্রিকেশনটি বিলম্বিত করতে হবে।
কৃতজ্ঞতা স্বীকার
এই নিবন্ধটি পর্যালোচনায় সাহায্যের জন্য কেনজি বাহেউক্স, ফার্গাল ডেলি, আদ্রিয়ানা জারা এবং জেরেমি ওয়াগনারকে ধন্যবাদ।
আনস্প্ল্যাশে আনিয়া বাউয়ারম্যানের তোলা প্রধান ছবি।