نشاط التسجيل باستخدام واجهة برمجة تطبيقات Web Beacon

تعد Beacon API واجهة برمجة تطبيقات ويب تستند إلى JavaScript لإرسال كميات صغيرة من البيانات من المتصفح إلى خادم الويب دون انتظار استجابة. في هذه المقالة ، سنلقي نظرة على ما يمكن أن يكون مفيدًا ، وما الذي يجعله مختلفًا عن التقنيات المألوفة مثل XMLHTTPRequest ("Ajax") ، وكيف يمكنك البدء في استخدامه.

إذا كنت تعرف سبب رغبتك في استخدام منارة بالفعل ، فلا تتردد في الانتقال مباشرةً إلى قسم "البدء".

ما هي منارة API؟

تُستخدم منارة API لإرسال كميات صغيرة من البيانات إلى الخادم دون انتظار استجابة . يعتبر هذا الجزء الأخير بالغ الأهمية وهو المفتاح الذي يجعل منارة مفيدة للغاية - لا يمكن للرمز الخاص بنا رؤية أي استجابة أبدًا ، حتى لو أرسل الخادم ردًا. تُستخدم الإشارات التنبيهية على وجه التحديد لإرسال البيانات ثم نسيانها. لا نتوقع ردًا ولا نحصل على رد.

فكر في الأمر مثل بطاقة بريدية يتم إرسالها إلى المنزل عندما تكون في إجازة. تضع كمية صغيرة من البيانات عليها (قليلًا من "أتمنى لو كنت هنا" و "كان الطقس جميلًا") ، تضعها في صندوق البريد ، ولا تتوقع ردًا. لا أحد يرسل بطاقة بريدية معادة تقول "نعم ، أتمنى لو كنت هناك بالفعل ، شكرًا جزيلاً لك!"

بالنسبة لمواقع الويب والتطبيقات الحديثة ، هناك عدد من حالات الاستخدام التي تقع بدقة شديدة في هذا النمط من الإرسال والنسيان.

إحصائيات التتبع وبيانات التحليلات

حالة الاستخدام الأولى التي تتبادر إلى الذهن بالنسبة لمعظم الناس هي التحليلات. قد تقدم الحلول الكبيرة مثل Google Analytics نظرة عامة جيدة على أشياء مثل زيارات الصفحة ، ولكن ماذا لو أردنا شيئًا أكثر تخصيصًا؟ يمكننا كتابة بعض JavaScript لتتبع ما يحدث في الصفحة (ربما كيف يتفاعل المستخدم مع أحد المكونات ، أو إلى أي مدى انتقلوا إليه ، أو المقالات التي تم عرضها قبل أن يتبعوا CTA) ولكننا نحتاج بعد ذلك إلى إرسال تلك البيانات إلى الخادم عندما يغادر المستخدم الصفحة. منارة مثالية لهذا ، لأننا نسجل البيانات فقط ولا نحتاج إلى رد.

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

التصحيح والتسجيل

تطبيق مفيد آخر لهذا السلوك هو تسجيل المعلومات من كود JavaScript الخاص بك. تخيل أن لديك مكونًا تفاعليًا معقدًا على صفحتك يعمل بشكل مثالي مع جميع اختباراتك ، ولكنه يفشل أحيانًا في الإنتاج. أنت تعلم أنه فشل ، لكن لا يمكنك رؤية الخطأ لبدء تصحيحه. إذا تمكنت من اكتشاف فشل في الشفرة نفسها ، فيمكنك عندئذٍ جمع التشخيصات واستخدام منارة لإرسالها كلها مرة أخرى للتسجيل.

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

لا يمكننا فعل هذا بالفعل؟

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

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

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

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

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

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

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

ابدء

لذلك نحن نفهم ما هو المرشد ، ولماذا قد نستخدمه ، لذلك دعونا نبدأ ببعض التعليمات البرمجية. لا يمكن أن تكون الأساسيات أبسط:

 let result = navigator.sendBeacon(url, data);

والنتيجة منطقية ، true إذا قبل المتصفح الطلب ووضعه في قائمة الانتظار ، false إذا كانت هناك مشكلة في القيام بذلك.

باستخدام navigator.sendBeacon()

navigator.sendBeacon يأخذ معلمتين. الأول هو عنوان URL لتقديم الطلب. يتم تنفيذ الطلب على شكل HTTP POST ، وإرسال أي بيانات مقدمة في المعلمة الثانية.

يمكن أن تكون معلمة البيانات بأحد التنسيقات المتعددة ، وكلها مأخوذة مباشرة من Fetch API. يمكن أن يكون هذا Blob أو BufferSource أو FormData أو URLSearchParams - بشكل أساسي أي من أنواع الجسم المستخدمة عند تقديم طلب باستخدام Fetch.

أحب استخدام FormData للحصول على بيانات قيمة المفتاح الأساسية لأنها غير معقدة وسهلة القراءة.

 // URL to send the data to let url = '/api/my-endpoint'; // Create a new FormData and add a key/value pair let data = new FormData(); data.append('hello', 'world'); let result = navigator.sendBeacon(url, data); if (result) { console.log('Successfully queued!'); } else { console.log('Failure.'); }

