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

Demián Renzulli

Barry Pollard

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

جدول زمانی منسوخ شدن

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

• آزمایش در طبیعت از طریق Permission-Policy API برای بارگیری در Chrome 115 (ژوئیه 2023)
• آزمایش محلی با فعال کردن یک پرچم در Chrome 117 (سپتامبر 2023)

پس از این مراحل فرادستی و آزمایشی، در اینجا انتظار داریم که استهلاک نرم گسترش یابد:

• مرحله ای محدوده که در آن تخلیه به تدریج برای 50 سایت محبوب برتر ( مرجع تا زمان نگارش) از کار می افتد.
  • شروع با 1٪ از کاربران از Chrome 120 (پایان نوامبر 2023).
  • پایان سه ماهه سوم سال 2024 با 100٪ از کاربران
• علاوه بر این، از سه ماهه سوم 2024، ما قصد داریم یک مرحله عمومی را شروع کنیم که در آن تخلیه به تدریج در هر سایتی متوقف می شود، از 1٪ کاربران شروع می شود و تا پایان سه ماهه اول 2025 با 100٪ از کاربران پایان می یابد.

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

زمینه

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

سناریوهایی که این رویداد بیشتر مورد استفاده قرار گرفت عبارتند از:

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

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

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

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

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

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

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

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

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

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

به جای unload ، توصیه می شود از:

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

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

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

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

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

فانوس دریایی

Lighthouse دارای یک ممیزی no-unload-listeners است که به توسعه دهندگان هشدار می دهد اگر جاوا اسکریپت در صفحات آنها (از جمله از کتابخانه های شخص ثالث) شنونده رویداد unload اضافه کند.

Chrome DevTools

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

برای آزمایش کش برگشت/به جلو، مراحل زیر را دنبال کنید:

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

2. روی Test back/forward cache کلیک کنید Chrome به طور خودکار شما را به chrome://terms/ می برد و به صفحه خود باز می گرداند. همچنین، می‌توانید روی دکمه‌های برگشت و جلو مرورگر کلیک کنید.

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

گزارش API

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

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

Bfcache notRestoredReasons API

ویژگی notRestoredReasons - که به کلاس PerformanceNavigationTiming اضافه شده است - اطلاعاتی را گزارش می دهد که آیا اسناد از استفاده از bfcache در مسیریابی مسدود شده اند یا خیر. دستورالعمل استفاده را می توان در اینجا یافت. این نمونه ای از نحوه اخطار شی پاسخ یک شنونده unload موجود است:

{
   children: [],
   id: null,
   name: null,
   reasons: [
     {"reason", "unload-handler"}
   ],
   src: null,
   url: "https://www.example.com/page/"
}

کنترل دسترسی برای unload

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

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

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

خط مشی مجوزها

یک خط‌مشی مجوزها از Chrome 115 اضافه شده است تا به سایت‌ها اجازه دهد از استفاده از کنترل‌کننده‌های unload انصراف دهند و فوراً از bfcache برای بهبود عملکرد سایت بهره‌مند شوند. این نمونه ها را در مورد نحوه تنظیم این برای سایت خود ببینید. این به سایت‌ها اجازه می‌دهد تا از unload بارگذاری پیشی بگیرند.

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

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

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

پرچم های کروم و سوئیچ های خط فرمان

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

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

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

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

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

نتیجه

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

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

سپاسگزاریها

با تشکر از Kenji Baheux، Fergal Daly، Adriana Jara، و Jeremy Wagner برای کمک به بررسی این مقاله.

تصویر قهرمان توسط Anja Bauermann در Unsplash