سازگاری با کاربران با نکات مشتری

Jeremy Wagner

توسعه سایت‌هایی که در همه جا سریع باشند، می‌تواند یک چشم‌انداز دشوار باشد. فراوانی قابلیت‌های دستگاه‌ها - و کیفیت شبکه‌هایی که به آنها متصل می‌شوند - می‌تواند این کار را مانند یک کار غیرقابل انجام جلوه دهد. در حالی که می‌توانیم از ویژگی‌های مرورگر برای بهبود عملکرد بارگیری استفاده کنیم، چگونه می‌توانیم بدانیم که دستگاه کاربر چه قابلیت‌هایی دارد یا کیفیت اتصال شبکه او چگونه است؟ راه حل، نکات کلاینت است!

نکات مربوط به کلاینت، مجموعه‌ای از هدرهای درخواست HTTP هستند که به ما بینشی در مورد این جنبه‌های دستگاه کاربر و شبکه‌ای که به آن متصل است، می‌دهند. با دسترسی به این اطلاعات سمت سرور، می‌توانیم نحوه ارائه محتوا را بر اساس شرایط دستگاه و/یا شبکه تغییر دهیم. این می‌تواند به ما کمک کند تا تجربیات کاربری فراگیرتری ایجاد کنیم.

همه چیز درباره مذاکره محتوا

راهنمایی‌های کلاینت روش دیگری برای مذاکره محتوا است، که به معنی تغییر پاسخ‌های محتوا بر اساس هدرهای درخواست مرورگر است.

یک نمونه از مذاکره محتوا شامل هدر درخواست Accept است. این هدر نوع محتوایی را که مرورگر درک می‌کند و سرور می‌تواند از آن برای مذاکره در مورد پاسخ استفاده کند، شرح می‌دهد. برای درخواست‌های تصویر، محتوای هدر Accept کروم به صورت زیر است:

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 ، Client hint ها به طور جادویی ظاهر نمی‌شوند (به استثنای Save-Data که بعداً در مورد آن صحبت خواهیم کرد). برای اینکه هدرهای درخواست را به حداقل برسانید، باید با ارسال یک هدر Accept-CH هنگام درخواست منبع توسط کاربر، مشخص کنید که می‌خواهید کدام client hint ها را دریافت کنید:

Accept-CH: Viewport-Width, Downlink

مقدار Accept-CH فهرستی از نکات درخواستی است که با کاما از هم جدا شده‌اند و سایت در تعیین نتایج درخواست‌های بعدی منابع از آنها استفاده خواهد کرد. وقتی کلاینت این هدر را می‌خواند، به او گفته می‌شود که «این سایت نکات مربوط به Viewport-Width و Downlink کلاینت را می‌خواهد.» نگران خود نکات خاص نباشید. به زودی به آنها خواهیم پرداخت.

شما می‌توانید این هدرهای opt-in را در هر زبان back-end تنظیم کنید. برای مثال، می‌توان از تابع header در PHP استفاده کرد. حتی می‌توانید این هدرهای opt-in را با ویژگی http-equiv در یک تگ <meta> تنظیم کنید:

<meta http-equiv="Accept-CH" content="Viewport-Width, Downlink" />

تمام نکات مشتری!

نکات مربوط به کلاینت یکی از این دو مورد را توصیف می‌کنند: دستگاهی که کاربران شما، خب، از آن استفاده می‌کنند و شبکه‌ای که برای دسترسی به سایت شما از آن استفاده می‌کنند. بیایید به طور خلاصه تمام نکات موجود را بررسی کنیم.

نکات مربوط به دستگاه

برخی از نکات مربوط به کلاینت، ویژگی‌های دستگاه کاربر، معمولاً ویژگی‌های صفحه نمایش را توصیف می‌کنند. برخی از آنها می‌توانند به شما در انتخاب منبع رسانه بهینه برای صفحه نمایش کاربر کمک کنند، اما همه آنها لزوماً رسانه محور نیستند.

