قد يكون تطوير مواقع إلكترونية سريعة في كل مكان أمرًا صعبًا. إنّ كثرة إمكانات الأجهزة وجودة الشبكات التي تتصل بها قد تجعل هذه المهمة تبدو مستحيلة. على الرغم من أنّه يمكننا الاستفادة من ميزات المتصفّح لتحسين أداء التحميل، كيف يمكننا معرفة إمكانات جهاز المستخدم أو جودة اتصاله بالشبكة؟ الحلّ هو حقول معلومات العميل.
تلميحات العميل هي مجموعة من عناوين طلبات 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، ولكنّه يتضمّن أيضًا السمتَين width وheight في CSS مع تطبيق القيمتَين 256px و192px عليه على التوالي. في هذا المثال،
يصبح الحجم الخارجي لعنصر <img> هو 256x192.
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، سيرسل العميل
تلميح Width هذا إلى الخادم مع طلب src لـ <img>:
Width: 544
في هذه الحالة، يلمّح العميل إلى الخادم بأنّ العرض الأساسي الأمثل للصورة المطلوبة سيكون %85 من عرض إطار العرض (272 بكسل) مضروبًا في نسبة كثافة بكسل الشاشة (2)، أي ما يعادل 544 بكسل.
هذا التلميح فعّال بشكل خاص لأنّه لا يأخذ في الاعتبار فقط العرض المصحَّح للكثافة على الشاشة، بل يوفّق أيضًا بين هذه المعلومة المهمة والحجم الخارجي للصورة ضمن التنسيق. ويتيح ذلك للخوادم التفاوض بشأن ردود الصور التي تكون مثالية لكل من الشاشة والتنسيق.
Content-DPR
للشاشات نسبة وحدات بكسل على الجهاز، وللموارد أيضًا
نسب وحدات بكسل خاصة بها. في أبسط حالات استخدام اختيار الموارد، يمكن أن تكون نِسب البكسل بين الأجهزة والموارد متطابقة. ولكن! في الحالات التي يتم فيها استخدام كل من الرأسَين DPR وWidth، يمكن أن يؤدي الحجم الخارجي للمورد إلى سيناريوهات يختلف فيها الرأسان. هنا يأتي دور تلميح Content-DPR.
على عكس تلميحات العميل الأخرى، لا يُعدّ Content-DPR عنوان طلب تستخدمه الخوادم، بل هو عنوان استجابة يجب أن ترسله الخوادم كلما تم استخدام تلميحَي DPR وWidth لاختيار مورد. يجب أن تكون قيمة Content-DPR
نتيجة هذه المعادلة:
Content-DPR = [حجم مورد الصورة المحدّدة] / ([Width] / [DPR])
عند إرسال عنوان الطلب Content-DPR، سيعرف المتصفّح كيفية تغيير حجم الصورة المحدّدة لتناسب نسبة بكسل الجهاز في الشاشة والتنسيق. بدونها، قد لا يتم تغيير حجم الصور بشكل صحيح.
Device-Memory
يُعدّ Device-Memory جزءًا من واجهة برمجة التطبيقات Device Memory، ويكشف عن مقدار الذاكرة التقريبي المتوفّر في الجهاز الحالي بوحدة غيبي بايت:
Device-Memory: 2
من حالات الاستخدام المحتملة لهذا التلميح تقليل كمية JavaScript التي يتم إرسالها إلى المتصفحات على الأجهزة ذات الذاكرة المحدودة، لأنّ JavaScript هو نوع المحتوى الأكثر استهلاكًا للموارد والذي تحمّله المتصفحات عادةً. أو يمكنك إرسال صور بنسبة DPR أقل لأنّها تستخدم ذاكرة أقل لفك الترميز.
تلميحات الشبكة
توفّر واجهة برمجة التطبيقات Network Information API فئة أخرى من حقول معلومات العميل التي تصف أداء اتصال شبكة المستخدم. في رأيي، هذه هي مجموعة التلميحات الأكثر فائدة. من خلالها، يمكننا تخصيص التجارب للمستخدمين من خلال تغيير طريقة تقديم الموارد للعملاء الذين لديهم اتصالات بطيئة.
مراسلة نصية في الوقت الفعلي
يوفّر تلميح RTT قيمة تقريبية للوقت المستغرَق في الرحلة ذهابًا وعودة بالمللي ثانية على طبقة التطبيقات. على عكس وقت الاستجابة في طبقة النقل، يتضمّن تلميح RTT وقت معالجة الخادم.
RTT: 125
هذا التلميح مفيد بسبب الدور الذي يلعبه وقت الاستجابة في أداء التحميل.
باستخدام تلميح RTT، يمكننا اتخاذ قرارات استنادًا إلى مدى استجابة الشبكة، ما يساعد في تسريع تقديم تجربة كاملة (مثلاً، من خلال حذف بعض الطلبات).
رابط التنزيل
على الرغم من أنّ وقت الاستجابة مهم في أداء التحميل، فإنّ معدّل نقل البيانات له تأثير أيضًا. يكشف تلميح Downlink، الذي يتم التعبير عنه بالميغابت في الثانية (Mbps)، عن سرعة الاتصال التقريبية للمستخدم:
Downlink: 2.5
بالتزامن مع 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 تلميحًا يصف حالة الشبكة، بل هو خيار مفضّل للمستخدم يشير إلى أنّ الصفحات يجب أن ترسل بيانات أقل.
أفضّل تصنيف 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 في الخلفية؟"
In a way, yes—but with an important distinction: when an application uses client hints to craft media responses, most (if not all) of the work is much easier to automate, which can include a service (such as a CDN) that can do this on your behalf. بينما في حلول 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. ويشمل ذلك حقول معلومات العميل. في حدث 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!
})(),
);
});
يمكن قراءة أي حقل معلومات عميل تختاره بهذه الطريقة. ومع ذلك، هذه ليست الطريقة الوحيدة التي يمكنك من خلالها الحصول على بعض هذه المعلومات. يمكن قراءة التلميحات الخاصة بالشبكة في سمات 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 والمتصفّحات المستندة إلى Chromium، يمكن استخدامها بطريقة لا تؤثر سلبًا في المتصفّحات التي لا تتيحها. ننصحك باستخدام حقول معلومات العميل لإنشاء تجارب شاملة وقابلة للتكيّف مع إمكانات أجهزة المستخدمين والشبكات التي يتصلون بها. نأمل أن يدرك مورّدو المتصفّحات الأخرى قيمة هذه الميزات وأن يُظهروا نية تنفيذها.
الموارد
- الصور المتجاوبة التلقائية مع تلميحات العميل
- حقول معلومات العميل والصور المتجاوبة: التغييرات في الإصدار 67 من Chrome
- التعرّف على حقول معلومات العميل (العروض التقديمية من Google)
- تقديم تطبيقات سريعة وخفيفة باستخدام
Save-Data
نشكر كلاً من إيليا غريغوريك وإريك بورتيس وجيف بوسنيك ويواف فايس وإستيل وايل على ملاحظاتهم القيّمة وتعديلاتهم على هذه المقالة.