تمت ترجمة هذه الصفحة بواسطة Cloud Translation API‏.

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

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" />

تحذير: تضمّنت الإصدارات السابقة من المواصفات العنوان Accept-CH-Lifetime الذي تمت إزالته الآن، ومن المفترض أن تتوقّف المواقع الإلكترونية أيضًا عن إرساله. إذا كنت تستخدم هذا الإجراء لتفعيل الاحتفاظ بالاقتراحات على مدار جلسات المتصفّح، عليك بدلاً من ذلك التأكّد من إرسال رؤوس Accept-CH اللازمة في الردود ذات الصلة.

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

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

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

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

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

الحجم الأساسي: السمات الفعلية لمصدر وسائط. على سبيل المثال، إذا فتحت صورة في 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 في هذه الحالة هو 320×240، وأنّ الحجم الأساسي لصورة 2x هو 640×480. إذا تم تحليل هذه الترميزات من قِبل مثبّت العميل على جهاز بنسبة كثافة بكسل للشاشة تبلغ 2 (مثل شاشة Retina )، يتم طلب صورة 2x. الحجم الأساسي الذي تم تصحيحه حسب الكثافة ل صورة 2x هو 320×240، لأنّ 640×480 مقسومًا على 2 يساوي 320×240.

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

صورة توضيحية للحجم الجوهري مقارنةً
بالحجم الخارجي يظهر مربّع أبعاده 320×240 بكسل مع تصنيف INTRINSIC
SIZE. يتضمّن هذا العنصر مربّعًا أصغر حجمه 256×192 بكسل، ويمثّل
عنصر img في HTML تم تطبيق CSS عليه. تم تصنيف هذا المربّع باسم EXTRINSIC
SIZE. على يسار الصفحة، يظهر مربّع يحتوي على نمط CSS الذي تم تطبيقه على العنصر الذي يغيّر تنسيق عنصر img لكي يختلف حجمه الخارجي عن حجمه الداخلي. — **الشكل 1**. صورة توضيحية للحجم الجوهري مقارنةً بالحجم الخارجي تكتسب الصورة حجمها الخارجي بعد تطبيق عوامل التنسيق عليها. في هذه الحالة، يؤدي تطبيق قواعد CSS الخاصة بـ `width: 256px;` و`height: 192px;` إلى تحويل صورة ذات حجم أساسي يبلغ 320×240 إلى صورة ذات حجم خارجي يبلغ 256×192.

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

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، سيرسل العميل هذا التلميح إلى الخادم مع طلب src في <img>:Width

Width: 544

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

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

Content-DPR

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

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

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

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

ذاكرة الجهاز

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

Device-Memory: 2

ملاحظة: بما أنّه يمكن استخدام هذه المعلومات لإنشاء بصمة مستخدمين، تكون قيمة Device-Memory تقريبية عن قصد. القيم الصالحة هي 0.25 و0.5 و1 و2 و4 و8.

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

تعديلات الشبكة

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

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

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

RTT: 125

ملاحظة: يتم تقريب قيمة RTT إلى أقرب 25 ملي ثانية لمنع وضع بصمة رقمية.

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

رابط للتحميل

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

Downlink: 2.5

ملاحظة: يتم تقريب قيمة Downlink إلى أقرب مضاعف 25 كيلوبت في الثانية. لأنّه مرة أخرى، يتم استخدام بصمة الإصبع.

يمكن أن يكون مقياس 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 هي الإشار الوحيدة التي لا يمكنك تفعيلها باستخدام Accept-CH. يمكن للمستخدم فقط التحكّم في إرسال هذا التلميح من خلال تفعيل ميزة "توفير البيانات" في Chrome على أجهزة Android.

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

Save-Data: on

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

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

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

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

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

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

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

اختَر أولاً معالجة الصورة (أي الصور الموجَّهة للفن) من خلال وضع علامة في المربّع بجانب التلميح Viewport-Width، إذا كان ذلك منطبقًا على سير عملك.
اختَر درجة دقة الصورة من خلال وضع علامة في مربّع التلميح Width ومربّع التلميح DPR، واختَر مصدرًا يناسب حجم تنسيق الصورة وكثافة الشاشة (على غرار طريقة عمل الأوصاف x وw في srcset).
اختَر تنسيق الملف الأمثل الذي يتيح استخدامه المتصفّح (يساعدنا 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. خلاصة القول هي أنّه إذا استخدمنا التلميحات المتعلّقة بالشبكة بطريقة معيّنة، يمكننا تحسين التجارب للمستخدمين الذين يستخدمون شبكات بطيئة.

مقارنة بين موقع إلكتروني لا يستخدم
إشارات العميل للتكيّف مع اتصال الشبكة البطيء (على يمين الصفحة) والموقع الإلكتروني نفسه الذي يستخدم
هذه الإشارات (على يمين الصفحة) — **الشكل 2**. صفحة "لمحة عنا" لموقع إلكتروني لنشاط تجاري محلي تتضمّن التجربة الأساسية خطوط الويب وJavaScript لتشغيل سلوك ملف التمرير المتعدّد واللوحات المنسدلة، بالإضافة إلى صور المحتوى. هذه هي كل الأشياء التي يمكننا حذفها عندما تكون حالات الشبكة بطيئة جدًا ولا يمكن تحميلها بسرعة.

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

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

رسم بياني للتحميل في WebPagetest لموقع Sconnie
Timber الإلكتروني الذي يحمّل جميع الموارد على اتصال شبكة بطيء — **الشكل 3**. موقع إلكتروني يستهلك الكثير من الموارد ويحمّل الصور والنصوص البرمجية والخطوط على اتصال بطيء

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

رسم بياني للعرض بدون انقطاع من WebPagetest لموقع Sconnie
Timber الإلكتروني باستخدام إشارات العميل لتحديد عدم تحميل الموارد غير المهمة عند اتصال الشبكة ببطء — **الشكل 4**. الموقع الإلكتروني نفسه على الاتصال نفسه، يتم استبعاد الموارد "المرغوب فيها" فقط لصالح loading أسرع.

أدّت إشارات العميل إلى تقليل وقت تحميل الصفحة من أكثر من 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!
    })(),
  );
});

تحذير: بما أنّ بعض المتصفحات لا تتيح استخدام نصائح العملاء، عليك التحقّق من القيم التي يعرضها event.request.headers.get. من الطرق البديلة المحتملة تسجيل مكافئات JavaScript، مثل window.devicePixelRatio أو window.innerWidth إلى IndexedDB، والتي يمكن الوصول إليها في نطاق مشغّل الخدمة.

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

مكونات Imagemin الإضافية لأنواع الملفات
تعديلات العميل	مكافئ JavaScript
‎`ECT`‎	‎`navigator.connection.effectiveType`‎
`RTT`	`navigator.connection.rtt`
Save-Data	`navigator.connection.saveData`
‎`Downlink`‎	`navigator.connection.downlink`
‎`Device-Memory`‎	`navigator.deviceMemory`

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

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

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

ملخص

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

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

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

الموارد

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