قبل از اینکه به این لیست بپردازیم، شاید یادگیری چند اصطلاح کلیدی که برای توصیف صفحه نمایش و وضوح تصویر استفاده می‌شوند مفید باشد:

اندازه ذاتی: ابعاد واقعی یک منبع رسانه‌ای. برای مثال، اگر تصویری را در فتوشاپ باز کنید، ابعاد نشان داده شده در کادر محاوره‌ای اندازه تصویر، اندازه ذاتی آن را توصیف می‌کنند.

اندازه ذاتی اصلاح‌شده با چگالی: ابعاد یک منبع رسانه‌ای پس از اصلاح چگالی پیکسل. این اندازه ذاتی تصویر تقسیم بر نسبت پیکسل دستگاه است. برای مثال، بیایید این نشانه‌گذاری را در نظر بگیریم:

<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 در این مورد ۳۲۰x۲۴۰ و اندازه ذاتی تصویر 2x برابر با ۶۴۰x۴۸۰ باشد. اگر این نشانه‌گذاری توسط کلاینتی که روی دستگاهی با نسبت پیکسل ۲ (مثلاً صفحه نمایش رتینا) نصب شده است، تجزیه شود، تصویر 2x درخواست می‌شود. اندازه ذاتی تصحیح‌شده با چگالی تصویر 2x برابر با ۳۲۰x۲۴۰ است، زیرا ۶۴۰x۴۸۰ تقسیم بر ۲ می‌شود ۳۲۰x۲۴۰.

اندازه بیرونی: اندازه یک منبع رسانه پس از اعمال CSS و سایر عوامل طرح‌بندی (مانند ویژگی‌های width و height ) بر روی آن. فرض کنید یک عنصر <img> دارید که تصویری با اندازه ذاتی اصلاح‌شده با چگالی 320x240 را بارگذاری می‌کند، اما همچنین دارای ویژگی‌های width و height CSS با مقادیر 256px و 192px است که به ترتیب بر روی آن اعمال شده است. در این مثال، اندازه بیرونی آن عنصر <img> به 256x192 تبدیل می‌شود.

با آشنایی با برخی اصطلاحات، بیایید به فهرست نکات مربوط به کلاینت‌های مخصوص دستگاه که در دسترس شما هستند، بپردازیم.

عرض-دیدگاه

Viewport-Width عرض نمای کاربر در پیکسل‌های CSS است:

Viewport-Width: 320

این راهنمایی می‌تواند به همراه سایر راهنمایی‌های مختص صفحه نمایش برای ارائه روش‌های مختلف (مثلاً برش‌ها) از یک تصویر که برای اندازه‌های خاص صفحه نمایش (مثلاً جهت هنری ) بهینه هستند، یا برای حذف منابعی که برای عرض فعلی صفحه نمایش غیرضروری هستند، استفاده شود.

دی پی آر

DPR ، مخفف عبارت device pixel ratio (نسبت پیکسل دستگاه)، نسبت پیکسل‌های فیزیکی به پیکسل‌های CSS صفحه نمایش کاربر را گزارش می‌دهد:

DPR: 2

این نکته هنگام انتخاب منابع تصویری که با تراکم پیکسلی صفحه نمایش مطابقت دارند (مانند توصیفگرهای x در ویژگی srcset ) مفید است.

عرض

اشاره‌گر Width در درخواست‌های مربوط به منابع تصویری که توسط تگ‌های <img> یا <source> با استفاده از ویژگی sizes ارسال می‌شوند، ظاهر می‌شود. sizes به مرورگر می‌گوید که اندازه بیرونی منبع چقدر خواهد بود؛ Width از آن اندازه بیرونی برای درخواست تصویری با اندازه ذاتی که برای طرح‌بندی فعلی بهینه است، استفاده می‌کند.

