التكيّف مع المستخدمين من خلال تلميحات العملاء

Downlink: 2.5

يمكن أن يكون مقياس Downlink مفيدًا مع مقياس RTT في تغيير كيفية عرض المحتوى للمستخدمين استنادًا إلى جودة الاتصال بالشبكة.

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

يشير التلميح ECT إلى نوع الاتصال الفعّال. وتكون قيمته واحدة من قائمة محدّدة بأنواع الاتّصالات، يصف كلّ منها اتّصالًا ضمن نطاقات محدّدة لكلّ من قيمRTT وDownlink.

لا يوضّح هذا العنوان نوع الاتصال الحقيقي، مثلاً، لا يُبلِغ عن ما إذا كانت البوابة عبارة عن برج خلوي أو نقطة اتصال Wi-Fi. بدلاً من ذلك، يحلّل وقت استجابة الاتصال الحالي ومعدّل نقل البيانات ويحدد الملف الشخصي للشبكة الذي يشبهه أكثر من غيره. على سبيل المثال، إذا اتصلت بشبكة بطيئة من خلال شبكة Wi-Fi، قد تتم تعبئة ECT بالقيمة 2g، وهي أقرب تقريب للاتصال الفعّال:

ECT: 2g

القيم الصالحة لسمة ECT هي 4g و3g و2g وslow-2g. يمكن استخدام هذه التلميحة كنقطة بداية لتقييم جودة الاتصال، ثم تعديلها بعد ذلك باستخدام التلميحَين RTT وDownlink.

توفير البيانات

لا يُعدّ الخيار Save-Data تلميحًا يصف ظروف الشبكة بقدر ما هو أحد خيارات الإعدادات المفضّلة للمستخدمين التي تشير إلى أنّه يجب أن ترسل الصفحات بيانات أقل.

أفضل تصنيف Save-Data على أنّه تلميح للشبكة لأنّ العديد من الإجراءات التي يمكن تنفيذها به تشبه إجراءات تلميحات الشبكة الأخرى. وقد يميل المستخدمون أيضًا إلى تفعيلها في البيئات التي يكون فيها وقت الاستجابة مرتفعًا أو معدل نقل البيانات منخفضًا. يظهر هذا التلميح دائمًا على النحو التالي:

Save-Data: on

في Google، لقد تحدّثنا عن الإجراءات التي يمكنك اتّخاذها باستخدام Save-Data. وقد يكون تأثير ذلك في الأداء عميقًا. وهذا يعني أنّ المستخدمين يطلبون منك حرفيًا إرسال عدد أقل من الرسائل إليهم. وإذا استمعت إلى هذه الإشارة واتّخذت إجراءً بشأنها، سيقدّر المستخدمون ذلك.

جمع أطر العمل ضمن عملية مترابطة

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

الصور المتجاوبة

يمكن أن تصبح جميع حالات استخدام الصور المتجاوبة مع الأجهزة الجوّالة معقّدة باستثناء أبسطها. ماذا لو كان لديك صور متعددة ونُسخ مختلفة من الصور نفسها لأحجام شاشة مختلفة وتنسيقات مختلفة؟ يصبح هذا الترميز معقدًا بشكل سريع. من السهل ارتكاب الأخطاء، ومن السهل نسيان مفاهيم مهمة أو إساءة فهمها (مثل sizes).

على الرغم من أنّ <picture> وsrcset هما أداتان رائعة بلا شك، يمكن أن يستغرق تطويرهما وصيانتها وقتًا طويلاً في حالات الاستخدام المعقدة. يمكننا إنشاء ترميز بشكلٍ آلي، ولكنّ ذلك يشكّل أيضًا صعوبة لأنّ الوظائف التي يوفّرها <picture> وsrcset معقّدة بما يكفي لكي تتم عملية التشغيل الآلي بطريقة تحافظ على المرونة التي يوفّرها هذان العنصران.

يمكن أن تبسِّط تعديلات العميل ذلك. يمكن أن تبدو عملية التفاوض على الردود على الصور مع العميل باستخدام التلميحات على النحو التالي:

1. اختَر أولاً معالجة الصورة (أي الصور الموجَّهة للفن) من خلال وضع علامة في المربّع بجانب التلميح Viewport-Width، إذا كان ذلك منطبقًا على سير عملك.
2. اختَر درجة دقة الصورة من خلال وضع علامة في مربّع التلميح Width ومربّع التلميح DPR، واختَر مصدرًا يناسب حجم تنسيق الصورة وكثافة الشاشة (على غرار طريقة عمل الأوصاف x وw في srcset).
3. اختَر تنسيق الملف الأمثل الذي يتيح استخدامه المتصفّح (يساعدنا Accept في تنفيذ ذلك في معظم المتصفّحات).

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

