أصبح نطاق إمكانات الأجهزة التي يمكنها الاتصال بالويب أوسع من أي وقت مضى. قد يتم أيضًا استخدام تطبيق الويب نفسه الذي يتم عرضه على أجهزة الكمبيوتر المكتبية المتطورة على هاتف أو ساعة أو جهاز لوحي منخفض الطاقة، وقد يكون إنشاء تجارب مقنعة تعمل بسلاسة على أي جهاز، أمرًا صعبًا للغاية.
Device Memory API هي ميزة جديدة على مستوى النظام الأساسي للويب تهدف إلى مساعدة مطوّري البرامج على الويب في التعامل مع الوضع الأفقي للأجهزة الحديثة. تضيف سمة للقراءة فقط إلى الكائن navigator،
navigator.deviceMemory، التي تعرض مقدار ذاكرة الوصول العشوائي في الجهاز بالغيغابايت، ويتم تقريبها إلى أقرب طاقة تبلغ اثنين. تعرض واجهة برمجة التطبيقات أيضًا
Client Hints Header (عنوان تلميحات العميل)
Device-Memory الذي يعرض القيمة نفسها.
تتيح واجهة برمجة التطبيقات Device Memory API للمطوّرين تنفيذ أمرين أساسيين:
- يجب اتخاذ قرارات في وقت التشغيل بشأن الموارد المطلوب عرضها استنادًا إلى قيمة ذاكرة الجهاز المعروضة (مثل عرض إصدار "بسيط" من التطبيق لمستخدمي الأجهزة ذات الذاكرة المنخفضة).
- يمكنك الإبلاغ عن هذه القيمة لإحدى خدمات الإحصاءات حتى تتمكن من فهم كيفية ارتباط ذاكرة الجهاز بسلوك المستخدم أو الإحالات الناجحة أو غير ذلك من المقاييس المهمة لنشاطك التجاري بشكل أفضل.
تخصيص المحتوى ديناميكيًا استنادًا إلى ذاكرة الجهاز
إذا كنت تشغّل خادم الويب الخاص بك ويمكنك تعديل المنطق الذي
يخدم الموارد، يمكنك الاستجابة بشكل مشروط للطلبات التي تحتوي على
Device-Memory Client Hints Header.
GET /main.js HTTP/1.1
Host: www.example.com
Device-Memory: 0.5
Accept: */*
باستخدام هذه التقنية، يمكنك إنشاء نسخة واحدة أو أكثر من النصوص البرمجية للتطبيق والردّ على الطلبات الواردة من العميل بشروط استنادًا إلى القيمة التي تم ضبطها في العنوان Device-Memory. لا تحتاج هذه الإصدارات إلى أن تحتوي على
تعليمات برمجية مختلفة تمامًا (لأنه يصعب صيانتها). وفي أغلب الأحيان، لن يستبعد الإصدار "البسيط" سوى الميزات التي قد تكون باهظة الثمن وليست أساسية
لتجربة المستخدم.
استخدام عنوان تلميحات العميل
لتفعيل عنوان Device-Memory، أضِف علامة <meta> الخاصة بتلميحات العميل إلى <head> من المستند:
<meta http-equiv="Accept-CH" content="Device-Memory">
أو يمكنك تضمين "ذاكرة الجهاز" في عناوين استجابة Accept-CH للخادم:
HTTP/1.1 200 OK
Date: Thu Dec 07 2017 11:44:31 GMT
Content-Type: text/html
Accept-CH: Device-Memory, Downlink, Viewport-Width
يؤدي ذلك إلى إعلام المتصفّح بإرسال العنوان Device-Memory مع جميع طلبات الموارد الفرعية للصفحة الحالية.
بتعبير آخر، بعد تنفيذ أحد الخيارات أعلاه لموقعك الإلكتروني، إذا زار أحد المستخدمين جهازًا يتضمّن ذاكرة وصول عشوائي (RAM) بسعة 0.5 غيغابايت، ستتضمّن جميع طلبات الصور وCSS وJavaScript من هذه الصفحة عنوان Device-Memory مع ضبط القيمة على "0.5"، وسيتمكّن الخادم من الاستجابة لهذه الطلبات كيفما تراه مناسبًا.
على سبيل المثال، يعرض مسار Express التالي
إصدارًا "بسيطًا" من نص برمجي في حال ضبط العنوان Device-Memory وقيمته أقل من 1، أو عرض إصدار "كامل" إذا كان المتصفّح لا يتيح عمل العنوان Device-Memory أو إذا كانت القيمة 1 أو أكبر:
app.get('/static/js/:scriptId', (req, res) => {
// Low-memory devices should load the "lite" version of the component.
// The logic below will set `scriptVersion` to "lite" if (and only if)
// `Device-Memory` isn't undefined and returns a number less than 1.
const scriptVersion = req.get('Device-Memory') < 1 ? 'lite' : 'full';
// Respond with the file based on `scriptVersion` above.
res.sendFile(`./path/to/${req.params.scriptId}.${scriptVersion}.js`);
});
استخدام واجهة برمجة تطبيقات JavaScript
في بعض الحالات (مثل خادم ملفات ثابت أو شبكة توصيل للمحتوى)، لن تتمكن من الاستجابة بشكل مشروط للطلبات بناءً على عنوان HTTP. وفي هذه الحالات، يمكنك استخدام واجهة برمجة تطبيقات JavaScript لإنشاء طلبات شرطية في رمز JavaScript.
يتشابه المنطق التالي مع مسار Express أعلاه، باستثناء أنه يحدّد ديناميكيًا عنوان URL للنص البرمجي في منطق جانب العميل:
// Low-memory devices should load the "lite" version of the component.
// The logic below will set `componentVersion` to "lite" if (and only if)
// deviceMemory isn't undefined and returns a number less than 1.
const componentVersion = navigator.deviceMemory < 1 ? 'lite' : 'full';
const component = await import(`path/to/component.${componentVersion}.js`);
component.init();
وعلى الرغم من أنّ العرض لإصدارات مختلفة من المكوِّن نفسه بشكل مشروط استنادًا إلى إمكانات الجهاز يُعدّ استراتيجية جيدة، قد يكون من الأفضل أحيانًا عدم عرض مكوّن على الإطلاق.
في كثير من الحالات، تكون المكونات تحسينات بحتة. إنها تضيف بعض اللمسات اللطيفة إلى التجربة، لكنها ليست مطلوبة للوظيفة الأساسية للتطبيق. في هذه الحالات، قد يكون من الحكمة عدم تحميل هذه المكوّنات في المقام الأول. إذا كان أحد المكونات التي تهدف إلى تحسين تجربة المستخدم يجعل التطبيق بطيئًا أو غير مستجيب، فإنه لا يحقق هدفه.
أي قرار تتخذه يؤثر في تجربة المستخدم، فمن الضروري قياس تأثيره. من الأهمية بمكان أيضًا أن يكون لديك صورة واضحة حول مستوى أداء تطبيقك اليوم.
إنّ فهم كيفية ارتباط ذاكرة الجهاز بسلوك المستخدم في الإصدار الحالي من تطبيقك سيحدد بشكل أفضل الإجراء الذي يجب اتخاذه، وسيمنحك أساسًا يمكنك قياس مدى نجاح التغييرات المستقبلية بناءً عليه.
تتبُّع ذاكرة الجهاز باستخدام الإحصاءات
إنّ واجهة برمجة التطبيقات Device Memory API جديدة ولا يتتبّعها معظم مقدّمي الإحصاءات. لحسن الحظ، يمنحك معظم موفري خدمات التحليلات طريقة لتتبع البيانات المخصصة (على سبيل المثال، تشتمل "إحصاءات Google" على ميزة تسمى الأبعاد المخصصة)، التي يمكنك استخدامها لتتبع ذاكرة الجهاز لأجهزة المستخدمين.
استخدام بُعد مخصّص لذاكرة الجهاز
تتألف عملية استخدام المكوّنات المخصّصة في "إحصاءات Google" من خطوتين.
- إعداد السمة المخصّصة في "إحصاءات Google"
- حدِّث رمز التتبّع إلى
set(قيمة ذاكرة الجهاز) للسمة المخصّصة التي أنشأتها للتو.
عند إنشاء السمة المخصّصة، أدخِلها باسم "ذاكرة الجهاز" واختر نطاقًا "للجلسة" لأن القيمة لن تتغير خلال جلسة تصفّح المستخدم:
بعد ذلك، يمكنك تعديل رمز التتبّع. فيما يلي مثال على الشكل الذي قد يبدو عليه. بالنسبة إلى المتصفّحات التي لا تتوافق مع Device Memory API، ستكون قيمة السمة (not set) "(not set).
// Create the tracker from your tracking ID.
// Replace "UA-XXXXX-Y" with your Google Analytics tracking ID.
ga('create', 'UA-XXXXX-Y', 'auto');
// Set the device memory value as a custom dimension on the tracker.
// This will ensure it gets sent with all future data to Google Analytics.
// Note: replace "XX" with the index of the custom dimension you created
// in the Google Analytics admin.
ga('set', 'dimensionXX', navigator.deviceMemory || '(not set)');
// Do any other other custom setup you want...
// Send the initial pageview.
ga('send', 'pageview');
إعداد تقارير عن بيانات ذاكرة الجهاز
بعد وضع سمة ذاكرة الجهاز على set في عنصر التتبُّع، ستتضمّن جميع البيانات التي تُرسلها إلى "إحصاءات Google" هذه القيمة.
وسيتيح لك ذلك تقسيم أي مقياس تريده (مثل أوقات تحميل الصفحة ومعدّل الأهداف المكتملة وغير ذلك) حسب ذاكرة الجهاز لمعرفة ما إذا كانت هناك أي روابط.
نظرًا لأن ذاكرة الجهاز هي بُعد مخصّص وليس بُعدًا مضمَّنًا، لن تراها في أي من التقارير العادية. للوصول إلى هذه البيانات، عليك إنشاء تقرير مخصّص. على سبيل المثال، قد تظهر إعدادات تقرير مخصَّص يقارن بين أوقات التحميل حسب ذاكرة الجهاز على النحو التالي:
وقد يبدو التقرير الذي يُنشئه كما يلي:
بمجرد أن تنتهي من جمع بيانات ذاكرة الجهاز وأن يكون لديك أساس لمعرفة كيفية تجربة المستخدمين لتطبيقك عبر جميع نطاقات نطاق الذاكرة، يمكنك تجربة تقديم موارد مختلفة للمستخدمين المختلفين (باستخدام الأساليب الموضحة في القسم أعلاه). بعد ذلك، ستتمكن من إلقاء نظرة على النتائج ومعرفة ما إذا كان قد تحسنت.
ملخص
توضح هذه المشاركة كيفية استخدام واجهة برمجة التطبيقات Device Memory API لتخصيص تطبيقك وفق إمكانات أجهزة المستخدمين، وكيفية قياس انطباع هؤلاء المستخدمين عن تطبيقك.
على الرغم من أنّ هذه المشاركة تركّز على واجهة برمجة التطبيقات Device Memory API، يمكن تطبيق معظم الأساليب الموضّحة هنا على أي واجهة برمجة تطبيقات تنشئ تقارير عن إمكانات الجهاز أو حالات الشبكة.
مع استمرار اتساع مجال الأجهزة، أصبح من المهم أكثر من أي وقت مضى أن يأخذ مطوِّرو البرامج على الويب في الاعتبار طيف المستخدمين الكامل عند اتخاذ القرارات التي تؤثر في تجربتهم.