برای مثال، فرض کنید کاربری صفحه‌ای با عرض ۳۲۰ پیکسل CSS و DPR برابر با ۲ درخواست می‌کند. دستگاه سندی را با عنصر <img> که حاوی مقدار ویژگی sizes برابر با 85vw (یعنی ۸۵٪ از عرض viewport برای همه اندازه‌های صفحه نمایش) است، بارگذاری می‌کند. اگر اشاره‌گر Width hint) انتخاب شده باشد، کلاینت این اشاره‌گر Width را به همراه درخواست src مربوط به <img> به سرور ارسال می‌کند:

Width: 544

در این حالت، کلاینت به سرور اطلاع می‌دهد که عرض ذاتی بهینه برای تصویر درخواستی، ۸۵٪ از عرض نمایشگر (۲۷۲ پیکسل) ضربدر DPR صفحه نمایش (۲) است که برابر با ۵۴۴ پیکسل می‌شود.

این نکته به ویژه قدرتمند است زیرا نه تنها عرض تصحیح شده با چگالی صفحه نمایش را در نظر می‌گیرد، بلکه این بخش مهم از اطلاعات را با اندازه بیرونی تصویر در طرح‌بندی نیز تطبیق می‌دهد. این به سرورها این فرصت را می‌دهد تا پاسخ‌های تصویری را که هم برای صفحه نمایش و هم برای طرح‌بندی بهینه هستند، مذاکره کنند.

محتوا-DPR

در حالی که شما از قبل می‌دانید که صفحه نمایش‌ها نسبت پیکسلی دستگاه دارند، منابع نیز نسبت پیکسلی خاص خود را دارند. در ساده‌ترین موارد استفاده از انتخاب منبع، نسبت پیکسل بین دستگاه‌ها و منابع می‌تواند یکسان باشد. اما! در مواردی که هر دو هدر DPR و Width در کار هستند، اندازه بیرونی یک منبع می‌تواند سناریوهایی را ایجاد کند که در آن‌ها این دو متفاوت باشند. اینجاست که اشاره به Content-DPR وارد عمل می‌شود.

برخلاف سایر نکات کلاینت، Content-DPR یک هدر درخواست نیست که توسط سرورها استفاده شود، بلکه یک هدر پاسخ است که سرورها باید هر زمان که از نکات DPR و Width برای انتخاب یک منبع استفاده می‌شود، ارسال کنند. مقدار Content-DPR باید نتیجه این معادله باشد:

Content-DPR = [اندازه منبع تصویر انتخاب شده] / ([ Width ] / [ DPR ])

وقتی یک هدر درخواست Content-DPR ارسال می‌شود، مرورگر می‌داند که چگونه تصویر داده شده را برای نسبت پیکسل دستگاه صفحه نمایش و طرح‌بندی مقیاس‌بندی کند. بدون آن، تصاویر ممکن است به درستی مقیاس‌بندی نشوند.

حافظه دستگاه

از نظر فنی، Device-Memory که بخشی از رابط برنامه‌نویسی کاربردی حافظه دستگاه است ، مقدار تقریبی حافظه دستگاه فعلی را بر حسب گیگابایت نشان می‌دهد:

Device-Memory: 2

یک کاربرد احتمالی این نکته می‌تواند کاهش میزان جاوا اسکریپت ارسالی به مرورگرها در دستگاه‌هایی با حافظه محدود باشد، زیرا جاوا اسکریپت پرمصرف‌ترین نوع محتوایی است که مرورگرها معمولاً بارگذاری می‌کنند . یا می‌توانید تصاویر با DPR پایین‌تر ارسال کنید زیرا از حافظه کمتری برای رمزگشایی استفاده می‌کنند.

نکات شبکه

API اطلاعات شبکه، دسته دیگری از نکات مربوط به کلاینت را ارائه می‌دهد که عملکرد اتصال شبکه کاربر را توصیف می‌کند. به نظر من، این‌ها مفیدترین مجموعه نکات هستند. با آن‌ها، ما می‌توانیم با تغییر نحوه ارائه منابع به کلاینت‌ها در اتصالات کند، تجربیات را متناسب با کاربران تنظیم کنیم.

