إيقاف حدث إلغاء التحميل نهائيًا

Demián Renzulli

Barry Pollard

تاريخ النشر: 10 آب (أغسطس) 2023، تاريخ التعديل الأخير: 11 آذار (مارس) 2025

سيتم إيقاف حدث unload نهائيًا تدريجيًا من خلال تغيير الإعداد التلقائي تدريجيًا حتى تتوقف معالِجات unload عن تنشيط الأحداث على الصفحات ما لم تختار الصفحة تفعيلها صراحةً من جديد.

المخطط الزمني للإيقاف النهائي

تعديل: تم تعديل هذا المخطط الزمني اعتبارًا من 11 آذار (مارس) 2025.

لقد لاحظنا أنّ سلوك التفريغ قد يخضع للتغييرات في أقرب وقت ممكن منذ كانون الثاني (يناير) 2019، عندما أعلنّا عن نيتنا في تنفيذ ميزة "التخزين المؤقت للصفحات". بالتوازي مع عمل التنفيذ، أجرينا حملة إرشادية كبيرة أدّت إلى انخفاض كبير في استخدام unload. ولإكمال هذه الجهود، بدأنا أيضًا في تقديم طرق لاختبار تأثير إيقاف unload نهائيًا من الإصدار 115 من Chrome:

• الاختبار العلني باستخدام Permission-Policy API لتفريغ الذاكرة في الإصدار 115 من Chrome (يوليو 2023)
• الاختبار على الجهاز من خلال تفعيل ميزة تجريبية في الإصدار 117 من Chrome (أيلول/سبتمبر 2023)

خلال عام 2024، عالجنا العديد من المشاكل التي كانت تمنع بدء عملية الطرح.

في ما يلي المخطط الزمني الحالي لإيقاف حدث unload نهائيًا:

ملاحظة مهمة: يمكن أن تتغيّر أرقام الإصدارات والتواريخ أثناء رصدنا وتقييمنا لتأثير عملية الطرح.

Milestone	تاريخ الإنجاز	أهم 50 موقعًا إلكترونيًا	النسبة المئوية للزيارات الواردة من مصادر أخرى
135	26 آذار (مارس) 2025	1 (www.google.com)	0
136	23 نيسان (أبريل) 2025	5	0
137	21 أيار (مايو) 2025	25	0
138	18 حزيران (يونيو) 2025	50	0

المخطط الزمني لإيقاف أهم 50 موقعًا إلكترونيًا

بعد الانتهاء من طرح الميزة في أهم 50 موقعًا إلكترونيًا، سنوقف الطرح مؤقتًا ونسمح بتطبيقه على نطاق واسع لمدة إنجاز إنجاز واحد أو إثنين، ثم نحصل على موافقة أخرى لطرح الميزة على جميع المواقع الإلكترونية خلال 8 إنجازات تالية (أو 32 أسبوعًا تقريبًا)، على النحو التالي:

Milestone	تاريخ الإنجاز	أهم 50 موقعًا إلكترونيًا	النسبة المئوية للزيارات الواردة من مصادر أخرى
140	27 آب (أغسطس) 2025	50	1
141	24 أيلول (سبتمبر) 2025	50	5
142	22 تشرين الأول (أكتوبر) 2025	50	10
143	19 تشرين الثاني (نوفمبر) 2025	50	20
144	17 كانون الثاني (يناير) 2026	50	40
145	4 شباط (فبراير) 2026	50	60
146	4 آذار (مارس) 2026	50	80
147	1 نيسان (أبريل) 2026	50	100

المخطط الزمني لإيقاف ميزة "جميع المواقع الإلكترونية" نهائيًا

يُرجى العلم أنّنا نقدّم أيضًا قائمة بخيارات إيقاف في حال عدم توفير مخطط الإيقاف النهائي هذا الوقت الكافي لنقل البيانات بعيدًا عن unload. هدفنا هو استخدام الإيقاف النهائي المؤقت هذا لتحديد المخطط الزمني للمرحلة الأخيرة (الإيقاف النهائي النهائي لميزة unload) التي ستتم فيها إزالة عمليات الإيقاف هذه أو تقليلها.

المخطط الزمني لإيقاف unload نهائيًا

الخلفية

تم تصميم unload لإطلاقه عند تفريغ المستند. من الناحية النظرية، يمكن استخدامه لتشغيل رمز في أي وقت ينتقل فيه المستخدِم بعيدًا عن صفحة، أو كإجراء استدعاء في نهاية الجلسة.

