منسوخ شدن رویداد تخلیه

Demián Renzulli

Barry Pollard

منتشر شده: ۱۰ آگوست ۲۰۲۳، آخرین به‌روزرسانی: ۲۹ ژانویه ۲۰۲۶

رویداد unload به تدریج با تغییر تدریجی پیش‌فرض منسوخ خواهد شد، به طوری که کنترل‌کننده‌های unload دیگر روی صفحات اجرا نمی‌شوند، مگر اینکه صفحه‌ای صریحاً تصمیم به فعال‌سازی مجدد آنها بگیرد.

جدول زمانی استهلاک

به‌روزرسانی: این جدول زمانی تا تاریخ ۲۷ آگوست ۲۰۲۵ به‌روزرسانی شده است.

ما متوجه شدیم که رفتار تخلیه احتمالاً در اوایل ژانویه ۲۰۱۹، زمانی که قصد خود را برای پیاده‌سازی حافظه پنهان back/forward اعلام کردیم، دستخوش تغییراتی خواهد شد. به موازات کار پیاده‌سازی، یک اطلاع‌رسانی گسترده انجام دادیم که منجر به کاهش قابل توجه استفاده از تخلیه شد. برای تکمیل این اطلاع‌رسانی، ما همچنین شروع به ارائه روش‌هایی برای آزمایش تأثیر منسوخ کردن تخلیه از Chrome 115 کردیم:

• در حال آزمایش با استفاده از API مربوط به Permission-Policy برای تخلیه در کروم ۱۱۵ (ژوئیه ۲۰۲۳)
• آزمایش محلی با فعال کردن یک پرچم در کروم ۱۱۷ (سپتامبر ۲۰۲۳)

در طول سال ۲۰۲۴ ما به چندین مشکل که مانع از شروع انتشار می‌شدند، رسیدگی کردیم و در طول سال ۲۰۲۵، حذف را برای ۵۰ سایت برتر اعمال کردیم.

نقطه عطف	تاریخ نقطه عطف	۵۰ سایت برتر	درصد از سایر ریشه‌ها
۱۳۵	۲۶ مارس ۲۰۲۵	۱ ( www.google.com )	0
۱۳۹	۳۰ ژوئیه ۲۰۲۵	۵	0
۱۴۰	۲۷ آگوست ۲۰۲۵	۱۰	0
۱۴۱	۲۴ سپتامبر ۲۰۲۵	۲۵	0
۱۴۲	۲۲ اکتبر ۲۰۲۵	۵۰	0

جدول زمانی منسوخ شدن ۵۰ سایت برتر.

اکنون که حذف این قابلیت را برای ۵۰ سایت برتر به پایان رسانده‌ایم، مجوز بیشتری برای انتشار آن در تمام سایت‌های مبدا، طی ۸ مرحله (یا حدود ۳۲ هفته) دریافت کرده‌ایم، همانطور که در جدول زیر شرح داده شده است.

مهم: شماره نسخه‌ها و تاریخ‌ها ممکن است تغییر کنند، زیرا ما در حال نظارت و ارزیابی تأثیر انتشار هستیم.

نقطه عطف	تاریخ نقطه عطف	۵۰ سایت برتر	درصد بارگذاری صفحات کروم برای همه سایت‌ها
۱۴۶	۱۰ مارس ۲۰۲۶	۵۰	۱
۱۴۷	۷ آوریل ۲۰۲۶	۵۰	۵
۱۴۸	۵ مه ۲۰۲۶	۵۰	۱۰
۱۴۹	۲ ژوئن ۲۰۲۶	۵۰	۲۰
۱۵۰	۳۰ ژوئن ۲۰۲۶	۵۰	۴۰
۱۵۱	۲۸ ژوئیه ۲۰۲۶	۵۰	۶۰
۱۵۲	۲۵ آگوست ۲۰۲۶	۵۰	۸۰
۱۵۳	۲۲ سپتامبر ۲۰۲۶	۵۰	۱۰۰

جدول زمانی منسوخ شدن همه سایت‌ها.

کل روند انتشار بر اساس بارگذاری صفحات (با ثبات در طول زمان) است، نه بر اساس کاربران یا سایت‌های شخصی، تا از تأثیر بیشتر بر کاربران یا سایت‌ها نسبت به سایرین، همانطور که در Intent to Deprecate شرح داده شده است، جلوگیری شود.

توجه داشته باشید که ما همچنین منویی از گزینه‌های انصراف را ارائه می‌دهیم در صورتی که این جدول زمانی منسوخ شدن، زمان کافی برای مهاجرت از unload را فراهم نکند. هدف ما استفاده از این منسوخ شدن نرم برای اطلاع‌رسانی در جدول زمانی آخرین مرحله ( منسوخ شدن سخت unload ) است که در آن این موارد لغو یا کاهش می‌یابند.