آر تی تی

راهنمای RTT زمان تقریبی رفت و برگشت (Round Trip Time ) را بر حسب میلی‌ثانیه در لایه کاربرد ارائه می‌دهد. راهنمای RTT ، برخلاف RTT لایه انتقال، شامل زمان پردازش سرور نیز می‌شود.

RTT: 125

این نکته به دلیل نقشی که تأخیر در عملکرد بارگذاری ایفا می‌کند، مفید است. با استفاده از نکته RTT ، می‌توانیم بر اساس پاسخگویی شبکه تصمیم‌گیری کنیم که می‌تواند به سرعت بخشیدن به ارائه کل یک تجربه (مثلاً از طریق حذف برخی درخواست‌ها) کمک کند.

داون‌لینک

اگرچه تأخیر در عملکرد بارگذاری مهم است، پهنای باند نیز تأثیرگذار است. اشاره به Downlink که بر حسب مگابیت در ثانیه (Mbps) بیان می‌شود، سرعت تقریبی دانلود اتصال کاربر را نشان می‌دهد:

Downlink: 2.5

در کنار RTT ، Downlink می‌تواند در تغییر نحوه ارائه محتوا به کاربران بر اساس کیفیت اتصال شبکه مفید باشد.

الکتروشوک درمانی

اشاره ECT مخفف عبارت Effective Connection Type (نوع اتصال مؤثر) است. مقدار آن یکی از لیست‌های شمارش‌شده‌ی انواع اتصال است که هر کدام یک اتصال را در محدوده‌های مشخص‌شده‌ای از مقادیر RTT و Downlink توصیف می‌کنند.

این هدر نوع اتصال واقعی را توضیح نمی‌دهد - برای مثال، گزارش نمی‌دهد که آیا دروازه شما یک برج سلولی است یا یک نقطه دسترسی وای‌فای. در عوض، تأخیر و پهنای باند اتصال فعلی را تجزیه و تحلیل می‌کند و تعیین می‌کند که بیشتر به کدام پروفایل شبکه شباهت دارد. برای مثال، اگر از طریق وای‌فای به یک شبکه کند متصل شوید، ECT ممکن است با مقدار 2g پر شود که نزدیکترین تقریب به اتصال مؤثر است:

ECT: 2g

مقادیر معتبر برای ECT عبارتند از 4g ، 3g ، 2g و slow-2g . این راهنما می‌تواند به عنوان نقطه شروع برای ارزیابی کیفیت اتصال استفاده شود و متعاقباً با استفاده از راهنماهای RTT و Downlink اصلاح شود.

ذخیره داده

Save-Data بیش از آنکه صرفاً یک راهنما برای توصیف شرایط شبکه باشد، ترجیح کاربر است که بیان می‌کند صفحات باید داده‌های کمتری ارسال کنند.

من ترجیح می‌دهم Save-Data به عنوان یک راهنمای شبکه طبقه‌بندی کنم، زیرا بسیاری از کارهایی که با آن انجام می‌دهید مشابه سایر راهنمای‌های شبکه است. همچنین ممکن است کاربران در محیط‌های با تأخیر بالا/پهنای باند کم، آن را فعال کنند. این راهنمای شبکه، در صورت وجود، همیشه به این شکل است:

Save-Data: on

ما در گوگل در مورد کارهایی که می‌توانید با Save-Data انجام دهید صحبت کرده‌ایم . تأثیر آن بر عملکرد می‌تواند عمیق باشد. این سیگنالی است که کاربران از شما می‌خواهند محتوای کمتری برایشان ارسال کنید! اگر به این سیگنال گوش دهید و عمل کنید، کاربران از آن قدردانی خواهند کرد.

همه چیز را به هم گره زدن

