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

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

تلميحات العميل هي مجموعة من عناوين طلبات 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 تعديلاً للعميل". لا تقلق بشأن التلميحات المحددة نفسها. سنصل إليها بعد قليل.

يمكنك ضبط رؤوس الموافقة هذه بأي لغة خلفية. على سبيل المثال، يُعد PHP الدالة header. يمكنك أيضًا ضبط عناوين الموافقة هذه باستخدام 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 في هذه الحالة هو 320×240، الحجم الأساسي لصورة 2x هو 640×480. إذا حلل العميل هذا الترميز مُثبَّت على جهاز بنسبة وحدات بكسل تبلغ 2 (على سبيل المثال، شاشة ريتينا) الشاشة)، يتم طلب صورة 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
الحجم يوجد داخلها مربع أصغر بحجم 256×192 بكسل، وهو يمثل
عنصر صورة HTML مع تطبيق CSS عليه. تم تصنيف هذا المربع باعتباره &quot;غير تقليدي&quot;
الحجم يوجد إلى اليمين مربع يحتوي على CSS تم تطبيقه على العنصر الذي
لتعديل تنسيق عنصر الصورة بحيث يختلف حجمها الخارجي
عن حجمه الجوهري.
الشكل 1. صورة توضيحية للدالة الجوهرية مقابل الحجم الخارجي. تكتسب الصورة حجمها الخارجي بعد استخدام عوامل التصميم. الذي تم تطبيقه عليه. في هذه الحالة، سيتم تطبيق قواعد width: 256px; لخدمة مقارنة الأسعار (CSS). وheight: 192px; تحوّل الصورة بحجم 320×240 إلى حجم جوهري إلى مقاس خارجي 256×192

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

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

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

Viewport-Width: 320

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

DPR

تشير DPR، وهي نسبة وحدات بكسل للأجهزة، إلى نسبة وحدات البكسل الفعلية إلى CSS. وحدات البكسل لشاشة المستخدم:

DPR: 2

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

العرض

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

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

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

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

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

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

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

RTT: 125

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

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

Downlink: 2.5

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

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

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

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

ECT: 2g

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

حفظ البيانات

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

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

Save-Data: on

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

شلال WebPagetest في &quot;كوني&quot;
موقع إلكتروني خشبي يحمِّل جميع الموارد على اتصال بطيء بالشبكة.
الشكل 3. أو الموقع الذي يحمل موارد كبيرة من الصور والنصوص البرمجية والخطوط عندما يكون الاتصال بطيئًا.

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

شلال WebPagetest في &quot;كوني&quot;
موقع خشبي يستخدم تعديلات العميل لتحديد عدم تحميل موارد غير مهمة على
اتصال بطيء بالشبكة.
الشكل 4. نفس الموقع على نفس الاتصال، ذلك أنه يتم استبعاد الموارد "من الجيد توفر" فقط لصالح الموارد الأسرع قيد التحميل

أدت تلميحات العميل إلى تقليل وقت تحميل الصفحة من أكثر من 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. يتضمّن ذلك تلميحات عن العميل. في مشغّل الخدمات fetch، يمكنك استخدام عنصر event request.headers.get لقراءة عناوين طلبات المورد مثل:

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

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

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

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

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

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

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

ملخص

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

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

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

الموارد

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