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

Jeremy Wagner

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

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

المفاوضة بشأن المحتوى هي الأساس

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

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

Accept: image/webp,image/apng,image/*,*/*;q=0.8

في حين أنّ جميع المتصفّحات تتيح استخدام تنسيقات الصور مثل JPEG وPNG وGIF، يوضّح حقل Accept في هذه الحالة أنّ المتصفّح يتيح أيضًا استخدام WebP وAPNG. باستخدام هذه المعلومات، يمكننا التفاوض على أفضل أنواع الصور لكل متصفّح:

<?php
// Check Accept for an "image/webp" substring.
$webp = stristr($_SERVER["HTTP_ACCEPT"], "image/webp") !== false ? true : false;

// Set the image URL based on the browser's WebP support status.
$imageFile = $webp ? "whats-up.webp" : "whats-up.jpg";
?>
<img src="<?php echo($imageFile); ?>" alt="I'm an image!">

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

التفعيل

على عكس العنوان Accept، لا تظهر تلميحات العميل بشكل تلقائي (باستثناء Save-Data الذي سنتحدّث عنه لاحقًا). للحفاظ على الحد الأدنى من عناوين الطلبات، عليك تحديد الإشارات التي تريد تلقّيها من خلال إرسال عنوان Accept-CH عندما يطلب المستخدم موردًا:

Accept-CH: Viewport-Width, Downlink

قيمة Accept-CH هي قائمة قيم مفصولة بفاصلة من التلميحات المطلوبة التي سيستخدمها الموقع الإلكتروني في تحديد نتائج طلب الموارد اللاحق. عندما يقرأ العميل هذا العنوان، يتم إخباره بأنّ "هذا الموقع الإلكتروني يريد تلميحات العميل Viewport-Width وDownlink". ولا داعي للقلق بشأن التلميحات المحدّدة نفسها. سنتطرق إلى هذه الميزات بعد قليل.

يمكنك ضبط عناوين الموافقة هذه بأي لغة من لغات الخلفية. على سبيل المثال، يمكن استخدام دالة header في PHP. يمكنك حتى ضبط عناوين الموافقة هذه باستخدام السمة http-equiv في علامة <meta>:

<meta http-equiv="Accept-CH" content="Viewport-Width, Downlink" />

جميع تعديلات برنامج وكيل المستخدم

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

تلميحات الجهاز

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

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

الحجم الأصلي: يمثّل ذلك الأبعاد الفعلية لمورد الوسائط. على سبيل المثال، إذا فتحت صورة في Photoshop، ستصف الأبعاد المعروضة في مربّع حوار حجم الصورة الحجم الأصلي.

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

<img
  src="whats-up-1x.png"
  srcset="whats-up-2x.png 2x, whats-up-1x.png 1x"
  alt="I'm that image you wanted."
/>

لنفترض أنّ الحجم الأصلي للصورة 1x في هذه الحالة هو 320x240، وأنّ الحجم الأصلي للصورة 2x هو 640x480. إذا حلّل أحد البرامج هذا الترميز على جهاز مزوّد بشاشة تبلغ نسبة وحدات البكسل فيها إلى الجهاز 2 (مثل شاشة Retina)، سيتم طلب الصورة 2x. الحجم الأصلي المعدَّل حسب الكثافة للصورة 2x هو 320x240، لأنّ 640x480 مقسومًا على 2 يساوي 320x240.

الحجم الخارجي: هو حجم مورد الوسائط بعد تطبيق CSS وعوامل التنسيق الأخرى (مثل السمتَين width وheight). لنفترض أنّ لديك عنصر <img> يحمّل صورة بحجم أصلي معدَّل الكثافة يبلغ 320 × 240، ولكنّه يتضمّن أيضًا السمتَين width وheight في CSS بقيمتَين 256px و192px على التوالي. في هذا المثال، يصبح الحجم الخارجي لعنصر <img> هذا هو 256x192.

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

Viewport-Width

‫Viewport-Width هو عرض إطار العرض الخاص بالمستخدم بوحدات بكسل CSS:

Viewport-Width: 320

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

DPR

‫DPR، وهي اختصار لعبارة "نسبة وحدات البكسل على الجهاز"، وتُظهر نسبة وحدات البكسل الفعلية إلى وحدات بكسل CSS على شاشة المستخدم:

DPR: 2

تكون هذه الإشارة مفيدة عند اختيار مصادر الصور التي تتوافق مع كثافة وحدات البكسل في الشاشة (مثلما تفعل واصفات x في السمة srcset).

العرض

يظهر التلميح Width في الطلبات التي يتم إرسالها للحصول على موارد الصور من خلال العلامات <img> أو <source> باستخدام السمة sizes. تخبر sizes المتصفّح بالحجم الخارجي للمورد، وتستخدم Width هذا الحجم الخارجي لطلب صورة بحجم داخلي مناسب للتنسيق الحالي.

على سبيل المثال، لنفترض أنّ أحد المستخدمين يطلب صفحة بعرض 320 بكسل CSS على شاشة بنسبة كثافة بكسل تبلغ 2. يحمّل الجهاز مستندًا يتضمّن عنصر <img> يحتوي على قيمة السمة sizes وهي 85vw (أي ‫85% من عرض إطار العرض لجميع أحجام الشاشات). في حال تفعيل تلميح Width، سيرسل العميل تلميح Width هذا إلى الخادم مع طلب src الخاص بـ <img>:

Width: 544

في هذه الحالة، يشير العميل إلى الخادم بأنّ العرض الداخلي الأمثل للصورة المطلوبة سيكون% 85 من عرض إطار العرض (272 بكسل) مضروبًا في نسبة كثافة البكسل على الشاشة (2)، ما يساوي 544 بكسل.

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

Content-DPR

كما تعلم، تحتوي الشاشات على نسبة وحدات البكسل على الجهاز، ولكن تحتوي الموارد أيضًا على نسب وحدات البكسل الخاصة بها. في أبسط حالات استخدام اختيار الموارد، يمكن أن تكون نسب البكسل بين الأجهزة والموارد متطابقة. ولكن! في الحالات التي يتم فيها استخدام كل من العنوانَين DPR وWidth، يمكن أن يؤدي الحجم الخارجي للمورد إلى سيناريوهات يختلف فيها العنوانان. هنا يأتي دور التلميح Content-DPR.

على عكس تلميحات العميل الأخرى، Content-DPR ليس عنوان طلب يستخدمه الخادم، بل هو عنوان استجابة على الخادم يجب إرساله كلما تم استخدام التلميحات DPR وWidth لاختيار أحد الموارد. يجب أن تكون قيمة Content-DPR هي نتيجة هذه المعادلة:

‫Content-DPR = [حجم مورد الصورة المحدّدة] / ([Width] / [DPR])

عند إرسال عنوان طلب Content-DPR، سيعرف المتصفّح كيفية تغيير حجم الصورة المحدّدة لتناسب نسبة وحدات البكسل على الجهاز في الشاشة والتصميم. وبدونها، قد لا يتم تغيير حجم الصور بشكل صحيح.

Device-Memory

Device-Memory هي جزء من Device Memory API، وتكشف عن المقدار التقريبي للذاكرة المتوفرة في الجهاز الحالي بوحدة غيغابايت:

Device-Memory: 2

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

تلميحات الشبكة

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

مراسلة نصية في الوقت الفعلي

يوفّر التلميح RTT مدة الذهاب والعودة التقريبية، بالمللي ثانية، على مستوى التطبيق. يختلف تلميح RTT عن وقت الاستجابة الكامل (RTT) في طبقة النقل، إذ يتضمّن وقت معالجة الخادم.

RTT: 125

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

Downlink

مع أنّ وقت الاستجابة مهم في أداء التحميل، إلا أنّ معدّل نقل البيانات يؤثر أيضًا في الأداء. تعرض تلميحة Downlink، المعروضة بالميغابت في الثانية، السرعة التقريبية لتنزيل البيانات من الإنترنت على جهاز المستخدم:

Downlink: 2.5

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

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

يشير التلميح 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 على أنّه تلميح شبكة لأنّ العديد من الإجراءات التي يمكنك تنفيذها باستخدام هذا التلميح تشبه تلك التي يمكنك تنفيذها باستخدام تلميحات الشبكة الأخرى. من المحتمل أيضًا أن يفعِّل المستخدمون هذه الميزة في البيئات التي يكون فيها معدل نقل البيانات منخفضًا أو وقت الاستجابة طويلاً. يظهر هذا التلميح دائمًا على النحو التالي:

Save-Data: on

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

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

يعتمد ما تفعله مع تلميحات العميل عليك. وبما أنّها تقدّم الكثير من المعلومات، تتوفّر لك خيارات عديدة. للحصول على بعض الأفكار، لنرَ ما يمكن أن تقدّمه تلميحات العميل لشركة Sconnie Timber، وهي شركة خشبية وهمية تقع في منطقة Upper Midwest الريفية. وكما هو الحال غالبًا في المناطق النائية، قد تكون اتصالات الشبكة غير مستقرة. وهنا يأتي دور تكنولوجيات مثل تلميحات العميل التي يمكن أن تُحدث فرقًا كبيرًا للمستخدمين.

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

يمكن أن تصبح جميع حالات استخدام الصور المتجاوبة معقّدة باستثناء أبسطها. ماذا لو كان لديك معالجات و صيغ متعددة من الصور نفسها لأحجام شاشات مختلفة و بتنسيقات مختلفة؟ ويصبح الترميز معقّدًا جدًا بسرعة. من السهل أن ترتكب أخطاء، ومن السهل أن تنسى أو يساء فهمك للمفاهيم المهمة (مثل 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 عند استخدام المتصفحات التي تتيح تلميحات العميل.

لكن احذر! أدت التغييرات التي تم إجراؤها في الإصدار 67 من Chrome على نسخة الموقع الإلكتروني المخصّصة لأجهزة الكمبيوتر إلى إزالة إمكانية استخدام حقول معلومات العميل من مصادر متعددة. لحسن الحظ، لا تؤثر هذه القيود في إصدارات 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"، لن تتأثر المتصفّحات التي لا تتوافق مع تلميحات العميل. Opt-in FTW!

انتبه إلى تلك الذاكرات المؤقتة!

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

Vary: DPR, Width

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

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

تعديلات برنامج وكيل المستخدم في برامج الخدمة

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

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!
    })(),
  );
});

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

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

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

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

ملخص

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

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

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

الموارد

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

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