تشمل السيناريوهات التي تم استخدام هذا الحدث فيها بشكل شائع ما يلي:

• حفظ بيانات المستخدمين: عليك حفظ البيانات قبل مغادرة الصفحة.
• تنفيذ مهام التنظيف: إغلاق الموارد المفتوحة قبل مغادرة الصفحة
• إرسال الإحصاءات: إرسال البيانات ذات الصلة بتفاعلات المستخدِمين في نهاية الجلسة

ومع ذلك، فإنّ حدث unload غير موثوق به على الإطلاق.

في متصفِّحَي Chrome وFirefox على أجهزة الكمبيوتر المكتبي، يكون unload موثوقًا به بشكل معقول، ولكنه يؤثر سلبًا في أداء الموقع الإلكتروني من خلال منع استخدام bfcache (التخزين المؤقت للرجوع/الانتقال إلى الأمام).

في المتصفحات المتوافقة مع الأجهزة الجوّالة، لا يتم تشغيل unload غالبًا لأنّ علامات التبويب يتم نقلها غالبًا إلى الخلفية ثم إغلاقها. لهذا السبب، تختار المتصفّحات منح الأولوية لذاكرة التخزين المؤقت bfcache على الأجهزة الجوّالة على unload، ما يجعلها غير موثوقة بشكل أكبر. يستخدم Safari هذا السلوك أيضًا على أجهزة الكمبيوتر المكتبي.

يعتقد فريق Chrome أنّ استخدام نموذج الأجهزة الجوّالة الذي يمنح الأولوية لذاكرة التخزين المؤقت bfcache على unload على أجهزة الكمبيوتر المكتبي قد يؤدي إلى حدوث مشاكل من خلال جعله غير موثوق به على هذا الجهاز أيضًا، علمًا بأنّه كان موثوقًا بشكل معقول في Chrome (وFirefox) في السابق. بدلاً من ذلك، يهدف Chrome إلى إزالة الحدث unload بالكامل. وحتى ذلك الحين، سيظلّ هذا الإصدار موثوقًا به على أجهزة الكمبيوتر المكتبي للمستخدمين الذين أوقفوا نهائيًا استخدام الإصدار القديم بشكل صريح.

ما هو سبب إيقاف الحدث unload نهائيًا؟

إنّ إيقاف unload نهائيًا هو خطوة رئيسية في إطار اعتراف أكبر بكثير بشبكة الإنترنت التي نعيش فيها الآن. يمنح الحدث unload شعورًا زائفًا بالتحكّم في دورة حياة التطبيق، وهو شعور غير صحيح بشكل متزايد في ما يتعلّق بطريقة تصفّحنا الويب في عالم الحوسبة الحديثة.

غالبًا ما تجمِّد أنظمة التشغيل للأجهزة الجوّالة صفحات الويب أو تُزيلها من الذاكرة للحفاظ عليها، وأصبح متصفّحات أجهزة الكمبيوتر المكتبي تفعل ذلك بشكل متزايد الآن أيضًا للأسباب نفسها. حتى بدون تدخلات نظام التشغيل، غالبًا ما يبدّل المستخدمون علامات التبويب ويغلقونها بدون "مغادرة الصفحات" رسميًا.

إنّ إزالة الحدث unload باعتباره قديمًا يُعدّ اعترافًا بأنّنا كمطوّري ويب نحتاج إلى التأكّد من أنّ منهجنا يتطابق مع منهج العالم الواقعي وعدم الاعتماد على المفاهيم القديمة التي لم تعُد صالحة، إن كانت صالحة من قبل.

بدائل لأحداث unload

بدلاً من unload، يُنصح باستخدام:

• ‫visibilitychange: لتحديد وقت تغيير مستوى رؤية الصفحة يحدث هذا الحدث عندما يبدّل المستخدِم علامات التبويب أو يُصغّر نافذة المتصفّح أو يفتح صفحة جديدة. يمكنك اعتبار حالة hidden آخر وقت موثوق به لحفظ بيانات التطبيق والمستخدمين.
• ‫pagehide: لتحديد وقت خروج المستخدِم من الصفحة يحدث هذا الحدث عندما ينتقل المستخدِم بعيدًا عن الصفحة أو يُعيد تحميلها أو يغلِق نافذة المتصفّح. لا يتم تنشيط الحدث pagehide عند تصغير الصفحة أو التبديل إلى علامة تبويب أخرى. تجدر الإشارة إلى أنّه بما أنّ pagehide لا يجعل الصفحة غير مؤهَّلة للاستفادة من ميزة "التخزين المؤقت للصفحات"، من الممكن استعادة الصفحة بعد بدء هذا الحدث. إذا كنت بصدد تنظيف أي موارد في هذا الحدث، قد يكون عليك استعادتها عند استعادة الصفحة.