اینکه با Client hints چه می‌کنید به خودتان بستگی دارد. از آنجایی که اطلاعات زیادی ارائه می‌دهند، گزینه‌های زیادی دارید. برای اینکه ایده‌هایتان به جریان بیفتد، بیایید ببینیم Client hints چه کاری می‌تواند برای Sconnie Timber ، یک شرکت چوب‌بری خیالی واقع در مناطق روستایی Upper Midwest، انجام دهد. همانطور که اغلب در مناطق دورافتاده اتفاق می‌افتد ، اتصالات شبکه می‌توانند شکننده باشند. اینجاست که فناوری مانند Client hints واقعاً می‌تواند برای کاربران تفاوت ایجاد کند.

تصاویر واکنش‌گرا

تقریباً همه موارد استفاده از تصاویر واکنش‌گرا، به جز ساده‌ترین آنها، می‌توانند پیچیده شوند. اگر چندین نوع تصویر برای اندازه‌های مختلف صفحه نمایش و فرمت‌های مختلف داشته باشید، چه می‌شود؟ این نشانه‌گذاری خیلی سریع پیچیده می‌شود. به راحتی می‌توان در آن اشتباه کرد و مفاهیم مهم (مانند sizes ) را به راحتی فراموش کرد یا نفهمید.

اگرچه <picture> و srcset ابزارهای فوق‌العاده‌ای هستند، اما توسعه و نگهداری آنها برای موارد استفاده پیچیده می‌تواند زمان‌بر باشد. ما می‌توانیم تولید نشانه‌گذاری را خودکار کنیم، اما انجام این کار نیز دشوار است زیرا عملکردی که <picture> و srcset ارائه می‌دهند به اندازه کافی پیچیده است که خودکارسازی آنها باید به گونه‌ای انجام شود که انعطاف‌پذیری ارائه شده توسط آنها حفظ شود.

نکات مشتری می‌تواند این کار را ساده کند. مذاکره در مورد پاسخ‌های تصویر با نکات مشتری می‌تواند چیزی شبیه به این باشد:

1. در صورت لزوم، ابتدا با بررسی گزینه Viewport-Width ، یک روش پردازش تصویر (یعنی تصاویر هنری) را انتخاب کنید.
2. با بررسی راهنمای عرض Width hint) و راهنمای 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."
/>

در این مثال، آدرس اینترنتی /image یک اسکریپت PHP است که به دنبال آن پارامترهایی توسط mod_rewrite بازنویسی می‌شوند. این آدرس یک نام فایل تصویر و پارامترهای اضافی را دریافت می‌کند تا به اسکریپت back-end کمک کند تا بهترین تصویر را در شرایط داده شده انتخاب کند.

حس می‌کنم اولین سوال شما این است که «مگر این فقط پیاده‌سازی مجدد <picture> و srcset در back-end نیست؟»

از یک جهت، بله—اما با یک تمایز مهم: وقتی یک برنامه از نکات کلاینت برای ایجاد پاسخ‌های رسانه‌ای استفاده می‌کند، خودکارسازی بیشتر (اگر نگوییم همه) کار بسیار آسان‌تر است، که می‌تواند شامل سرویسی (مانند CDN) باشد که می‌تواند این کار را از طرف شما انجام دهد. در حالی که با راه‌حل‌های HTML، باید نشانه‌گذاری جدیدی نوشته شود تا برای هر مورد استفاده فراهم شود. مطمئناً، می‌توانید تولید نشانه‌گذاری را خودکار کنید. با این حال، اگر طراحی یا الزامات شما تغییر کند، احتمال زیادی وجود دارد که در آینده نیاز به بازنگری استراتژی اتوماسیون خود داشته باشید.

Client hints این امکان را فراهم می‌کنند که با یک تصویر بدون افت کیفیت و با وضوح بالا شروع کنید که سپس می‌تواند به صورت پویا تغییر اندازه دهد تا برای هر ترکیبی از صفحه نمایش و طرح‌بندی بهینه باشد. برخلاف srcset که شما را ملزم به برشمردن لیست ثابتی از تصاویر کاندید ممکن برای انتخاب مرورگر می‌کند، این رویکرد می‌تواند انعطاف‌پذیرتر باشد. در حالی که srcset شما را مجبور می‌کند مجموعه‌ای تقریبی از انواع مختلف - مثلاً 256w ، 512w ، 768w و 1024w - را به مرورگرها ارائه دهید، یک راه‌حل مبتنی بر client hints می‌تواند بدون حجم زیادی از markup، تمام عرض‌ها را پوشش دهد.

