تقليل عمليات التنقل المتأخرة
من الشائع أن تحتوي الصفحة أو التطبيق على إحصاءات أو بيانات أخرى لم يتم إرسالها في
وقت إغلاق المستخدم لها. لمنع فقدان البيانات، تستخدم بعض المواقع الإلكترونية طلبًا متزامنًا
إلى XMLHttpRequest()
لإبقاء الصفحة أو التطبيق مفتوحَين إلى أن يتم تمرير بياناتهما إلى
الخادم. بالإضافة إلى أنّ هناك طرقًا أفضل لحفظ البيانات، فإنّ هذه الطريقة تؤدي إلى
تجربة سيئة للمستخدمين من خلال تأخير إغلاق الصفحة لمدة تصل إلى عدة ثوانٍ.
يجب تغيير هذه الممارسة، وبدأت المتصفّحات في الاستجابة. سبق أن تم تحديد موعد إيقاف مواصفات XMLHttpRequest()
وإزالتها. يتّخذ Chrome 80 الخطوة الأولى
من خلال حظر المكالمات المتزامنة داخل العديد من معالجات الأحداث،
وعلى وجه التحديد beforeunload
وunload
وpagehide
وvisibilitychange
عند
إطلاقها في عملية الإغلاق. أصدرت WebKit أيضًا تحديثًا لتنفيذ
تغيير السلوك نفسه.
في هذه المقالة، سأوضّح بشكل مختصر الخيارات المتاحة لأولئك الذين يحتاجون إلى بعض الوقت لتعديل
مواقعهم الإلكترونية، كما سأوضّح البدائل المتاحة لXMLHttpRequest()
.
عمليات الإيقاف المؤقتة
لا يريد Chrome إيقاف XMLHttpRequest()
نهائيًا، لذلك تتوفّر بعض خيارات التوقف المؤقت عن استخدام الميزة. بالنسبة إلى المواقع الإلكترونية على الإنترنت، تتوفّر ميزة "إصدار بدء" في مرحلة اختبار قيد التطوير.
وبهذا الإجراء، تتم إضافة رمز مميّز خاص بالمصدر إلى رؤوس صفحاتك يتيح XMLHttpRequest()
طلبات XMLHttpRequest()
غير المتزامنة. سيتم إيقاف هذا الخيار نهائيًا قبل وقت قصير من طرح الإصدار Chrome 89 في وقت ما من آذار (مارس) 2021. يمكن لعملاء Chrome Enterprise أيضًا
استخدام علامة السياسة AllowSyncXHRInPageDismissal
التي تنتهي في الوقت نفسه.
الحلول البديلة
بغض النظر عن كيفية إعادة إرسال البيانات إلى الخادم، يُفضَّل تجنب الانتظار حتى يتم إلغاء تحميل الصفحة لإرسال جميع البيانات مرة واحدة. بالإضافة إلى توفير تجربة استخدام رديئة، لا يمكن الاعتماد على أسلوب unload في المتصفّحات الحديثة، كما أنّه يعرّض البيانات للفقدان في حال حدوث خطأ. وعلى وجه التحديد، لا يتم تنشيط أحداث إلغاء التحميل في المتصفّحات المتوافقة مع الأجهزة الجوّالة
غالبًا لأنّ هناك طرقًا متعدّدة لإغلاق علامة تبويب أو متصفّح على أنظمة التشغيل المتوافقة مع الأجهزة الجوّالة بدون تنشيط الحدث unload
.
في XMLHttpRequest()
، كان استخدام حمولات صغيرة أمرًا اختياريًا. الآن هو
شرط. يُرجى العِلم أنّ الحد الأقصى لتحميل كلا الخيارَين هو 64 كيلوبايت لكل
سياق، كما هو مطلوب في المواصفات.
رسالة التحقّق من الاتصال
توفّر Fetch API
وسيلة فعّالة للتعامل مع تفاعلات الخادم وواجهة
متسقة لاستخدامها في مختلف
واجهات برمجة تطبيقات المنصات. ومن بين خياراته keepalive
التي تضمن استمرار الطلب
سواء بقيت الصفحة التي جعلتها مفتوحة أم لا:
window.addEventListener('unload', {
fetch('/siteAnalytics', {
method: 'POST',
body: getStatistics(),
keepalive: true
});
}
تتميز طريقة fetch()
بميزة التحكّم بشكل أكبر في ما يتم إرساله إلى
الخادم. ما لا أعرضه في المثال هو أنّ fetch()
يعرض أيضًا
وعدًا يتم حلّه باستخدام عنصر Response
. بما أنّني أحاول الابتعاد عن
مسار تفريغ الصفحة، اخترت عدم اتّخاذ أي إجراء بشأنها.
SendBeacon()
يستخدم SendBeacon()
واجهة برمجة التطبيقات Fetch API في الواقع، لذلك يفرض الحد الأقصى نفسه لحمولة البيانات وهو 64 كيلوبايت، ويضمن أيضًا مواصلة الطلب
بعد إزالة الصفحة من الذاكرة. ميزتها الأساسية هي بساطتها. يتيح لك
إرسال بياناتك باستخدام سطر واحد من التعليمات البرمجية:
window.addEventListener('unload', {
navigator.sendBeacon('/siteAnalytics', getStatistics());
}
الخاتمة
مع زيادة توفّر
fetch()
على مستوى المتصفحات، نأمل أن تتم إزالة XMLHttpRequest()
من منصة الويب في مرحلة ما. يوافق مورّدو المتصفّحات على ضرورة إزالتها، ولكن قد تحتاج العملية إلى
بعض الوقت. إنّ إيقاف أحد حالات الاستخدام الأكثر سوءًا هو خطوة أولى لتحسين
تجربة المستخدمين.
صورة من تصوير "ماثيو هاميلتون" على قناة Un التصميم