<picture>
  <source
    srcset="
      company-photo-256w.webp   256w,
      company-photo-512w.webp   512w,
      company-photo-768w.webp   768w,
      company-photo-1024w.webp 1024w,
      company-photo-1280w.webp 1280w
    "
    type="image/webp"
  />
  <img
    srcset="
      company-photo-256w.jpg   256w,
      company-photo-512w.jpg   512w,
      company-photo-768w.jpg   768w,
      company-photo-1024w.jpg 1024w,
      company-photo-1280w.jpg 1280w
    "
    src="company-photo-256w.jpg"
    sizes="(min-width: 560px) 251px, 88.43vw"
    alt="The Sconnie Timber Staff!"
  />
</picture>

تمكّنت من تقليلها إلى ما يلي استنادًا إلى توافق المتصفّحات الفردية:

<img
  src="/image/sizes:true/company-photo.jpg"
  sizes="(min-width: 560px) 251px, 88.43vw"
  alt="SAY CHEESY PICKLES."
/>

في هذا المثال، عنوان URL /image هو نص برمجي بلغة PHP متبوعًا بالمَعلمات التي تمت إعادة كتابتها باستخدام mod_rewrite. ويأخذ الإجراء اسم ملف الصورة ومَعلمات إضافية لمساعدة نص برمجي في الخلفية على اختيار أفضل صورة في الظروف المحدّدة.

أعتقد أنّ سؤالك الأول هو "أليس هذا مجرد إعادة تنفيذ <picture> وsrcset في الخلفية؟".

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

تتيح لك إشارات العميل البدء باستخدام صورة عالية الدقة بدون فقدان الجودة، ويمكن بعد ذلك تغيير حجمها ديناميكيًا لتكون مثالية لأي تركيبة من الشاشة والتنسيق. على عكس srcset، الذي يتطلّب منك إدراج قائمة ثابتة بالصور المحتملة التي يمكن للمتصفّح الاختيار من بينها، يمكن أن يكون هذا النهج أكثر مرونة. في حين أنّ srcset يفرض عليك تقديم مجموعة تقريبية من الصيغ للمتصفحات، مثل 256w و512w و768w و1024w، يمكن لأي حلّ يستند إلى اقتراحات العميل عرض جميع العروض بدون الحاجة إلى استخدام مجموعة كبيرة من الترميز.

بالطبع، ليس عليك كتابة منطق اختيار الصور بنفسك. تستخدِم Cloudinary إشارات العميل لإنشاء ردود الصور عند استخدام المَعلمة w_auto، وقد لاحظت الشركة أنّ متوسط عدد المستخدمين الذين نزّلوا عددًا أقل من البايت بنسبة% 42 عند استخدام المتصفّحات التي تتيح إشارات العميل.

ولكن احرِص على اتّباع الخطوات التالية: أدّت التغييرات في إصدار Chrome 67 للكمبيوتر المكتبي إلى إيقاف ميزة ملاحظات العميل من مصادر مختلفة. لحسن الحظ، لا تؤثر هذه القيود في إصدارات Chrome المتوافقة مع الأجهزة الجوّالة، وسيتمّ رفعها بالكامل لجميع الأنظمة الأساسية عند اكتمال العمل على سياسة الميزات.

مساعدة المستخدمين على الشبكات البطيئة

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

في ما يتعلّق بموقع Sconnie Timber الإلكتروني، نتّخذ خطوات لتخفيف الحمل عندما تكون الشبكات بطيئة، ويتم فحص رؤوس Save-Data وECT وRTT وDownlink في رمز الخلفية. عند الانتهاء من ذلك، ننشئ علامة قياس لجودة الشبكة يمكننا استخدامها لتحديد ما إذا كان علينا التدخل لتحسين تجربة المستخدم. تتراوح نتيجة الشبكة هذه بين 0 و1، حيث يمثّل 0 أسوأ جودة ممكنة للشبكة، و1 هو الأفضل.

في البداية، نتحقّق مما إذا كان Save-Data متوفّرًا. إذا كان الأمر كذلك، يتم ضبط النتيجة على 0، لأنّنا نفترض أنّ المستخدم يريد منا تنفيذ كل ما هو ضروري لجعل تجربته أكثر سلاسة وسرعة.

في حال عدم توفّر Save-Data، ننتقل إلى الخطوة التالية ونضع في الاعتبار قيم التلميحَين ECT وRTT وDownlink لاحتساب نتيجة تصف جودة اتصال بالشبكة. يتوفّر رمز المصدر لإنشاء نتيجة الشبكة على Github. خلاصة القول هي أنّه إذا استخدمنا التلميحات المتعلّقة بالشبكة بطريقة معيّنة، يمكننا تحسين التجارب للمستخدمين الذين يستخدمون شبكات بطيئة.

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

