قد يكون تطوير المواقع الإلكترونية السريعة في أي مكان عميلاً محتملاً صعبًا. إنّ العدد الكبير من إمكانات الأجهزة وجودة الشبكات التي تتصل بها قد تجعل هذه المهمة تبدو مستحيلة. على الرغم من أنّه يمكننا الاستفادة من ميزات المتصفّح لتحسين أداء التحميل، كيف يمكننا معرفة ما يمكن أن يفعله جهاز المستخدم أو جودة اتصاله بالشبكة؟ الحل هو تلميحات العميل.
تلميحات العميل هي مجموعة من عناوين طلبات HTTP التي يمكن الموافقة عليها والتي تمنحنا إحصاءات بشأن هذه الجوانب المتعلقة بجهاز المستخدم والشبكة التي يتصل بها. ومن خلال الاستفادة من هذه المعلومات من جهة الخادم، يمكننا تغيير طريقة عرض المحتوى استنادًا إلى حالة الجهاز و/أو الشبكة. ويمكن أن يساعدنا ذلك في إنشاء تجارب مستخدمين أكثر شمولية.
التركيز على التفاوض بشأن المحتوى
تلميحات العملاء هي طريقة أخرى للتفاوض على المحتوى، وهي تعني تغيير الردود على المحتوى استنادًا إلى عناوين طلبات المتصفّح.
من الأمثلة على التفاوض على المحتوى استخدام Accept
عنوان الطلب. وهو يصف أنواع المحتوى التي يفهمها المتصفّح، والتي يمكن للخادم استخدامها للتفاوض بشأن الاستجابة. بالنسبة إلى طلبات الصور، يكون محتوى
عنوان Accept
في Chrome كما يلي:
Accept: image/webp,image/apng,image/*,*/*;q=0.8
على الرغم من أنّ جميع المتصفّحات تتيح استخدام تنسيقات الصور مثل JPEG وPNG وGIF، يشير الحقل Accept في هذه الحالة إلى أنّ المتصفّح يتوافق أيضًا مع WebP وAPNG. باستخدام هذه المعلومات، يمكننا التفاوض على أفضل أنواع الصور لكل متصفح:
<?php
// Check Accept for an "image/webp" substring.
$webp = stristr($_SERVER["HTTP_ACCEPT"], "image/webp") !== false ? true : false;
// Set the image URL based on the browser's WebP support status.
$imageFile = $webp ? "whats-up.webp" : "whats-up.jpg";
?>
<img src="<?php echo($imageFile); ?>" alt="I'm an image!">
مثل Accept
، تُعدّ إشارات العميل طريقة أخرى للتفاوض على المحتوى، ولكن في
سياق إمكانات الجهاز وظروف الشبكة. باستخدام إشارات العميل، يمكننا اتخاذ قرارات بشأن الأداء من جهة الخادم استنادًا إلى تجربة كل مستخدم، مثل تحديد ما إذا كان يجب عرض الموارد غير المهمة للمستخدمين الذين يعانون من ظروف شبكة سيئة. في هذا الدليل، سنوضّح كل الاقتراحات المتاحة وبعض الطرق التي يمكنك استخدامها لجعل عرض المحتوى أكثر ملاءمةً للمستخدمين.
التفعيل
على عكس عنوان Accept
، لا تظهر تلميحات العميل بطريقة سحريّة فقط (باستثناء Save-Data
الذي سنناقشه لاحقًا). من أجل الحفاظ على الحد الأدنى من رؤوس الطلبات، عليك تفعيل التلميحات التي تريد تلقّيها من العميل من خلال إرسال رأس Accept-CH
عندما يطلب مستخدم موارد:
Accept-CH: Viewport-Width, Downlink
قيمة Accept-CH
هي قائمة مفصولة بفواصل للتلميحات المطلوبة التي سيستخدمها الموقع الإلكتروني
في تحديد نتائج طلب المورد اللاحق. عندما يقرأ العميل
هذا العنوان، يتم إبلاغه بأنّ "هذا الموقع الإلكتروني يريد إشارات العميل Viewport-Width
وDownlink
". لا داعي للقلق بشأن الإشارات المحدّدة نفسها.
سنتناول هذه النقاط بعد قليل.
يمكنك ضبط رؤوس الموافقة هذه بأي لغة خلفية. على سبيل المثال، يمكن استخدام دالة
header
في PHP.
يمكنك أيضًا ضبط عناوين الموافقة هذه باستخدام السمة http-equiv
على علامة <meta>
:
<meta http-equiv="Accept-CH" content="Viewport-Width, Downlink" />
كل تعديلات برنامج وكيل المستخدم
تصفّ تلميحات العملاء أحد الأمرَين: الجهاز الذي يستخدمه المستخدمون، واستخدامهم، والشبكة التي يستخدمونها للوصول إلى موقعك الإلكتروني. لنطّلِع بإيجاز على كل الاقتراحات المتاحة.
تلميحات الجهاز
تصف بعض إشارات العميل خصائص جهاز المستخدم، وعادةً ما تكون خصائص الشاشة. ويمكن أن يساعدك بعضها في اختيار مورد الوسائط الأمثل لشاشة مستخدم معيّن، ولكن ليس كلّها بالضرورة تركّز على الوسائط.
قبل الاطّلاع على هذه القائمة، قد يكون من المفيد التعرّف على بعض المصطلحات الرئيسية المستخدَمة لوصف الشاشات ودرجة دقة الوسائط:
الحجم الأساسي: السمات الفعلية لمصدر وسائط. على سبيل المثال، إذا فتحت صورة في Photoshop، تصف الأبعاد المعروضة في مربّع حوار حجم الصورة حجمها الأساسي.
الحجم الأساسي المعدَّل حسب الكثافة: أبعاد مورد وسائط بعد تعديلها لتتلاءم مع كثافة البكسل وهو الحجم الأساسي للصورة مقسومًا على نسبة وحدات البكسل على الجهاز . على سبيل المثال، لنأخذ علامة الترميز هذه:
<img
src="whats-up-1x.png"
srcset="whats-up-2x.png 2x, whats-up-1x.png 1x"
alt="I'm that image you wanted."
/>
لنفترض أنّ الحجم الأساسي لصورة 1x
في هذه الحالة هو 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.
سنتعرّف الآن على بعض المصطلحات والتلميحات المتعلّقة بالعميل والمتاحة لكل جهاز.
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
يمكن استخدام هذه التلميحة في تقليل كمية JavaScript المُرسَلة إلى المتصفّحات على الأجهزة ذات الذاكرة المحدودة، لأنّ JavaScript هو نوع المحتوى الذي يستهلك موارد المتصفّحات بشكلٍ كبير. أو يمكنك إرسال صور DPR أقل لأنها تستخدم ذاكرة أقل لفك الترميز.
تعديلات الشبكة
توفّر Network Information API فئة أخرى من إشارات العميل التي تصف أداء اتصال المستخدم بالشبكة. في رأيي، هذه هي مجموعة التلميحات الأكثر فائدة. ومن خلال هذه الميزة، يصبح بإمكاننا تخصيص التجارب للمستخدمين من خلال تغيير طريقة إرسال الموارد إلى العملاء الذين يستخدمون اتصالات بطيئة.
مراسلة نصية في الوقت الفعلي
يوفّر تلميح RTT
مدة الذهاب والعودة التقريبية، بالمللي ثانية، على طبقة التطبيق. على عكس وقت استجابة الطلب (RTT) في طبقة النقل، يتضمّن التلميح RTT
وقت معالجة الخادم.
RTT: 125
يكون هذا التلميح مفيدًا بسبب الدور الذي تلعبه مدة الاستجابة في أداء التحميل.
باستخدام التلميح RTT
، يمكننا اتخاذ قرارات استنادًا إلى استجابة الشبكة،
ما يمكن أن يساعد في تسريع عرض تجربة كاملة (مثلاً، من خلال
حذف بعض الطلبات).
رابط للأسفل
على الرغم من أنّ وقت الاستجابة مهم في أداء التحميل، إلا أنّ معدل نقل البيانات مهم أيضًا.
يشير التلميح Downlink
، الذي يتم التعبير عنه بالميغابت في الثانية (Mbps)، إلى السرعة
التقريبية لتنزيل البيانات في اتصال المستخدم:
Downlink: 2.5
يمكن أن يكون الخيار 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
كتلميح للشبكة، لأنّ العديد من الإجراءات التي ستنفّذها باستخدام هذه الأداة تشبه تلميحات الشبكة الأخرى. وقد يميل المستخدمون أيضًا
إلى تفعيلها في البيئات التي يكون فيها وقت الاستجابة مرتفعًا أو معدل نقل البيانات منخفضًا. يظهر هذا التلميح، عند
توفّره، دائمًا على النحو التالي:
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. خلاصة القول هي أنّه إذا استخدمنا التلميحات المتعلّقة بالشبكة بطريقة
معيّنة، يمكننا تحسين التجارب للمستخدمين الذين يستخدمون
شبكات بطيئة.
عندما تتكيّف المواقع الإلكترونية مع المعلومات التي تقدّمها إشارات العميل، لا نحتاج إلى اتّباع أسلوب "الكل أو لا شيء". يمكننا تحديد الموارد التي يجب إرسالها بذكاء. يمكننا تعديل منطق اختيار الصور المتوافقة مع مختلف الأجهزة لإرسال صور بجودة أقل لشاشة معيّنة من أجل تسريع أداء التحميل عندما تكون جودة الشبكة منخفضة.
في هذا المثال، يمكننا الاطّلاع على تأثير إشارات العميل في تحسين أداء المواقع الإلكترونية على الشبكات البطيئة. في ما يلي ملف WebPagetest المخطّط البياني لموقع إلكتروني على شبكة بطيئة لا تتكيّف مع إشارات العميل:
في ما يلي عرض مرئي للموقع الإلكتروني نفسه على الاتصال البطيء نفسه، إلا أنّه في هذه المرة، يستخدم الموقع الإلكتروني إشارات العميل لإزالة موارد الصفحة غير المهمة:
أدّت إشارات العميل إلى تقليل وقت تحميل الصفحة من أكثر من 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!
})(),
);
});
يمكن قراءة أيّ عنوان تلميح عميل تفعّله بهذه الطريقة. ومع ذلك، ليس هذا هو
الطريقة الوحيدة للحصول على بعض هذه المعلومات. يمكن قراءة التلميح الخاص بالشبكة
في سمات JavaScript المعادلات التالية في كائن navigator
:
تعديلات العميل | مكافئ 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
، خاصةً في حالات الاستخدام المعقّدة. ولا يقتصر الأمر على تقليل الوقت والجهد في جانب التطوير فحسب، بل أيضًا في تحسين الموارد، لا سيما الصور، بطريقة تستهدف شاشات المستخدمين بدقة أكبر مقارنةً بـ .
والأهم من ذلك، يمكننا رصد عمليات الاتصال السيئة بالشبكة وسدّ فجوة الأداء للمستخدمين من خلال تعديل ما نرسله وطريقة إرساله. يمكن أن يؤدي ذلك إلى تحسين كبير في تسهيل وصول المستخدمين إلى المواقع الإلكترونية على الشبكات الضعيفة. بالإضافة إلى مهام الخدمة، يمكننا إنشاء مواقع إلكترونية سريعة بشكلٍ لا يصدق وتكون متاحة بلا اتصال بالإنترنت.
على الرغم من أنّ نصائح العملاء لا تتوفّر إلا في Chrome ومتصفّحات Chrome المبنية على Chromium، من الممكن استخدامها بطريقة لا تؤثر في المتصفّحات التي لا تتوافق معها. ضع في اعتبارك استخدام تلميحات العميل لإنشاء تجارب شاملة وقابلة للتكيّف حقًا على دراية بإمكانات أجهزة كل مستخدم والشبكات التي يتصل بها. نأمل أن يدرك مورّدو المتصفّحات الآخرون قيمة هذه الميزات وأن يبدؤوا تنفيذها.
الموارد
- الصور المتجاوبة التلقائية مع تلميحات العميل
- ملاحظات العميل والصور المتجاوبة: التغييرات في الإصدار Chrome 67
- الحصول على تلميح (عميل) (العروض التقديمية من Google)
- تقديم تطبيقات سريعة وخفيفة باستخدام
Save-Data
نشكر إيليا غريغوريك وإريك بورتيس وجيف بوسنيك ويوآف وايس وإيستل وييل على مساهمتهم في تحسين هذه المقالة من خلال تقديم ملاحظاتهم وآراءهم المُهمة وإجراء التعديلات عليها.