دعم المتصفح

الدعم في المتصفحات لـ Beacon جيد جدًا ، مع الاستثناءات الملحوظة الوحيدة هي Internet Explorer (يعمل في Edge) و Opera Mini. بالنسبة لمعظم الاستخدامات ، يجب أن يكون ذلك جيدًا ، لكن الأمر يستحق الاختبار للحصول على الدعم قبل محاولة استخدام navigator.sendBeacon .

من السهل القيام بذلك:

 if (navigator.sendBeacon) { // Beacon code } else { // No Beacon. Maybe fall back to XHR? }

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

مثال: وقت التسجيل على الصفحة

لرؤية هذا في الممارسة العملية ، دعنا ننشئ نظامًا أساسيًا لوقت بقاء المستخدم على الصفحة. عندما يتم تحميل الصفحة ، سنقوم بتدوين الوقت ، وعندما يغادر المستخدم الصفحة ، سنرسل وقت البدء والوقت الحالي إلى الخادم.

نظرًا لأننا نهتم فقط بالوقت المنقضي (وليس الوقت الفعلي من اليوم) ، يمكننا استخدام performance.now() للحصول على طابع زمني أساسي أثناء تحميل الصفحة:

 let startTime = performance.now();

إذا أنهينا تسجيل الدخول إلى دالة ، فيمكننا تسميتها عند تفريغ الصفحة.

 let logVisit = function() { // Test that we have support if (!navigator.sendBeacon) return true; // URL to send the data to, eg let url = '/api/log-visit'; // Data to send let data = new FormData(); data.append('start', startTime); data.append('end', performance.now()); data.append('url', document.URL); // Let's go! navigator.sendBeacon(url, data); };

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

 window.addEventListener('beforeunload', logVisit);

عندما يتم تفريغ الصفحة (أو قبل ذلك مباشرة) ، سيتم استدعاء وظيفة logVisit() بنا وشريطة أن يدعم المتصفح واجهة برمجة تطبيقات Beacon ، سيتم إرسال المرشد الخاص بنا.

(لاحظ أنه في حالة عدم وجود دعم منارة ، فإننا نرجع " true " ونتظاهر بأن كل شيء يعمل بشكل رائع. سيؤدي إرجاع false إلى إلغاء الحدث وإيقاف تفريغ الصفحة. سيكون هذا أمرًا مؤسفًا.)

اعتبارات عند التتبع

نظرًا لأن العديد من الاستخدامات المحتملة لـ Beacon تدور حول تتبع النشاط ، أعتقد أنه سيكون من التقصير عدم ذكر المسؤوليات الاجتماعية والقانونية التي نتحملها كمطورين عند تسجيل وتتبع النشاط الذي يمكن ربطه بالمستخدمين.

اللائحة العامة لحماية البيانات

قد نفكر في قوانين القانون العام لحماية البيانات الأوروبية الأخيرة من حيث صلتها بالبريد الإلكتروني ، ولكن بالطبع ، يتعلق التشريع بتخزين أي نوع من البيانات الشخصية. إذا كنت تعرف من هم المستخدمون لديك ويمكنك تحديد جلساتهم ، فعليك التحقق من النشاط الذي تقوم بتسجيله ومدى ارتباطه بسياساتك المعلنة.

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

DNT: عدم التعقب

بالإضافة إلى المتطلبات القانونية ، تحتوي معظم المتصفحات على إعداد لتمكين المستخدم من التعبير عن رغبته في عدم التعقب. ترسل ميزة "عدم التعقب" رأس HTTP بالطلب الذي يبدو كالتالي:

 DNT: 1

إذا كنت تقوم بتسجيل البيانات التي يمكنها تتبع مستخدم معين ويرسل المستخدم رأس DNT إيجابيًا ، فمن الأفضل اتباع رغبات المستخدم وإخفاء هوية تلك البيانات أو عدم تتبعها على الإطلاق.

في PHP ، على سبيل المثال ، يمكنك بسهولة اختبار هذا العنوان كما يلي:

 if (!empty($_SERVER['HTTP_DNT'])) { // User does not wish to be tracked ... }

ختاما

تعد Beacon API طريقة مفيدة حقًا لإرسال البيانات من صفحة إلى الخادم ، خاصة في سياق التسجيل. دعم المتصفح واسع جدًا ، وهو يمكّنك من تسجيل البيانات بسلاسة دون التأثير سلبًا على تجربة تصفح المستخدم وأداء موقعك. تعني الطبيعة غير المحظورة للطلبات أن الأداء أسرع بكثير من البدائل مثل XHR و Fetch.

إذا كنت ترغب في قراءة المزيد حول Beacon API ، فإن المواقع التالية تستحق البحث.

• "مواصفات W3C Beacon" ، توصية مرشح W3C
• "وثائق MDN Beacon ،" مستندات الويب MDN ، Mozilla
• "معلومات دعم المتصفح" caniuse.com