ساختن برای وب به شما دسترسی بی نظیری می دهد. برنامه وب شما با یک کلیک فاصله دارد و تقریباً در هر دستگاه متصل مانند تلفن هوشمند، تبلت، لپ تاپ و دسکتاپ، تلویزیون و موارد دیگر بدون در نظر گرفتن مارک یا پلتفرم موجود است. برای ارائه بهترین تجربه، سایتی ریسپانسیو ساخته‌اید که ارائه و عملکرد را برای هر فرم فاکتور تطبیق می‌دهد، و اکنون چک لیست عملکرد خود را برای اطمینان از بارگیری هرچه سریع‌تر برنامه اجرا می‌کنید: شما خود را بهینه کرده‌اید. در مسیر رندر بحرانی ، شما منابع متنی خود را فشرده و کش کرده اید، و اکنون به منابع تصویر خود نگاه می کنید، که اغلب اکثر بایت های منتقل شده را تشکیل می دهند. مشکل این است که بهینه سازی تصویر سخت است :
- فرمت مناسب را تعیین کنید (بردار در مقابل شطرنجی)
- فرمت های کدگذاری بهینه (jpeg، webp و غیره) را تعیین کنید.
- تنظیمات فشرده سازی مناسب را تعیین کنید (تلفات در مقابل بدون اتلاف)
- تعیین کنید که کدام ابرداده باید نگهداری یا حذف شود
- برای هر نمایشگر + رزولوشن DPR انواع مختلفی از هر کدام ایجاد کنید
- ...
- نوع شبکه، سرعت و تنظیمات برگزیده کاربر را در نظر بگیرید
به طور جداگانه، این مشکلات به خوبی درک شده است. در مجموع، آنها فضای بهینه سازی بزرگی را ایجاد می کنند که ما (توسعه دهندگان) اغلب از آن غافل می شویم یا از آن غفلت می کنیم. انسان‌ها در جستجوی مکرر همان فضای جستجو، کار ضعیفی انجام می‌دهند، مخصوصاً زمانی که مراحل زیادی درگیر باشد. از سوی دیگر رایانه ها در این نوع کارها عالی هستند.
پاسخ به یک استراتژی بهینه سازی خوب و پایدار برای تصاویر و سایر منابع با ویژگی های مشابه ساده است: اتوماسیون. اگر منابع خود را دستی تنظیم می کنید، اشتباه انجام می دهید: فراموش می کنید، تنبل می شوید یا شخص دیگری این اشتباهات را برای شما انجام می دهد - تضمینی.
حماسه توسعه دهنده آگاه به عملکرد
جستجو در فضای بهینه سازی تصویر دارای دو مرحله مجزا است: زمان ساخت و زمان اجرا.
- برخی از بهینه سازی ها ذاتی خود منبع هستند - به عنوان مثال انتخاب فرمت مناسب و نوع رمزگذاری، تنظیم تنظیمات فشرده سازی برای هر رمزگذار، حذف ابرداده های غیر ضروری و غیره. این مراحل را می توان در «زمان ساخت» انجام داد.
- سایر بهینه سازی ها بر اساس نوع و ویژگی های مشتری درخواست کننده تعیین می شوند و باید در "زمان اجرا" انجام شوند: انتخاب منبع مناسب برای DPR مشتری و عرض نمایش مورد نظر، محاسبه سرعت شبکه مشتری، اولویت های کاربر و برنامه، و غیره. بر.
ابزار زمان ساخت وجود دارد اما می‌توان آن را بهتر کرد. به عنوان مثال، با تنظیم پویا تنظیمات "کیفیت" برای هر تصویر و هر فرمت تصویر، صرفه جویی زیادی وجود دارد، اما من هنوز ندیده ام که کسی واقعاً از آن خارج از تحقیق استفاده کند. این منطقه برای نوآوری آماده است، اما برای اهداف این پست من آن را در همین جا می گذارم. بیایید روی بخش زمان اجرا داستان تمرکز کنیم.
<img src="/image/thing" sizes="50vw"
alt="image thing displayed at 50% of viewport width">
هدف برنامه بسیار ساده است: واکشی و نمایش تصویر در 50٪ از نمای کاربر. اینجا جایی است که اکثر طراحان دست‌های خود را می‌شویند و به سمت بار می‌روند. در همین حال، برنامه‌نویس آگاه به عملکرد تیم، شبی طولانی را در پیش دارد:
- برای دریافت بهترین فشرده‌سازی، او می‌خواهد از فرمت تصویر بهینه برای هر مشتری استفاده کند: WebP برای Chrome، JPEG XR برای Edge، و JPEG برای بقیه.
- برای به دست آوردن بهترین کیفیت بصری، او باید چندین گونه از هر تصویر را با وضوح های مختلف تولید کند: 1x، 1.5x، 2x، 2.5x، 3x، و شاید حتی چند نوع دیگر در این بین.
- برای جلوگیری از ارائه پیکسل‌های غیرضروری، او باید بفهمد که "50% نمای کاربر در واقع به چه معناست" - عرض‌های مختلف ویوپورت زیادی وجود دارد!
- در حالت ایده‌آل، او همچنین می‌خواهد تجربه‌ای انعطاف‌پذیر ارائه دهد که در آن کاربران در شبکه‌های کندتر به‌طور خودکار وضوح پایین‌تری دریافت می‌کنند. پس از همه، همه چیز در مورد زمان شیشه است.
- این برنامه همچنین برخی از کنترل‌های کاربر را در معرض نمایش می‌گذارد که بر منبع تصویری که باید واکشی شود تأثیر می‌گذارد، بنابراین باید این کنترل‌ها را نیز در نظر گرفت.
اوه، و سپس طراح متوجه می شود که برای بهینه سازی خوانایی، باید تصویر متفاوتی را با عرض 100% نمایش دهد. این بدان معناست که اکنون باید همان فرآیند را برای یک دارایی دیگر تکرار کنیم و سپس واکشی را مشروط به اندازه viewport کنیم. آیا من اشاره کردم این چیزها سخت است؟ خوب، بیایید به آن برسیم. عنصر picture ما را خیلی دور می برد :
<picture>
<!-- serve WebP to Chrome and Opera -->
<source
media="(min-width: 50em)"
sizes="50vw"
srcset="/image/thing-200.webp 200w, /image/thing-400.webp 400w,
/image/thing-800.webp 800w, /image/thing-1200.webp 1200w,
/image/thing-1600.webp 1600w, /image/thing-2000.webp 2000w"
type="image/webp">
<source
sizes="(min-width: 30em) 100vw"
srcset="/image/thing-crop-200.webp 200w, /image/thing-crop-400.webp 400w,
/image/thing-crop-800.webp 800w, /image/thing-crop-1200.webp 1200w,
/image/thing-crop-1600.webp 1600w, /image/thing-crop-2000.webp 2000w"
type="image/webp">
<!-- serve JPEGXR to Edge -->
<source
media="(min-width: 50em)"
sizes="50vw"
srcset="/image/thing-200.jpgxr 200w, /image/thing-400.jpgxr 400w,
/image/thing-800.jpgxr 800w, /image/thing-1200.jpgxr 1200w,
/image/thing-1600.jpgxr 1600w, /image/thing-2000.jpgxr 2000w"
type="image/vnd.ms-photo">
<source
sizes="(min-width: 30em) 100vw"
srcset="/image/thing-crop-200.jpgxr 200w, /image/thing-crop-400.jpgxr 400w,
/image/thing-crop-800.jpgxr 800w, /image/thing-crop-1200.jpgxr 1200w,
/image/thing-crop-1600.jpgxr 1600w, /image/thing-crop-2000.jpgxr 2000w"
type="image/vnd.ms-photo">
<!-- serve JPEG to others -->
<source
media="(min-width: 50em)"
sizes="50vw"
srcset="/image/thing-200.jpg 200w, /image/thing-400.jpg 400w,
/image/thing-800.jpg 800w, /image/thing-1200.jpg 1200w,
/image/thing-1600.jpg 1600w, /image/thing-2000.jpg 2000w">
<source
sizes="(min-width: 30em) 100vw"
srcset="/image/thing-crop-200.jpg 200w, /image/thing-crop-400.jpg 400w,
/image/thing-crop-800.jpg 800w, /image/thing-crop-1200.jpg 1200w,
/image/thing-crop-1600.jpg 1600w, /image/thing-crop-2000.jpg 2000w">
<!-- fallback for browsers that don't support picture -->
<img src="/image/thing.jpg" width="50%">
</picture>
ما جهت هنری، انتخاب قالب، و شش نوع از هر تصویر را برای در نظر گرفتن تنوع در DPR و عرض نمای دستگاه مشتری ارائه کرده‌ایم. چشمگیر!
متأسفانه، عنصر picture به ما اجازه نمی دهد تا بر اساس نوع اتصال یا سرعت مشتری، قوانینی را برای نحوه رفتار آن تعریف کنیم. با این حال، الگوریتم پردازش آن به عامل کاربر اجازه می‌دهد تا در برخی موارد، چه منبعی را واکشی می‌کند، تنظیم کند - مرحله 5 را ببینید. فقط باید امیدوار باشیم که عامل کاربر به اندازه کافی هوشمند باشد. (توجه: هیچ یک از پیاده سازی های فعلی وجود ندارد). به طور مشابه، هیچ قلابی در عنصر picture وجود ندارد تا منطق خاص برنامه را که تنظیمات برگزیده برنامه یا کاربر را به حساب می آورد، اجازه دهد. برای دریافت این دو بیت آخر، باید تمام منطق بالا را به جاوا اسکریپت منتقل کنیم، اما این بهینه سازی های اسکنر پیش بارگذاری ارائه شده توسط picture را از دست می دهد. هوم
این محدودیت ها به کنار، کار می کند. خوب، حداقل برای این دارایی خاص. چالش واقعی و بلندمدت در اینجا این است که نمی‌توانیم از طراح یا توسعه‌دهنده انتظار داشته باشیم که برای تک تک دارایی‌ها، چنین کدی را ایجاد کند. این یک پازل مغزی سرگرم کننده در اولین تلاش است، اما بلافاصله پس از آن جذابیت خود را از دست می دهد. ما به اتوماسیون نیاز داریم. شاید IDE یا سایر ابزارهای تبدیل محتوا بتواند ما را نجات دهد و به طور خودکار صفحه دیگ بالا را تولید کند.
انتخاب خودکار منابع با نکات مشتری
نفس عمیق بکشید، ناباوری خود را به حالت تعلیق درآورید و اکنون به مثال زیر توجه کنید:
<meta http-equiv="Accept-CH" content="DPR, Viewport-Width, Width">
...
<picture>
<source media="(min-width: 50em)" sizes="50vw" srcset="/image/thing">
<img sizes="100vw" src="/image/thing-crop">
</picture>
باور کنید یا نه، مثال بالا برای ارائه همه قابلیت‌های مشابه نشانه‌گذاری تصویر بسیار طولانی‌تر در بالا کافی است، به علاوه، همانطور که خواهیم دید، کنترل کامل توسعه‌دهنده را بر نحوه، کدام و زمان واکشی منابع تصویر ممکن می‌سازد. "جادو" در خط اول است که گزارش نکات مشتری را فعال می کند و به مرورگر می گوید نسبت پیکسل دستگاه ( DPR )، عرض درگاه دید طرح بندی ( Viewport-Width ) و عرض نمایش در نظر گرفته شده ( Width ) منابع را تبلیغ کند. سرور.
با فعال کردن نکات مشتری، نشانه‌گذاری سمت مشتری حاصل فقط الزامات ارائه را حفظ می‌کند . طراح نیازی به نگرانی در مورد انواع تصویر، وضوح مشتری، نقاط شکست بهینه برای کاهش بایت های تحویلی یا سایر معیارهای انتخاب منبع ندارد. بیایید با آن روبرو شویم، آنها هرگز این کار را نکردند و نباید مجبور شوند. بهتر است، توسعه‌دهنده نیازی به بازنویسی و گسترش نشانه‌گذاری بالا نداشته باشد زیرا انتخاب منبع واقعی توسط مشتری و سرور مذاکره می‌شود.
Chrome 46 از نکات DPR ، Width و Viewport-Width پشتیبانی می‌کند. راهنمایی‌ها به‌طور پیش‌فرض غیرفعال هستند و <meta http-equiv="Accept-CH" content="..."> بالا به‌عنوان یک سیگنال انتخابی عمل می‌کند که به Chrome می‌گوید سرصفحه‌های مشخص‌شده را به درخواست‌های خروجی اضافه کند. با وجود آن، اجازه دهید سرفصل های درخواست و پاسخ را برای یک درخواست تصویر نمونه بررسی کنیم:
Chrome پشتیبانی خود را از قالب WebP از طریق سرصفحه پذیرش درخواست تبلیغ می کند. مرورگر جدید Edge به طور مشابه پشتیبانی از JPEG XR را از طریق هدر Accept تبلیغ می کند.
سه هدر درخواست بعدی عبارتند از هدرهای اشاره مشتری که نسبت پیکسل دستگاه دستگاه مشتری (3x)، عرض نمای طرح (460 پیکسل) و عرض صفحه نمایش مورد نظر منبع (230 پیکسل) را تبلیغ می کنند. این همه اطلاعات لازم را در اختیار سرور قرار می دهد تا نوع تصویر بهینه را بر اساس مجموعه سیاست های خود انتخاب کند: در دسترس بودن منابع از پیش تولید شده، هزینه رمزگذاری مجدد یا تغییر اندازه یک منبع، محبوبیت یک منبع، بارگذاری فعلی سرور، و غیره. . در این مورد خاص، سرور از نکات DPR و Width استفاده می‌کند و یک منبع WebP را برمی‌گرداند، همانطور که توسط هدرهای Content-Type ، Content-DPR و Vary نشان داده شده است.
اینجا جادویی نیست. ما انتخاب منبع را از نشانه گذاری HTML و به مذاکره درخواست-پاسخ بین مشتری و سرور منتقل کردیم. در نتیجه، HTML فقط به الزامات ارائه مربوط می شود و چیزی است که ما می توانیم به هر طراح و توسعه دهنده ای برای نوشتن آن اعتماد کنیم، در حالی که جستجو در فضای بهینه سازی تصویر به رایانه ها موکول شده و اکنون به راحتی در مقیاس خودکار می شود. توسعه دهنده آگاه به عملکرد ما را به خاطر دارید؟ کار او اکنون نوشتن یک سرویس تصویری است که بتواند از نکات ارائه شده استفاده کند و پاسخ مناسب را ارائه دهد: او می تواند از هر زبان یا سروری که دوست دارد استفاده کند، یا اجازه دهد یک سرویس شخص ثالث یا یک CDN این کار را از طرف او انجام دهد.
<img src="/image/thing" sizes="50vw"
alt="image thing displayed at 50% of viewport width">
همچنین، این مرد بالا را به یاد دارید؟ با اشاره های مشتری، برچسب تصویر فروتن اکنون بدون هیچ نشانه گذاری اضافی، DPR-، viewport- و عرض است. اگر نیاز به افزودن جهت هنری دارید، می‌توانید از تگ picture استفاده کنید، همانطور که در بالا نشان دادیم، و در غیر این صورت، تمام برچسب‌های تصویر موجود شما بسیار هوشمندتر شده‌اند. نکات مشتری عناصر img و picture موجود را تقویت می کند.
کنترل انتخاب منابع با کارگر خدمات
ServiceWorker در واقع یک پروکسی سمت سرویس گیرنده است که در مرورگر شما اجرا می شود. تمام درخواست های خروجی را رهگیری می کند و به شما امکان می دهد پاسخ ها را بازرسی، بازنویسی، حافظه پنهان و حتی ترکیب کنید. تصاویر تفاوتی ندارند و با فعال کردن نکات مشتری، ServiceWorker فعال می تواند درخواست های تصویر را شناسایی کند، نکات مشتری ارائه شده را بررسی کند و منطق پردازش خود را تعریف کند.
self.onfetch = function(event) {
var req = event.request.clone();
console.log("SW received request for: " + req.url)
for (var entry of req.headers.entries()) {
console.log("\t" + entry[0] +": " + entry[1])
}
...
}
ServiceWorker به شما کنترل کامل سمت مشتری بر انتخاب منابع را می دهد . این مهم است. اجازه دهید آن غرق شود، زیرا احتمالات تقریباً بی نهایت هستند:
- می توانید مقادیر هدر نکات مشتری را که توسط عامل کاربر تنظیم شده است، بازنویسی کنید.
- می توانید مقادیر سرصفحه نکات مشتری جدید را به درخواست اضافه کنید.
- شما می توانید URL را بازنویسی کنید و درخواست تصویر را در یک سرور جایگزین (مثلا CDN) قرار دهید.
- حتی می‌توانید مقادیر اشاره را از سرصفحه‌ها و به خود URL منتقل کنید، اگر این کار استقرار کارها را در زیرساخت شما آسان‌تر می‌کند.
- شما می‌توانید پاسخ‌ها را در حافظه پنهان ذخیره کنید و منطق خود را تعریف کنید که منابع برای آن سرو می‌شوند.
- شما می توانید پاسخ خود را بر اساس اتصال کاربران تطبیق دهید.
- شما می توانید از NetInfo API برای پرس و جو و تبلیغ ترجیحات خود در سرور استفاده کنید .
- اگر واکشی کند است، می‌توانید یک پاسخ جایگزین برگردانید.
- می‌توانید برنامه‌ها و اولویت‌های کاربر را لغو کنید.
- شما می توانید … هر کاری که دلتان می خواهد، واقعاً انجام دهید.
عنصر picture ، کنترل جهت هنری لازم را در نشانه گذاری HTML فراهم می کند. نکات کلاینت حاشیه‌نویسی‌هایی را در مورد درخواست‌های تصویری به‌دست‌آمده ارائه می‌دهد که اتوماسیون انتخاب منابع را فعال می‌کند. ServiceWorker قابلیت های مدیریت درخواست و پاسخ را بر روی مشتری فراهم می کند. این وب توسعه پذیر در عمل است.
مشتری به سوالات متداول اشاره می کند
نکات مشتری کجا در دسترس است؟ در Chrome 46 ارسال شد. در حال بررسی در فایرفاکس و اج .
چرا نکات مشتری شرکت می کنند؟ ما می خواهیم هزینه های اضافی را برای سایت هایی که از نکات مشتری استفاده نمی کنند، به حداقل برسانیم. برای فعال کردن نکات مشتری، سایت باید هدر
Accept-CHیا دستورالعمل معادل<meta http-equiv>را در نشانه گذاری صفحه ارائه دهد. با هر یک از افراد حاضر، عامل کاربر نکات مناسب را به تمام درخواست‌های منبع فرعی اضافه می‌کند. در آینده، ممکن است یک مکانیسم اضافی برای تداوم این اولویت برای یک مبدأ خاص ارائه دهیم، که اجازه می‌دهد همان نکات در درخواست‌های ناوبری ارائه شود.اگر ServiceWorker داریم چرا به راهنمایی های مشتری نیاز داریم؟ ServiceWorker به اطلاعات چیدمان، منبع و عرض دید دسترسی ندارد. حداقل، بدون معرفی رفت و برگشت پرهزینه و تأخیر قابل توجه درخواست تصویر - به عنوان مثال زمانی که یک درخواست تصویر توسط تجزیه کننده پیش بارگذاری آغاز می شود. نکات مشتری با مرورگر ادغام می شود تا این داده ها به عنوان بخشی از درخواست در دسترس باشد.
آیا نکات مشتری فقط برای منابع تصویر است؟ مورد اصلی استفاده از نکات DPR، Viewport-Width و Width فعال کردن انتخاب منبع برای دارایی های تصویر است. با این حال، نکات یکسان برای همه منابع فرعی بدون در نظر گرفتن نوع ارائه می شود - به عنوان مثال درخواست های CSS و جاوا اسکریپت نیز اطلاعات یکسانی را دریافت می کنند و می توانند برای بهینه سازی آن منابع نیز استفاده شوند.
برخی از درخواست‌های تصویر Width را گزارش نمی‌کنند، چرا؟ مرورگر ممکن است عرض نمایش مورد نظر را نداند زیرا سایت به اندازه ذاتی تصویر متکی است. در نتیجه، اشاره Width برای چنین درخواست‌هایی حذف می‌شود و برای درخواست‌هایی که "عرض نمایش" ندارند - به عنوان مثال یک منبع جاوا اسکریپت. برای دریافت نکات عرض، مطمئن شوید که مقدار اندازه را روی تصاویر خود مشخص کنید.
در مورد <درج راهنمایی مورد علاقه من> چیست؟ ServiceWorker توسعه دهندگان را قادر می سازد تا تمام درخواست های خروجی را رهگیری و تغییر دهند (به عنوان مثال اضافه کردن سرصفحه های جدید). به عنوان مثال، اضافه کردن اطلاعات مبتنی بر NetInfo برای نشان دادن نوع اتصال فعلی آسان است - به " گزارش قابلیت با ServiceWorker " مراجعه کنید. نکات "بومی" ارسال شده در کروم (DPR، Width، Resource-Width) در مرورگر پیاده سازی می شوند زیرا اجرای خالص مبتنی بر SW همه درخواست های تصویر را به تاخیر می اندازد.
از کجا می توانم بیشتر بیاموزم، دموهای بیشتری را ببینم، و چطور؟ سند توضیح‌دهنده را بررسی کنید و اگر بازخورد یا سؤال دیگری دارید ، مشکلی را در GitHub باز کنید .