جدول زمانی استهلاک تخلیه.

پیشینه

unload طوری طراحی شده بود که هنگام تخلیه سند اجرا شود. در تئوری، می‌توان از آن برای اجرای کد در هر زمانی که کاربر در حال خروج از صفحه است یا به عنوان یک فراخوانی پایان جلسه استفاده کرد.

سناریوهایی که این رویداد بیشترین کاربرد را داشته است عبارتند از:

• ذخیره داده‌های کاربر : قبل از ترک صفحه، داده‌ها را ذخیره کنید.
• انجام وظایف پاکسازی : بستن منابع باز قبل از ترک صفحه.
• ارسال داده‌های تحلیلی : ارسال داده‌های مربوط به تعاملات کاربر در پایان جلسه.

با این حال، رویداد unload به شدت غیرقابل اعتماد است .

در کروم و فایرفاکس دسکتاپ، unload به طور قابل قبولی قابل اعتماد است، اما با جلوگیری از استفاده از bfcache (back/forward cache) تأثیر منفی بر عملکرد سایت دارد.

در مرورگرهای موبایل، unload اغلب اجرا نمی‌شود زیرا تب‌ها مرتباً در پس‌زمینه قرار می‌گیرند و سپس بسته می‌شوند. به همین دلیل، مرورگرها bfcache را در موبایل نسبت به unload در اولویت قرار می‌دهند و این باعث می‌شود که مرورگرها غیرقابل اعتمادتر شوند. سافاری نیز از این رفتار در دسکتاپ استفاده می‌کند.

تیم کروم معتقد است که استفاده از مدل موبایلیِ اولویت دادن به bfcache نسبت به unload در دسکتاپ، با غیر قابل اعتمادتر کردن آن در آنجا نیز مخرب خواهد بود ، در حالی که قبلاً این روش در کروم (و فایرفاکس) به طور معقولی قابل اعتماد بوده است. در عوض، هدف کروم حذف کامل رویداد unload است. تا آن زمان، این روش برای کسانی که صریحاً از منسوخ شدن انصراف داده‌اند، در دسکتاپ قابل اعتماد باقی خواهد ماند.

چرا رویداد unload را منسوخ کنیم؟

منسوخ کردن unload گامی کلیدی در شناخت بسیار بزرگتر وبی است که اکنون در آن زندگی می‌کنیم. رویداد unload حس کاذبی از کنترل چرخه حیات برنامه ایجاد می‌کند که به طور فزاینده‌ای با نحوه مرور وب در دنیای محاسبات مدرن مغایرت دارد.

سیستم‌عامل‌های موبایل اغلب صفحات وب را برای صرفه‌جویی در حافظه، فریز یا بارگذاری مجدد می‌کنند و مرورگرهای دسکتاپ نیز به همین دلایل، این کار را بیشتر و بیشتر انجام می‌دهند. حتی بدون دخالت سیستم‌عامل، خود کاربران اغلب بدون اینکه رسماً «صفحات را ترک کنند»، بین تب‌ها جابه‌جا می‌شوند و تب‌های قدیمی را می‌بندند.

حذف رویداد unload به عنوان رویدادی منسوخ، نشان می‌دهد که ما به عنوان توسعه‌دهندگان وب باید مطمئن شویم که الگوی ما با دنیای واقعی مطابقت دارد و به مفاهیم منسوخ‌شده‌ای که دیگر معتبر نیستند - اگر تا به حال معتبر بوده‌اند - وابسته نباشیم.

جایگزین‌هایی برای unload رویدادها

به جای unload توصیه می‌شود از موارد زیر استفاده کنید:

• visibilitychange : برای تعیین زمان تغییر قابلیت مشاهده یک صفحه. این رویداد زمانی اتفاق می‌افتد که کاربر تب‌ها را تغییر می‌دهد، پنجره مرورگر را کوچک می‌کند یا صفحه جدیدی باز می‌کند. حالت hidden را به عنوان آخرین زمان قابل اعتماد برای ذخیره داده‌های برنامه و کاربر در نظر بگیرید.
• pagehide : برای تعیین اینکه کاربر چه زمانی از صفحه خارج شده است. این رویداد زمانی اتفاق می‌افتد که کاربر از صفحه خارج شود، صفحه را مجدداً بارگذاری کند یا پنجره مرورگر را ببندد. رویداد pagehide هنگام کوچک کردن صفحه یا رفتن به تب دیگر اجرا نمی‌شود. توجه داشته باشید که از آنجایی که pagehide صفحه‌ای را برای حافظه پنهان back/forward غیرقابل استفاده نمی‌کند، ممکن است صفحه پس از اجرای این رویداد بازیابی شود. اگر در این رویداد در حال پاکسازی منابع هستید، ممکن است لازم باشد آنها را در page restore بازیابی کنید.