يختلف حدث beforeunload قليلاً عن حدث unload من حيث حالة الاستخدام، لأنّه حدث قابل للإلغاء. ويتم استخدامه غالبًا لتحذير المستخدمين من التغييرات غير المحفوظة عند الانتقال إلى صفحة أخرى. ولا يمكن الاعتماد على هذا الحدث أيضًا لأنّه لن يتم تشغيله في حال إغلاق علامة تبويب في الخلفية. ننصحك بالحد من استخدام beforeunload ووإضافته بشكل مشروط فقط. بدلاً من ذلك، استخدِم الأحداث المذكورة سابقًا لمعظم عمليات استبدال unload.

لمزيد من التفاصيل، اطّلِع على هذه النصيحة بشأن عدم استخدام معالِج unload مطلقًا.

رصد استخدام unload

تتوفّر أدوات مختلفة لمساعدتك في العثور على مواضع ظهور الحدث unload على الصفحات. يتيح ذلك للمواقع الإلكترونية معرفة ما إذا كانت تستخدم هذا الحدث، سواء في رمزها البرمجي أو باستخدام المكتبات، وبالتالي قد تتأثر بإيقاف هذا الحدث نهائيًا في المستقبل.

أدوات مطوري البرامج في Chrome

تتضمّن أدوات مطوّري البرامج في Chrome تدقيق back-forward-cache لمساعدتك في تحديد المشاكل التي قد تمنع صفحتك من أن تكون مؤهّلة للاستفادة من ميزة "التخزين المؤقت للصفحات" للرجوع أو التقديم، بما في ذلك استخدام معالِج unload.

لاختبار ميزة "التخزين المؤقت للصفحات"، اتّبِع الخطوات التالية:

1. في صفحتك، افتح "أدوات المطوّر"، ثم انتقِل إلى التطبيق > الخدمات التي تعمل في الخلفية > ذاكرة التخزين المؤقت للرجوع/التقديم.

2. انقر على اختبار ميزة "التخزين المؤقت للصفحات" للانتقال إلى الصفحة السابقة/التالية، وسينقلك Chrome تلقائيًا إلى chrome://terms/ ثم إلى صفحتك. بدلاً من ذلك، يمكنك النقر على زرَّي الرجوع والمتابعة في المتصفح.

إذا لم تكن صفحتك مؤهّلة لتخزين الصفحات للرجوع أو التقديم، ستعرض لك علامة التبويب التخزين المؤقت للصفحات للرجوع أو التقديم قائمة بالمشاكل. ضمن إتاحة اتّخاذ إجراء، يمكنك معرفة ما إذا كنت تستخدم unload:

أداة اختبار ذاكرة التخزين المؤقت للرجوع/التقديم في "أدوات مطوّري البرامج في Chrome"

Reporting API

يمكن استخدام Reporting API مع سياسة أذونات للقراءة فقط لرصد استخدام unload من مستخدمي موقعك الإلكتروني.

لمزيد من التفاصيل، يُرجى الاطّلاع على استخدام Reporting API للعثور على عمليات التفريغ.

واجهة برمجة تطبيقات Bfcache notRestoredReasons

تُبلغ سمة 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 لاختبار كيفية عمل موقعك الإلكتروني بدونها حتى تتمكّن من الاستعداد لإيقاف هذه المعالجات نهائيًا. هناك أنواع مختلفة من السياسات:

• سياسة الأذونات: هذه واجهة برمجة تطبيقات لمنصة تتيح لمالكي المواقع الإلكترونية التحكّم في الوصول إلى الميزات، على مستوى الموقع الإلكتروني أو صفحة فردية، باستخدام رؤوس HTTP.
• سياسات المؤسسات: أدوات لمشرفي تكنولوجيا المعلومات لضبط Chrome لمؤسستهم أو نشاطهم التجاري. ويمكن ضبطها باستخدام لوحة مشرف، مثل وحدة تحكّم المشرف في Google.
• إشعارات Chrome: يتيح هذا الإعداد للمطوّر الفردي تغيير إعداد إيقاف unload نهائيًا لاختبار تأثير ذلك على مواقع إلكترونية مختلفة.