البته، لازم نیست خودتان منطق انتخاب تصویر را بنویسید. Cloudinary هنگام استفاده از پارامتر w_auto از client hints برای ایجاد پاسخ‌های تصویر استفاده می‌کند و مشاهده کرده است که کاربران به طور متوسط ​​هنگام استفاده از مرورگرهایی که از client hints پشتیبانی می‌کنند، ۴۲٪ بایت کمتری دانلود می‌کنند.

اما مراقب باشید! تغییرات در نسخه دسکتاپ کروم ۶۷، پشتیبانی از cross-origin client hints را حذف کرده است . خوشبختانه، این محدودیت‌ها بر نسخه‌های موبایل کروم تأثیری ندارند و پس از اتمام کار بر روی Feature Policy ، این محدودیت‌ها برای همه پلتفرم‌ها به طور کامل برداشته خواهند شد.

کمک به کاربران در شبکه‌های کند

عملکرد تطبیقی ​​ایده‌ای است که ما می‌توانیم نحوه ارائه منابع را بر اساس اطلاعاتی که کلاینت هاینت در اختیار ما قرار می‌دهد، تنظیم کنیم؛ به طور خاص اطلاعات مربوط به وضعیت فعلی اتصال شبکه کاربر.

در مورد سایت Sconnie Timber، ما اقداماتی را برای کاهش بار شبکه در مواقع کندی انجام می‌دهیم و هدرهای Save-Data ، ECT ، RTT و Downlink را در کد back-end خود بررسی می‌کنیم. وقتی این کار انجام شد، یک امتیاز کیفیت شبکه ایجاد می‌کنیم که می‌توانیم از آن برای تعیین اینکه آیا باید برای تجربه کاربری بهتر مداخله کنیم یا خیر، استفاده کنیم. این امتیاز شبکه بین 0 و 1 است که 0 بدترین کیفیت ممکن شبکه و 1 بهترین کیفیت ممکن است.

در ابتدا، بررسی می‌کنیم که آیا Save-Data وجود دارد یا خیر. اگر وجود داشته باشد، امتیاز آن روی 0 تنظیم می‌شود، زیرا فرض می‌کنیم کاربر می‌خواهد هر کاری که لازم است انجام دهیم تا تجربه‌ی کاربری سبک‌تر و سریع‌تر شود.

با این حال، اگر Save-Data وجود نداشته باشد، به سراغ نکات ECT ، RTT و Downlink می‌رویم و آن‌ها را وزن می‌کنیم تا امتیازی را محاسبه کنیم که کیفیت اتصال شبکه را توصیف می‌کند. کد منبع تولید امتیاز شبکه در Github موجود است. نکته‌ی مهم این است که اگر به نحوی از نکات مربوط به شبکه استفاده کنیم، می‌توانیم تجربه‌ی بهتری را برای کسانی که از شبکه‌های کند استفاده می‌کنند، فراهم کنیم.

وقتی سایت‌ها با اطلاعاتی که کلاینت ارائه می‌دهد سازگار می‌شوند، لازم نیست رویکرد «همه یا هیچ» را اتخاذ کنیم. می‌توانیم هوشمندانه تصمیم بگیریم کدام منابع را ارسال کنیم. می‌توانیم منطق انتخاب تصویر واکنش‌گرای خود را طوری تغییر دهیم که تصاویر با کیفیت پایین‌تری را برای یک نمایشگر مشخص ارسال کند تا سرعت بارگذاری در زمانی که کیفیت شبکه پایین است، افزایش یابد.

