توسعه سایت‌هایی که در همه‌جا سریع باشند می‌تواند چشم‌انداز دشواری باشد. تعداد زیاد قابلیت‌های دستگاه—و کیفیت شبکه‌هایی که به آن‌ها متصل می‌شوند—می‌تواند این کار را به‌نظر غیرقابل‌انجام جلوه دهد. درحالی‌که می‌توانیم از ویژگی‌های مرورگر برای بهبود عملکرد بارگیری استفاده کنیم، چگونه می‌توانیم بدانیم که دستگاه کاربر چه توانایی‌هایی دارد یا کیفیت اتصال شبکه او چگونه است؟ راه‌حل اشاره‌های کارخواه است!
اشاره‌های کارخواه مجموعه‌ای از سرایندهای درخواست اچ‌تی‌تی‌پی موافقت‌کردنی است که به ما اطلاعاتی درباره این جنبه‌های دستگاه کاربر و شبکه‌ای که به آن متصل است می‌دهد. با استفاده از این اطلاعات در سمت سرور، می‌توانیم نحوه ارائه محتوا را براساس شرایط دستگاه و/یا شبکه تغییر دهیم. این کار می‌تواند به ما کمک کند تا تجربه‌های کاربری فراگیرتری ایجاد کنیم.
همه چیز به مذاکره درباره محتوا مربوط می‌شود
اشاره‌های کارخواه روش دیگری برای مذاکره محتوا است، یعنی تغییر دادن پاسخ‌های محتوا براساس سرایندهای درخواست مرورگر.
یک نمونه از مذاکره محتوا شامل سرایند درخواست
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 در این مورد ۳۲۰×۲۴۰ است و اندازه ذاتی تصویر 2x ۶۴۰×۴۸۰ است. اگر این نشان‌گذاری توسط کارخواهی تجزیه شود که روی دستگاهی با نسبت پیکسل صفحه دستگاه ۲ (مثلاً صفحه Retina) نصب شده است، تصویر 2x درخواست می‌شود. اندازه ذاتی اصلاح‌شده ازنظر تراکم
تصویر 2x برابر با ۳۲۰×۲۴۰ است، زیرا ۶۴۰×۴۸۰ تقسیم بر ۲ برابر با ۳۲۰×۲۴۰ است.
اندازه بیرونی: اندازه منبع رسانه پس‌از اعمال CSS و سایر عوامل چیدمان (مانند مشخصه‌های width و height) بر آن. فرض کنید
عنصر <img> دارید که تصویری را با اندازه ذاتی اصلاح‌شده ازنظر تراکم
۳۲۰×۲۴۰ بار می‌کند، اما ویژگی‌های CSS width و height
با مقادیر 256px و 192px نیز به‌ترتیب روی آن اعمال شده است. در این مثال،
اندازه بیرونی آن عنصر <img> به ۲۵۶×۱۹۲ تبدیل می‌شود.
width: 256px;
و height: 192px; تصویر با اندازه ذاتی ۳۲۰×۲۴۰ را
به تصویر با اندازه بیرونی ۲۵۶×۱۹۲ تبدیل می‌کند.با داشتن برخی اصطلاحات، بیایید به فهرست اشاره‌های کارخواه مختص دستگاه که دردسترس شما است بپردازیم.
Viewport-Width
Viewport-Width عرض نمای کاربر در پیکسل‌های CSS است:
Viewport-Width: 320
این راهنمایی را می‌توان با راهنمایی‌های خاص صفحه‌نمایش دیگر استفاده کرد تا پردازش‌های مختلفی (یعنی برش‌ها) از تصویر ارائه شود که برای اندازه‌های خاص صفحه‌نمایش بهینه هستند (یعنی جهت هنری)، یا منابعی را که برای عرض فعلی صفحه‌نمایش غیرضروری هستند حذف کرد.
DPR
DPR، که مخفف نسبت پیکسل دستگاه است، نسبت پیکسل‌های فیزیکی به پیکسل‌های CSS صفحه‌نمایش کاربر را گزارش می‌کند:
DPR: 2
این راهنمایی هنگام انتخاب منابع تصویری که با
تراکم پیکسل صفحه‌نمایش مطابقت دارند مفید است (مانند کاری که توصیف‌کننده‌های x در srcset
مشخصه انجام می‌دهند).
عرض
نکته Width در درخواست‌های منابع تصویری که توسط برچسب‌های <img> یا <source> بااستفاده از مشخصه sizes ارسال می‌شوند، ظاهر می‌شود.
sizes به مرورگر می‌گوید اندازه بیرونی منبع چقدر خواهد بود؛
Width از آن اندازه بیرونی برای درخواست تصویری با اندازه درونی استفاده می‌کند که
برای چیدمان فعلی بهینه است.
برای مثال، فرض کنید کاربری صفحه‌ای با صفحه‌نمایش ۳۲۰ پیکسل CSS
با نسبت پیکسل دستگاه ۲ درخواست می‌کند. دستگاه سندی را با عنصر <img> بار می‌کند که حاوی
مقدار مشخصه sizes از 85vw است (یعنی، ۸۵٪ از عرض ناحیه نمایش برای همه
اندازه‌های صفحه‌نمایش). اگر راهنمایی Width انتخاب شده باشد، سرویس‌گیرنده این راهنمایی Width را همراه با درخواست src <img> به سرور ارسال خواهد کرد:
Width: 544
در این حالت، مشتری به سرور اشاره می‌کند که عرض ذاتی بهینه برای تصویر درخواستی ۸۵٪ عرض نمای هدف (۲۷۲ پیکسل) ضرب در DPR صفحه‌نمایش (۲) است که برابر با ۵۴۴ پیکسل می‌شود.
این راهنمایی به‌ویژه قدرتمند است زیرا نه تنها عرض تصحیح‌شده ازنظر تراکم صفحه‌نمایش را درنظر می‌گیرد، بلکه این اطلاعات مهم را با اندازه خارجی تصویر در چیدمان تطبیق می‌دهد. این کار به سرورها فرصت می‌دهد تا پاسخ‌های تصویری را که هم برای صفحه‌نمایش و هم برای چیدمان بهینه هستند، مذاکره کنند.
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 مقدار تقریبی
حافظه
دستگاه فعلی را به گیبی‌بایت نشان می‌دهد:
Device-Memory: 2
یک مورد استفاده احتمالی برای این راهنمایی، کاهش مقدار جاوا اسکریپت ارسال‌شده به مرورگرها در دستگاه‌های با حافظه محدود است، زیرا جاوا اسکریپت معمولاً پرمصرف‌ترین نوع محتوا ازنظر منابع است که مرورگرها بار می‌کنند. یا می‌توانید تصاویر با DPR پایین‌تر ارسال کنید چون برای رمزگشایی از حافظه کمتری استفاده می‌کنند.
نکات شبکه
Network Information API دسته دیگری از اشاره‌های کارخواه را ارائه می‌دهد که عملکرد اتصال شبکه کاربر را توصیف می‌کند. به نظر من، این‌ها مفیدترین مجموعه نکته‌ها هستند. بااستفاده از آن‌ها، می‌توانیم با تغییر نحوه ارائه منابع به مشتریان در اتصال‌های کند، تجربه‌ها را برای کاربران سفارشی‌سازی کنیم.
نوشتار هم‌زمان
نکته RTT زمان رفت‌وبرگشت تقریبی را به میلی‌ثانیه در لایه برنامه ارائه می‌دهد. نکته RTT، برخلاف RTT لایه انتقال، شامل
زمان پردازش سرور است.
RTT: 125
این نکته به‌دلیل نقشی که تأخیر در عملکرد بارگیری ایفا می‌کند مفید است.
بااستفاده از راهنمایی RTT، می‌توانیم براساس پاسخ‌گویی شبکه تصمیم‌گیری کنیم،
که می‌تواند به تسریع ارائه کل تجربه کمک کند (برای مثال، ازطریق
حذف برخی درخواست‌ها).
پیوند پایین‌دستی
درحالی‌که تأخیر در عملکرد بار کردن مهم است، پهنای باند نیز تأثیرگذار است. نکته Downlink که برحسب مگابیت در ثانیه (Mbps) بیان می‌شود،
سرعت پایین‌دست تقریبی اتصال کاربر را نشان می‌دهد:
Downlink: 2.5
در ارتباط با RTT، Downlink می‌تواند در تغییر نحوه ارائه محتوا به کاربران براساس کیفیت اتصال شبکه مفید باشد.
ECT
نکته 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."
/>
در این مثال، نشانی وب /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
استفاده می‌کند،
و مشاهده کرد که کاربران میانه هنگام استفاده از مرورگرهای
پشتیبانی‌کننده از اشاره‌های کارخواه، ۴۲٪ بایت کمتری بارگیری کردند.
اما مراقب باشید! تغییرات در نسخه رایانه‌ای Chrome 67 پشتیبانی از اشاره‌های کارخواه میان‌مبدئی را برداشته است. خوشبختانه این محدودیت‌ها بر نسخه‌های تلفن همراه Chrome تأثیر نمی‌گذارد و وقتی کار روی خط‌مشی ویژگی تکمیل شود، این محدودیت‌ها برای همه پلاتفرم‌ها برداشته خواهد شد.
کمک به کاربران در شبکه‌های کند
عملکرد تطبیقی ایده‌ای است که براساس آن می‌توانیم نحوه ارائه منابع را براساس اطلاعاتی که اشاره‌های کارخواه دراختیار ما قرار می‌دهد تنظیم کنیم؛ به‌ویژه اطلاعات مربوط به وضعیت فعلی اتصال شبکه کاربر.
درخصوص سایت Sconnie Timber، وقتی شبکه‌ها کند هستند، اقداماتی برای سبک کردن بار انجام می‌دهیم و سراینده‌های Save-Data، ECT، RTT، و Downlink را در کد پس‌بست خود بررسی می‌کنیم. وقتی این کار انجام شد، امتیاز کیفیت شبکه را تولید می‌کنیم که می‌توانیم از آن برای تعیین اینکه آیا باید برای تجربه کاربری بهتر مداخله کنیم یا نه استفاده کنیم. امتیاز این شبکه بین 0 و 1 است، که 0 بدترین کیفیت شبکه ممکن و 1 بهترین کیفیت است.
ابتدا بررسی می‌کنیم که آیا Save-Data وجود دارد یا نه. اگر این‌طور باشد، امتیاز روی
0 تنظیم می‌شود، زیرا فرض می‌کنیم کاربر می‌خواهد هر کاری لازم است انجام دهیم تا
تجربه سبک‌تر و سریع‌تر شود.
اما اگر Save-Data وجود نداشته باشد، سراغ مقادیر راهنمایی‌های ECT، RTT، و Downlink می‌رویم و آن‌ها را می‌سنجیم تا امتیازی را محاسبه کنیم که کیفیت اتصال شبکه را توصیف می‌کند. کد منبع تولید امتیاز شبکه در Github دردسترس است. نتیجه این است که اگر از نکات مربوط به شبکه به
نحوی استفاده کنیم، می‌توانیم تجربه‌ها را برای کسانی که در شبکه‌های کند هستند
بهتر کنیم.
وقتی سایت‌ها با اطلاعاتی که اشاره‌های کارخواه ارائه می‌دهد سازگار می‌شوند، مجبور نیستیم رویکرد «همه یا هیچ» را اتخاذ کنیم. می‌توانیم به‌طور هوشمندانه تصمیم بگیریم که کدام منابع را ارسال کنیم. می‌توانیم منطق انتخاب تصویر واکنش‌گرای خود را اصلاح کنیم تا تصاویر با کیفیت پایین‌تری را برای نمایشگر خاصی ارسال کنیم تا عملکرد بارگیری را در شرایطی که کیفیت شبکه ضعیف است تسریع کنیم.
در این مثال، می‌توانیم تأثیر اشاره‌های کارخواه را در بهبود عملکرد سایت‌ها در شبکه‌های کندتر ببینیم. در زیر، آبشار WebPagetest سایتی در شبکه کندی که با اشاره‌های کارخواه سازگار نمی‌شود نشان داده شده است:
و اکنون یک آبشار برای همان سایت در همان اتصال کند، با این تفاوت که این بار، سایت از اشاره‌های کارخواه برای حذف منابع غیرضروری صفحه استفاده می‌کند:
اشاره‌های کارخواه زمان بار کردن صفحه را از بیش‌از ۴۵ ثانیه به کمتر از یک‌دهم آن زمان کاهش داد. مزایای اشاره‌های کارخواه در این سناریو را نمی‌توان به‌اندازه کافی مورد تأکید قرار داد و می‌تواند کمک جدی به کاربرانی باشد که به‌دنبال اطلاعات مهم در شبکه‌های کند هستند.
علاوه‌براین، می‌توان از اشاره‌های کارخواه بدون خراب کردن تجربه
برای مرورگرهایی که از آن‌ها پشتیبانی نمی‌کنند استفاده کرد. برای مثال، اگر بخواهیم تحویل منبع را بااستفاده از مقدار راهنمایی 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
header در اینجا ضروری است، زیرا ورودی‌های حافظه نهان را به مقدار سرایندهای درخواست ارائه‌شده به آن کلید می‌کند. به‌بیان ساده، اگر پاسخی را براساس سرایند درخواست HTTP خاصی اصلاح می‌کنید، تقریباً همیشه باید آن سرایند درخواست را در Vary به‌صورت زیر اضافه کنید:
Vary: DPR, Width
البته یک هشدار بزرگ در این مورد وجود دارد: هرگز نباید پاسخ‌های قابل‌ذخیره در حافظه نهان را در سرصفحه‌ای که مکرراً تغییر می‌کند (مانند Cookie) Vary کنید، زیرا این منابع عملاً غیرقابل‌ذخیره در حافظه نهان می‌شوند. با دانستن این موضوع، شاید بخواهید از
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 خواند:
| اشاره کارخواه | معادل جاوااسکریپت |
|---|---|
| `ECT` | `navigator.connection.effectiveType` |
| `RTT` | `navigator.connection.rtt` |
| `Save-Data` | `navigator.connection.saveData` |
| `Downlink` | `navigator.connection.downlink` |
| `Device-Memory` | `navigator.deviceMemory` |
چون این API-ها در همه جا دردسترس نیستند، باید بااستفاده از عملگر
in
ویژگی را بررسی کنید:
if ('connection' in navigator) {
// Work with netinfo API properties in JavaScript!
}
از اینجا، می‌توانید از منطقی مشابه آنچه در سرور استفاده می‌کنید استفاده کنید، با این تفاوت که برای مذاکره درباره محتوا با اشاره‌های کارخواه به سرور نیاز ندارید. کارگران خدمات به‌تنهایی این قدرت را دارند که تجربه‌ها را سریع‌تر و انعطاف‌پذیرتر کنند، زیرا توانایی بیشتری برای ارائه محتوا در زمانی که کاربر آفلاین است دارند.
درحال جمع‌بندی
با اشاره‌های کارخواه، می‌توانیم تجربه‌ها را به‌طور کاملاً پیش‌رونده برای کاربران سریع‌تر کنیم. می‌توانیم رسانه را براساس قابلیت‌های دستگاه کاربر ارائه دهیم، به‌گونه‌ای که ارائه تصاویر واکنش‌گرا آسان‌تر از تکیه بر <picture> و srcset باشد، به‌ویژه برای موارد استفاده پیچیده. این کار به ما امکان می‌دهد
نه تنها زمان و تلاش را در بخش توسعه کاهش دهیم، بلکه منابع را نیز بهینه‌سازی کنیم—به‌ویژه تصاویر—به‌گونه‌ای که صفحه‌نمایش‌های کاربران را
به‌طور دقیق‌تر از آنچه
شاید مهم‌تر از همه این باشد که می‌توانیم اتصال‌های شبکه ضعیف را شناسایی کنیم و با اصلاح آنچه ارسال می‌کنیم و نحوه ارسال آن، این شکاف را برای کاربران پر کنیم. این کار می‌تواند کمک بسیاری به آسان‌تر شدن دسترسی به سایت‌ها برای کاربران در شبکه‌های ناپایدار کند. با ترکیب این دو، می‌توانیم سایت‌های بسیار سریعی ایجاد کنیم که به‌صورت آفلاین دردسترس هستند.
درحالی‌که اشاره‌های کارخواه فقط در Chrome و مرورگرهای مبتنی بر Chromium دردسترس است، می‌توان از آن‌ها به‌گونه‌ای استفاده کرد که مرورگرهایی را که از آن‌ها پشتیبانی نمی‌کنند دچار مشکل نکند. برای ایجاد تجربه‌های واقعاً فراگیر و سازگار که از قابلیت‌های دستگاه هر کاربر و شبکه‌هایی که به آن‌ها متصل می‌شوند آگاه هستند، از اشاره‌های کارخواه استفاده کنید. امیدواریم سایر فروشندگان مرورگر ارزش آن‌ها را ببینند و تمایل خود را برای پیاده‌سازی نشان دهند.
منابع
- تصاویر واکنش‌گرای خودکار با اشاره‌های کارخواه
- اشاره‌های کارخواه و تصاویر واکنش‌گرا—چه چیزی در Chrome 67 تغییر کرده است
- از «اشاره‌های کارخواه» استفاده کنید! (اسلایدنگار)
- ارائه برنامه‌های سریع و سبک با
Save-Data
از ایلیا گریگوریک، اریک پورتیس، جف پوزنیک، یوآو وایس، و استل ویل به‌خاطر بازخوردها و ویرایش‌های ارزشمندشان در این مقاله سپاس‌گزاریم.