سياسة الأذونات

تمّت إضافة سياسة أذونات في الإصدار 115 من Chrome للسماح للمواقع الإلكترونية بإيقاف استخدام معالِجات unload والاستفادة على الفور من bfcache لتحسين أداء الموقع الإلكتروني. اطّلِع على هذه الأمثلة على كيفية ضبط هذه الإعدادات لموقعك الإلكتروني. يتيح ذلك للمواقع الإلكترونية الاستعداد لإيقاف unload نهائيًا.

سيتم تمديد هذا الإجراء في الإصدار 117 من Chrome للسماح للمواقع الإلكترونية بتنفيذ الإجراء عكسيًا، والموافقة على مواصلة محاولة تشغيل معالِجات unload، لأنّ Chrome سيغيّر الإعداد التلقائي لعدم تشغيلها في المستقبل. اطّلِع على هذه الأمثلة حول كيفية مواصلة السماح لمعالجات التفريغ بتنفيذ إجراءاتها في موقعك الإلكتروني. لن تبقى هذه الموافقة سارية إلى الأبد، ويجب استخدامها لإتاحة الوقت للمواقع الإلكترونية لنقل بياناتها بعيدًا عن معالِجات unload.

سياسة المؤسسة

يمكن للمؤسسات التي لديها برامج تعتمد على حدث unload لكي تعمل بشكل صحيح استخدام سياسة ForcePermissionPolicyUnloadDefaultEnabled لمنع الإيقاف النهائي التدريجي للأجهزة الخاضعة لسيطرتها. من خلال تفعيل هذه السياسة، سيظلّ الخيار unload مفعّلاً تلقائيًا لجميع مصادر البيانات. ويمكن للصفحة وضع سياسة أكثر صرامة إذا أرادت. مثل ميزة إيقاف سياسة الأذونات، هذه أداة للتخفيف من التغييرات المفاجئة المحتملة، ولكن لا يجب استخدامها إلى أجل غير مسمى.

علامات Chrome ومفاتيح سطر الأوامر

بالإضافة إلى سياسة المؤسسة، يمكنك إيقاف الإيقاف النهائي للمستخدمين الفرديين باستخدام خيارات Chrome وعناصر التحكّم في سطر الأوامر:

سيؤدي ضبط chrome://flags/#deprecate-unload هذا الإعداد على enabled إلى تقديم الإصدار التلقائي للإيقاف النهائي ومنع معالجات unload من الإطلاق. وسيظل بإمكانك إلغاء هذه الإعدادات على مستوى كل موقع إلكتروني باستخدام "سياسة الأذونات"، ولكن سيستمر تشغيلها تلقائيًا.

يمكن أيضًا التحكّم في هذه الإعدادات باستخدام مفاتيح سطر الأوامر.

مقارنة الخيارات

يلخّص الجدول التالي الاستخدامات المختلفة للخيارات التي سبق أن ناقشناها:

	تقديم تاريخ الإيقاف النهائي	تقديم تاريخ الإيقاف النهائي (مع الاستثناءات)	منع إيقاف الميزة نهائيًا لتوفير الوقت لنقل البيانات
سياسة الأذونات (تنطبق على الصفحات أو المواقع الإلكترونية)	نعم	نعم	نعم
سياسة المؤسسة (تنطبق على الأجهزة)	لا	لا	نعم
ميزات Chrome التجريبية (تنطبق على المستخدمين الفرديين)	نعم	لا	لا
مفاتيح تبديل سطر أوامر Chrome (تنطبق على المستخدمين الفرديين)	نعم	لا	نعم

الخاتمة

يتم إيقاف معالِجات unload نهائيًا. لم تكن هذه الإجراءات موثوقة منذ فترة طويلة ولا يمكن ضمان تنفيذها في جميع الحالات التي يتم فيها إتلاف مستند. بالإضافة إلى ذلك، لا تتوافق معالِجات unload مع bfcache.

على المواقع الإلكترونية التي تستخدِم معالِجات unload الاستعداد لهذا الإيقاف النهائي من خلال اختبار أيّ معالِجات unload حالية وإزالتها أو نقلها أو تأخير الإيقاف النهائي كحلّ أخير إذا لزم الأمر.

الشكر والتقدير

نشكر "كينجي باهوكس" و"فيرغال دالي" و"أدريانا جارا" و"جيريمي واغنر" على مساعدتهم في مراجعة هذه المقالة.

الصورة الرئيسية تقدّمها Anja Bauermann على Unsplash