در این مثال، می‌توانیم تأثیر client hints را در بهبود عملکرد سایت‌ها در شبکه‌های کندتر ببینیم. در زیر، نمودار آبشاری WebPagetest از سایتی روی شبکه کند که با client hints سازگار نمی‌شود، آمده است:

و حالا یک آبشار برای همان سایت با همان اتصال کند، با این تفاوت که این بار، سایت از نکات کلاینت برای حذف منابع غیر حیاتی صفحه استفاده می‌کند:

نکات کلاینت زمان بارگذاری صفحه را از بیش از ۴۵ ثانیه به کمتر از یک دهم آن زمان کاهش داد. مزایای نکات کلاینت در این سناریو به اندازه کافی قابل تأکید نیست و می‌تواند برای کاربرانی که به دنبال اطلاعات حیاتی از طریق شبکه‌های کند هستند، یک مزیت جدی باشد.

علاوه بر این، می‌توان از نکات کلاینت بدون ایجاد اختلال در تجربه مرورگرهایی که از آنها پشتیبانی نمی‌کنند، استفاده کرد. برای مثال، اگر بخواهیم تحویل منابع را با توجه به مقدار نکته ECT تنظیم کنیم و در عین حال تجربه کامل را برای مرورگرهایی که از آنها پشتیبانی نمی‌کنند، ارائه دهیم، می‌توانیم مانند زیر، مقدار پیش‌فرض را تنظیم کنیم:

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

در اینجا، "4g" نشان دهنده بالاترین کیفیت اتصال شبکه است که هدر ECT آن را توصیف می‌کند. اگر مقدار اولیه $ect روی "4g" قرار دهیم، مرورگرهایی که از client hints پشتیبانی نمی‌کنند، تحت تأثیر قرار نمی‌گیرند. Opt-in FTW!

به اون انبارها توجه کن!

هر زمان که پاسخی را بر اساس یک هدر HTTP تغییر می‌دهید، باید از نحوه مدیریت واکشی‌های آینده برای آن منبع توسط کش‌ها آگاه باشید. هدر Vary در اینجا ضروری است، زیرا ورودی‌های کش را به مقدار هدرهای درخواست ارائه شده به آن کلید می‌زند. به عبارت ساده، اگر هر پاسخی را بر اساس یک هدر درخواست HTTP مشخص تغییر می‌دهید، تقریباً همیشه باید هدر request that را در Vary به صورت زیر وارد کنید:

Vary: DPR, Width

با این حال، یک نکته‌ی مهم وجود دارد: شما هرگز نمی‌خواهید پاسخ‌های قابل Vary در حافظه‌ی نهان را روی یک هدر که مرتباً در حال تغییر است (مانند Cookie ) تغییر دهید، زیرا این منابع عملاً غیرقابل ذخیره می‌شوند. با دانستن این موضوع، ممکن است بخواهید Vary در هدرهای راهنمای کلاینت مانند RTT یا Downlink خودداری کنید، زیرا این‌ها عوامل اتصالی هستند که می‌توانند مرتباً تغییر کنند. اگر می‌خواهید پاسخ‌ها را روی آن هدرها تغییر دهید، فقط هدر ECT را کلیدگذاری کنید، که باعث می‌شود خطاهای حافظه‌ی نهان به حداقل برسد.

البته، این فقط در صورتی صدق می‌کند که شما در وهله اول یک پاسخ را ذخیره کنید. برای مثال، اگر محتوای HTML پویا باشد، آن را ذخیره نمی‌کنید، زیرا این امر می‌تواند تجربه کاربر را در بازدیدهای مکرر خراب کند. در مواردی مانند این، می‌توانید چنین پاسخ‌هایی را بر اساس هر مبنایی که احساس می‌کنید لازم است تغییر دهید و نگران Vary نباشید.

نکات مشتری در مورد سرویس ورکرها