في هذا المثال، يمكننا الاطّلاع على تأثير إشارات العميل في تحسين أداء المواقع الإلكترونية على الشبكات البطيئة. في ما يلي ملف WebPagetest المخطّط البياني لموقع إلكتروني على شبكة بطيئة لا تتكيّف مع إشارات العميل:

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

أدّت إشارات العميل إلى تقليل وقت تحميل الصفحة من أكثر من 45 ثانية إلى أقل من десятому من هذا الوقت. لا يمكن التأكيد بشكل كافٍ على فوائد اقتراحات العميل في هذا السيناريو، ويمكن أن تكون ميزة قيّمة للمستخدمين الذين يبحثون عن معلومات مهمة على الشبكات البطيئة.

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

// Set the ECT value to "4g" by default.
$ect = isset($_SERVER["HTTP_ECT"]) ? $_SERVER["HTTP_ECT"] : "4g";

في هذه الحالة، يمثّل "4g" اتصال الشبكة الأعلى جودة الذي يصفه عنوان ECT. في حال ضبط القيمة التلقائية لـ $ect على "4g"، لن تتأثّر المتصفّحات التي لا تتيح استخدام رسائل العميل التلميحية. تفعيل الميزة

انتبه إلى ذاكرات التخزين المؤقت هذه.

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

Vary: DPR, Width

هناك تحذير كبير بشأن ذلك: يجب عدم Vary تخزين ملفّات تعريف الارتباط لطلبات البحث التي يمكن تخزينها مؤقتًا في عناوين تتغيّر بشكل متكرّر (مثل Cookie) لأنّه يصبح من المستحيل تخزين ملفّات تعريف الارتباط لهذه الطلبات بشكل فعّال. بناءً على ذلك، ننصحك بعدم Varyالاعتماد على رؤوس تلميحات العميل، مثل RTT أو Downlink، لأنّها عوامل ربط يمكن أن تتغيّر كثيرًا. إذا كنت تريد تعديل الإجابات على هذه العناوين، ننصحك بضبط عنوان ECT فقط، ما سيؤدي إلى تقليل حالات عدم توفّر ذاكرة التخزين المؤقت.

لا ينطبق ذلك إلا إذا كنت تخزِّن استجابة في الأساس. على سبيل المثال، لن تخزِّن مواد عرض HTML في ذاكرة التخزين المؤقت إذا كان محتواها ديناميكيًا، لأنّه قد يؤدي ذلك إلى تعطيل تجربة المستخدم عند الزيارات المتكرّرة. في مثل هذه الحالات، يُرجى عدم التردد في تعديل هذه الردود على أي أساس تراه ضروريًا وعدم القلق بشأن Vary.

تعديلات العميل في مهام الخدمة

لم تعُد مفاوضة المحتوى متاحة للخوادم فقط. بما أنّ مهام الخدمة تعمل كوكلاء بين العملاء والخوادم، يمكنك التحكّم في كيفية عرض مواردك من خلال JavaScript. ويشمل ذلك تلميحات العميل. في حدث worker fetch، يمكنك استخدام العنصر event request.headers.get لقراءة رؤوس طلب المورد على النحو التالي:

self.addEventListener('fetch', (event) => {
  let dpr = event.request.headers.get('DPR');
  let viewportWidth = event.request.headers.get('Viewport-Width');
  let width = event.request.headers.get('Width');

  event.respondWith(
    (async function () {
      // Do what you will with these hints!
    })(),
  );
});

يمكن قراءة أيّ عنوان تلميح عميل تفعّله بهذه الطريقة. ومع ذلك، ليس هذا هو الطريقة الوحيدة للحصول على بعض هذه المعلومات. يمكن قراءة التلميح الخاص بالشبكة في سمات JavaScript المعادلات التالية في كائن navigator:

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

if ('connection' in navigator) {
  // Work with netinfo API properties in JavaScript!
}

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

ملخص

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

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

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

الموارد

• الصور المتجاوبة التلقائية باستخدام رسائل العميل التلميحات
• ملاحظات العميل والصور المتجاوبة: التغييرات في الإصدار Chrome 67
• الحصول على تلميح (عميل) (العروض التقديمية)
• توفير تطبيقات سريعة وخفيفة باستخدام Save-Data

نشكر إيليا غريغوريك وإريك بورتيس وجيف بوسنيك ويوآف وايس وإيستل وييل على مساهمتهم في تحسين هذه المقالة من خلال تقديم ملاحظاتهم وآراءهم المُهمة وإجراء التعديلات عليها.