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

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

توفّر 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 الأخشاب تحميل جميع الموارد على اتصال شبكة بطيء. — **الشكل 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 ومتصفّحات Chrome المبنية على Chromium، من الممكن استخدامها بطريقة لا تؤثر في المتصفّحات التي لا تتوافق معها. ضع في اعتبارك استخدام تلميحات العميل لإنشاء تجارب شاملة وقابلة للتكيّف حقًا على دراية بإمكانات أجهزة كل مستخدم والشبكات التي يتصل بها. نأمل أن يدرك مورّدو المتصفّحات الآخرون قيمة هذه الميزات وأن يبدؤوا تنفيذها.

الموارد

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