الخلاصة

  • وصفت أول مسودة علنية لـ Beacon نشرها W3C في أكتوبر 2013 وسائل كانت تؤخر مغادرة الصفحة: طلب XMLHttpRequest متزامن، وتحميل صورة، وحلقة انتظار بلا عمل مفيد.
  • شرحت مسودة التوصية المرشحة في أغسطس 2022 طريقة navigator.sendBeacon() لإيداع تقرير صغير أحادي الاتجاه لدى المتصفح، فيرتب إرساله بينما يمضي القارئ.

أنت عند باب المقهى، والمعطف على كتفك. يلحق بك موظف ويقول: «لحظة، عليّ إبلاغ الإدارة بأنك غادرت». الرسالة قصيرة؛ الانتظار أطول منها. هذا تقريبًا ما فعلته صفحات حين جعلت انتقال القارئ مشروطًا بإرسال آخر سطر من بيانات القياس. الصفحة التالية بدت بطيئة لأن الصفحة السابقة لم تنته من دفاترها.

أول مسودة عمل علنية نشرتها W3C في 29 أكتوبر 2013 سردت المشكلة بوضوح. أرادت شيفرة التحليل والتشخيص إرسال بيانات عند تفريغ المستند. قد تُلغى الطلبات غير المتزامنة عند زوال الصفحة؛ لذلك لجأ مطورون إلى XMLHttpRequest متزامن، أو تحميل صورة، أو تشغيل حلقة تستهلك الوقت فقط. هذه الأساليب رفعت فرص إرسال السجل عبر تأخير ما أراده الزائر أصلًا: الرحيل.

اقترحت المسودة تسليم الرسالة إلى وكيل المستخدم ليتحمل مسؤولية نقلها. حملت الطريقة المبكرة اسم beacon وبنية مختلفة عن navigator.sendBeacon() اللاحقة. قراءة الوثائق بتواريخها مهمة هنا. ما استمر من 2013 ليس شكل كل وسيط برمجي؛ إنه فكرة أن المتصفح يستطيع أخذ الظرف من يد صفحة توشك أن تختفي.

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

في مسودة التوصية المرشحة الصادرة عن W3C في 3 أغسطس 2022، تستقبل navigator.sendBeacon(url, data) بيانات صغيرة لاتصال أحادي الاتجاه. الطلب غير متزامن ولا يعطل الأعمال المستعجلة. يستطيع المتصفح ترتيب الأولويات وتجميع بعض الطلبات وتحسين استهلاك الشبكة والطاقة. ساعي البريد يأخذ الرسالة؛ لا يطلب من صاحبها الوقوف معه حتى يصل إلى مبنى آخر.

يستخدم مثال 2022 حدث visibilitychange حين تصبح الصفحة مخفية. في الهاتف قد ينتقل التطبيق إلى الخلفية، ثم ينهي النظام عمليته من غير أن يطلق unload بالطريقة التي ينتظرها الموقع. لحظة الاختفاء أكثر نفعًا من انتظار حفل وداع قد لا يحدث. تحدد حالة الظهور وقت تسليم الظرف، وتتولى Beacon مسار نقله.

القيمة true التي تعيدها sendBeacon() تعني أن المتصفح قبل وضع البيانات في قائمة الإرسال. إثبات الوصول يُبحث عنه في سجل الخادم. لا تقدم الواجهة ردًا تعالجه الصفحة. حين يقول حامل الحقيبة إنه أخذ الرسالة، نعرف مكان الظرف الآن؛ ختم المستلم شأن آخر. الخلط بينهما ينتج تقارير نجاح سريعة أكثر مما تنتج رسائل مستلمة.

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

يسجل تاريخ نشر W3C للمواصفة مسودة 2013 الأولى، ونسخة مرشحة في 2017، ومسودة مرشحة أحدث في 2022. هذه محطات نشر الوثائق. بقي السؤال الذي جمعها ملموسًا: الصفحة تريد ترك آخر سجل، فمن يحمل الرسالة من دون أن يمسك بالزائر عند الباب؟

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