رویداد beforeunload کاربرد کمی متفاوتی نسبت به رویداد unload دارد، زیرا یک رویداد قابل لغو است. اغلب برای هشدار دادن به کاربران در مورد تغییرات ذخیره نشده هنگام خروج از صفحه استفاده می‌شود. این رویداد همچنین غیرقابل اعتماد است زیرا در صورت بسته شدن یک تب پس‌زمینه، اجرا نمی‌شود. توصیه می‌شود استفاده از beforeunload را محدود کنید و فقط آن را به صورت مشروط اضافه کنید . در عوض، از رویدادهای ذکر شده قبلی برای اکثر جایگزین‌های unload استفاده کنید.

برای جزئیات بیشتر، به این توصیه در مورد عدم استفاده از unload handler مراجعه کنید.

تشخیص استفاده از unload

ابزارهای مختلفی برای کمک به شما در یافتن موارد وقوع رویداد unload در صفحات وجود دارد. این به سایت‌ها اجازه می‌دهد تا متوجه شوند که آیا از این رویداد استفاده می‌کنند - چه در کد خودشان و چه در کتابخانه‌ها - و بنابراین ممکن است تحت تأثیر منسوخ شدن قریب‌الوقوع قرار گیرند.

ابزارهای توسعه کروم

Chrome DevTools شامل یک بررسی back-forward-cache است که به شما کمک می‌کند مشکلاتی را که ممکن است مانع از واجد شرایط بودن صفحه شما برای back/forward cache شود، از جمله استفاده از unload handler، شناسایی کنید.

برای آزمایش حافظه پنهان back/forward، این مراحل را دنبال کنید:

1. در صفحه خود، DevTools را باز کنید ، سپس به Application > Background services > Back/forward cache بروید.

2. روی تست حافظه پنهان برگشت/جلو کلیک کنید. کروم به‌طور خودکار شما را به chrome://terms/ و صفحه خودتان می‌برد. به‌طور جایگزین، می‌توانید روی دکمه‌های برگشت و جلو مرورگر کلیک کنید.

اگر صفحه شما واجد شرایط ذخیره سازی back/forward نباشد، تب Back/forward cache لیستی از مشکلات را به شما نشان می‌دهد. در قسمت Actionable می‌توانید ببینید که آیا unload استفاده می‌کنید یا خیر:

Chrome DevTools ابزار تست حافظه پنهان به عقب/جلو.

گزارش API

API گزارش‌دهی می‌تواند در کنار یک سیاست مجوز فقط خواندنی برای تشخیص استفاده از unload از سوی کاربران وب‌سایت شما مورد استفاده قرار گیرد.

برای جزئیات بیشتر ، به استفاده از API گزارش‌دهی برای یافتن تخلیه‌ها مراجعه کنید.

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

کروم به تدریج رویداد unload منسوخ خواهد کرد. در این میان، می‌توانید از ابزارهای مختلفی برای کنترل این رفتار استفاده کنید و برای منسوخ شدن قریب‌الوقوع آماده شوید. به خاطر داشته باشید که نباید در درازمدت به این تکنیک‌ها تکیه کنید و باید در اسرع وقت برای مهاجرت به جایگزین‌ها برنامه‌ریزی کنید.

گزینه‌های زیر به شما امکان می‌دهند تا unload handlers را فعال یا غیرفعال کنید تا آزمایش کنید که سایت شما بدون آنها چگونه کار می‌کند تا بتوانید برای منسوخ شدن قریب‌الوقوع آماده شوید. انواع مختلفی از سیاست‌ها وجود دارد:

• سیاست دسترسی‌ها : این یک API پلتفرم برای صاحبان سایت است تا با استفاده از هدرهای HTTP، دسترسی به ویژگی‌ها را در سطح یک سایت یا یک صفحه خاص کنترل کنند.
• سیاست‌های سازمانی : ابزارهایی برای مدیران فناوری اطلاعات جهت پیکربندی کروم برای سازمان یا کسب‌وکارشان. این ابزارها را می‌توان با استفاده از یک پنل مدیریتی، مانند کنسول مدیریتی گوگل ، پیکربندی کرد.
• پرچم‌های کروم : این به یک توسعه‌دهنده اجازه می‌دهد تا تنظیمات unload را تغییر دهد تا تأثیر آن را در سایت‌های مختلف آزمایش کند.

