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

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

Jeremy Wagner

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

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

يتعلق الأمر برمته بالتفاوض على المحتوى

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

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

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

على الرغم من أنّ جميع المتصفّحات تتيح تنسيقات الصور مثل JPEG وPNG وGIF، توضِّح هذه الحالة أنّ المتصفّح يتوافق أيضًا مع 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 هو 320x240، لأنّ 640x480 مقسومًا على 2 هي 320x240.

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

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

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

عرض إطار العرض

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

Viewport-Width: 320

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

جمهورية الدومينيكان

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 بكسل) مضروبًا في DPR للشاشة (2)، أي ما يساوي 544 بكسل.

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

المحتوى-DPR

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

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

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

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

ذاكرة الجهاز

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

Device-Memory: 2

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

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

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

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

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

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

RTT: 125

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

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

رابط التنزيل

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

Downlink: 2.5

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

بالإضافة إلى 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 هو الوحيد الذي لا يمكنك الموافقة عليه في 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 في الخلفية؟"، هو السؤال الأول.

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

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

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

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

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

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

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

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

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

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

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

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

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

Vary: DPR, Width

مع ذلك، هناك تنبيه جسيم: يجب عدم حفظ Vary ردود قابلة للتخزين المؤقت على عنوان يتغير باستمرار (مثل Cookie) لأنّ هذه الموارد تصبح غير قابلة للتخزين المؤقت بشكل فعّال. من هذا المنطلق، ننصحك بتجنّب استخدام Vary في عناوين تلميحات العميل، مثل RTT أو Downlink، لأنّها تشكّل عوامل ربط يمكن أن تتغيّر كثيرًا. وإذا أردت تعديل الردود على هذه العناوين، ننصحك بإدراج عنوان 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!
    })(),
  );
});

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

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

مكوّنات Imagemin الإضافية لأنواع الملفات.
تلميح للعميل	مكافئ JavaScript
`ect`	`navigator.connection.effectiveType`
"المراسلة النصية في الوقت الفعلي"	"navigator.connection.rtt"
"حفظ البيانات"	`navigator.connection.saveData`
"الرابط الهبوطي"	`navigator.connection.downlink`
"ذاكرة الجهاز"	"navigator.deviceMemory"

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

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

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

ملخص

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

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

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

المراجِع

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