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

Demián Renzulli

Barry Pollard

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

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

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

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

بعد هذه المراحل من التواصل والتجربة، إليك الطريقة التي نتوقّع بها طرح إيقاف الميزة نهائيًا بشكل تدريجي:

• مرحلة على مستوى النطاق سيتم فيها إيقاف ميزة unload تدريجيًا في أهم 50 موقعًا إلكترونيًا رائجًا (مرجع اعتبارًا من وقت كتابة هذه المقالة).
  • بدءًا من% 1 من المستخدمين الذين يستخدمون الإصدار 120 من Chrome (نهاية تشرين الثاني/نوفمبر 2023).
  • الإيقاف النهائي لجميع المستخدمين بحلول نهاية الربع الثالث من عام 2024
• بالإضافة إلى ذلك، اعتبارًا من الربع الثالث من عام 2024، ننوي بدء مرحلة عامة يتم فيها إيقاف ميزة unload تدريجيًا على أي مواقع إلكترونية، بدءًا من% 1 من المستخدمين وانتهاءً بـ% 100 من المستخدمين بحلول نهاية الربع الأول من عام 2025.

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

Reporting API

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

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

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

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

• سياسة الأذونات: هذه واجهة برمجة تطبيقات لمنصّة تتيح لمالكي المواقع الإلكترونية التحكّم في الوصول إلى الميزات، على مستوى الموقع الإلكتروني أو صفحة فردية، من خلال استخدام رؤوس 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 من الإطلاق. وسيظل بإمكانك إلغاء هذه الإعدادات على أساس كل موقع إلكتروني على حدة من خلال "سياسة الأذونات"، ولكن سيستمر تشغيلها تلقائيًا.

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

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

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

الخاتمة

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

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

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

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

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