مذاکره محتوا دیگر فقط برای سرورها نیست! از آنجا که سرویس ورکرها به عنوان پروکسی بین کلاینت‌ها و سرورها عمل می‌کنند، شما می‌توانید بر نحوه تحویل منابع از طریق جاوا اسکریپت کنترل داشته باشید. این شامل نکات مربوط به کلاینت نیز می‌شود. در رویداد 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!
    })(),
  );
});

هر هدر راهنمای کلاینت که انتخاب می‌کنید، می‌تواند به این روش خوانده شود. اگرچه این تنها راهی نیست که می‌توانید برخی از این اطلاعات را دریافت کنید. راهنماهای مختص شبکه را می‌توان در این ویژگی‌های معادل جاوا اسکریپت در شیء navigator خواند:

از آنجا که این APIها همه جا در دسترس نیستند، برای بررسی ویژگی‌ها باید از عملگر in استفاده کنید:

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

از اینجا، می‌توانید از منطقی مشابه آنچه در سرور استفاده می‌کنید، استفاده کنید، با این تفاوت که برای انتقال محتوا با نکات کلاینت به سرور نیازی ندارید. سرویس ورکرها به تنهایی قدرت دارند تا تجربیات را سریع‌تر و انعطاف‌پذیرتر کنند، زیرا توانایی بیشتری در ارائه محتوا در زمانی که کاربر آفلاین است، دارند.

جمع‌بندی

با راهنمایی‌های کلاینت، ما این قدرت را داریم که تجربه‌ها را برای کاربران به روشی کاملاً مترقی سریع‌تر کنیم. ما می‌توانیم رسانه‌ها را بر اساس قابلیت‌های دستگاه کاربر به گونه‌ای ارائه دهیم که ارائه تصاویر واکنش‌گرا آسان‌تر از تکیه بر <picture> و srcset باشد، به خصوص برای موارد استفاده پیچیده. این امر ما را قادر می‌سازد تا نه تنها زمان و تلاش را در سمت توسعه کاهش دهیم، بلکه منابع - به ویژه تصاویر - را به گونه‌ای بهینه کنیم که صفحه نمایش کاربر را دقیق‌تر از ... هدف قرار دهد. و srcset می‌تواند.

شاید مهم‌تر از آن، بتوانیم اتصالات شبکه ضعیف را تشخیص دهیم و با تغییر آنچه ارسال می‌کنیم و نحوه ارسال آن، شکاف را برای کاربران پر کنیم. این می‌تواند در آسان‌تر کردن دسترسی کاربران به سایت‌ها در شبکه‌های شکننده بسیار مؤثر باشد. در ترکیب با سرویس ورکرها، می‌توانیم سایت‌های فوق‌العاده سریعی ایجاد کنیم که به صورت آفلاین در دسترس هستند.

اگرچه نکات مربوط به کلاینت فقط در کروم و مرورگرهای مبتنی بر کرومیوم در دسترس هستند، اما می‌توان از آنها به گونه‌ای استفاده کرد که مرورگرهایی که از آنها پشتیبانی نمی‌کنند را دچار مشکل نکند. استفاده از نکات مربوط به کلاینت را برای ایجاد تجربیات واقعاً فراگیر و سازگار که از قابلیت‌های دستگاه هر کاربر و شبکه‌هایی که به آنها متصل می‌شوند آگاه هستند، در نظر بگیرید. امیدواریم سایر فروشندگان مرورگر ارزش آنها را ببینند و قصد پیاده‌سازی آنها را نشان دهند.

منابع

• تصاویر واکنش‌گرای خودکار با راهنمایی‌های کلاینت
• نکات کلاینت و تصاویر واکنش‌گرا - چه چیزی در کروم ۶۷ تغییر کرده است؟
• به یک نکته (مشتری) توجه کنید! ( اسلایدها )
• ارائه برنامه‌های سریع و سبک با Save-Data

با تشکر از ایلیا گریگوریک ، اریک پورتیس ، جف پوسنیک ، یوآو وایس و استل وایل برای بازخوردها و ویرایش‌های ارزشمندشان در مورد این مقاله.