سیاست مجوزها

یک سیاست مجوز از کروم ۱۱۵ اضافه شده است تا به سایت‌ها اجازه دهد از استفاده از unload handlers خودداری کنند و بلافاصله از bfcache برای بهبود عملکرد سایت بهره‌مند شوند. برای نحوه تنظیم این مورد برای سایت خود، به این مثال‌ها مراجعه کنید. این به سایت‌ها اجازه می‌دهد تا از منسوخ شدن unload جلوگیری کنند.

این قابلیت در کروم ۱۱۷ توسعه داده خواهد شد تا به سایت‌ها اجازه دهد عکس این عمل را انجام دهند و در صورت عدم فعال‌سازی مجدد کنترل‌کننده‌های unload ، به تلاش برای فعال‌سازی آن‌ها ادامه دهند، زیرا کروم پیش‌فرض این کنترل‌کننده‌ها را به گونه‌ای تغییر می‌دهد که در آینده فعال نشوند. برای نحوه‌ی فعال‌سازی مجدد کنترل‌کننده‌های unload در سایت خود، به این مثال‌ها مراجعه کنید. این گزینه برای همیشه باقی نمی‌ماند و باید برای زمانی که سایت‌ها می‌توانند از کنترل‌کننده‌های unload مهاجرت کنند، استفاده شود.

سیاست سازمانی

شرکت‌هایی که نرم‌افزاری دارند که برای عملکرد صحیح به رویداد unload وابسته است، می‌توانند از سیاست ForcePermissionPolicyUnloadDefaultEnabled برای جلوگیری از منسوخ شدن تدریجی دستگاه‌های تحت کنترل خود استفاده کنند. با فعال کردن این سیاست، unload برای همه مبداها به طور پیش‌فرض روی فعال باقی می‌ماند. یک صفحه می‌تواند در صورت تمایل، سیاست سختگیرانه‌تری را تنظیم کند. مانند گزینه لغو سیاست مجوزها، این ابزاری برای کاهش تغییرات احتمالی است، اما نباید به طور نامحدود استفاده شود.

پرچم‌های کروم و کلیدهای خط فرمان

علاوه بر سیاست سازمانی، می‌توانید با استفاده از پرچم‌های کروم و کلیدهای خط فرمان، منسوخ شدن را برای کاربران شخصی غیرفعال کنید:

تنظیم chrome://flags/#deprecate-unload this به enabled ، پیش‌فرض deprecation را به حالت قبل برمی‌گرداند و از فعال شدن unload handlerها جلوگیری می‌کند. آن‌ها همچنان می‌توانند با استفاده از Permissions Policy به صورت سایت به سایت لغو شوند، اما به طور پیش‌فرض فعال خواهند ماند.

این تنظیمات را می‌توان با کلیدهای خط فرمان نیز کنترل کرد.

مقایسه گزینه‌ها

جدول زیر کاربردهای مختلف گزینه‌های مورد بحث قبلی را خلاصه می‌کند:

	استهلاک را به جلو بیاورید	منسوخ شدن را به جلو بیاورید (با استثنائات)	جلوگیری از منسوخ شدن برای تضمین زمان برای مهاجرت
سیاست مجوزها (مربوط به صفحات/سایت‌ها)	بله	بله	بله
سیاست سازمانی (مربوط به دستگاه‌ها)	خیر	خیر	بله
پرچم‌های کروم (برای کاربران شخصی اعمال می‌شود)	بله	خیر	خیر
کلیدهای خط فرمان کروم (برای کاربران شخصی اعمال می‌شود)	بله	خیر	بله

نتیجه‌گیری

کنترل‌کننده‌های unload منسوخ شده‌اند. آن‌ها مدت زیادی است که غیرقابل اعتماد بوده‌اند و تضمینی وجود ندارد که در تمام مواردی که یک سند از بین می‌رود، اجرا شوند. علاوه بر این، کنترل‌کننده‌های unload با bfcache سازگار نیستند.

سایت‌هایی که از unload handlers استفاده می‌کنند، باید با آزمایش هرگونه unload handlers موجود، حذف یا انتقال آنها یا به عنوان آخرین راه حل، به تأخیر انداختن منسوخ شدن در صورت نیاز به زمان بیشتر، برای این منسوخ شدن قریب‌الوقوع آماده شوند.

تقدیرنامه‌ها

با تشکر از کنجی باهوکس، فرگال دالی، آدریانا جارا و جرمی واگنر برای کمک به بررسی این مقاله.

تصویر قهرمان اثر آنیا باوئرمن در Unsplash