این صفحه به‌وسیله ‏Cloud Translation API‏ ترجمه شده است.

انتخاب خودکار منابع با نکات مشتری

Ilya Grigorik

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

فرمت مناسب را تعیین کنید (بردار در مقابل شطرنجی)
فرمت های کدگذاری بهینه (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 باز کنید .

Ilya Grigorik

فرمت مناسب را تعیین کنید (بردار در مقابل شطرنجی)
فرمت های کدگذاری بهینه (jpeg، webp و غیره) را تعیین کنید.
تنظیمات فشرده سازی مناسب را تعیین کنید (تلفات در مقابل بدون اتلاف)
تعیین کنید که کدام ابرداده باید نگهداری یا حذف شود
برای هر نمایشگر + رزولوشن DPR انواع مختلفی از هر کدام ایجاد کنید
...
نوع شبکه، سرعت و تنظیمات برگزیده کاربر را در نظر بگیرید

حماسه توسعه دهنده آگاه به عملکرد

جستجو در فضای بهینه سازی تصویر دارای دو مرحله مجزا است: زمان ساخت و زمان اجرا.

برخی از بهینه سازی ها ذاتی خود منبع هستند - به عنوان مثال انتخاب فرمت مناسب و نوع رمزگذاری، تنظیم تنظیمات فشرده سازی برای هر رمزگذار، حذف ابرداده های غیر ضروری و غیره. این مراحل را می توان در «زمان ساخت» انجام داد.
سایر بهینه‌سازی‌ها بر اساس نوع و ویژگی‌های مشتری درخواست‌کننده تعیین می‌شوند و باید در «زمان اجرا» انجام شوند: انتخاب منبع مناسب برای DPR مشتری و عرض نمایش مورد نظر، محاسبه سرعت شبکه مشتری، اولویت‌های کاربر و برنامه، و غیره.

<img src="/image/thing" sizes="50vw"
        alt="image thing displayed at 50% of viewport width">

برای دریافت بهترین فشرده‌سازی، او می‌خواهد از فرمت تصویر بهینه برای هر مشتری استفاده کند: WebP برای Chrome، JPEG XR برای Edge، و JPEG برای بقیه.
برای به دست آوردن بهترین کیفیت بصری، او باید چندین گونه از هر تصویر را با وضوح های مختلف تولید کند: 1x، 1.5x، 2x، 2.5x، 3x، و شاید حتی چند نوع دیگر در این بین.
برای جلوگیری از ارائه پیکسل‌های غیرضروری، او باید بفهمد که "50% نمای کاربر در واقع به چه معناست" - عرض‌های مختلف ویوپورت زیادی وجود دارد!
در حالت ایده‌آل، او همچنین می‌خواهد تجربه‌ای انعطاف‌پذیر ارائه دهد که در آن کاربران در شبکه‌های کندتر به‌طور خودکار وضوح پایین‌تری دریافت می‌کنند. پس از همه، همه چیز در مورد زمان شیشه است.
این برنامه همچنین برخی از کنترل‌های کاربر را در معرض نمایش می‌گذارد که بر منبع تصویری که باید واکشی شود تأثیر می‌گذارد، بنابراین باید این کنترل‌ها را نیز در نظر گرفت.

<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>

انتخاب خودکار منابع با نکات مشتری

نفس عمیق بکشید، ناباوری خود را به حالت تعلیق درآورید و اکنون به مثال زیر توجه کنید:

<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>

<img src="/image/thing" sizes="50vw"
        alt="image thing displayed at 50% of viewport width">

کنترل انتخاب منابع با کارگر خدمات

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])
    }
    ...
}

می توانید مقادیر هدر نکات مشتری را که توسط عامل کاربر تنظیم شده است، بازنویسی کنید.
می توانید مقادیر سرصفحه نکات مشتری جدید را به درخواست اضافه کنید.
شما می توانید URL را بازنویسی کنید و درخواست تصویر را در یک سرور جایگزین (مثلا CDN) قرار دهید.
- حتی می‌توانید مقادیر اشاره را از سرصفحه‌ها و به خود URL منتقل کنید، اگر این کار استقرار کارها را در زیرساخت شما آسان‌تر می‌کند.
شما می‌توانید پاسخ‌ها را در حافظه پنهان ذخیره کنید و منطق خود را تعریف کنید که منابع برای آن سرو می‌شوند.
شما می توانید پاسخ خود را بر اساس اتصال کاربران تطبیق دهید.
- شما می توانید از NetInfo API برای پرس و جو و تبلیغ ترجیحات خود در سرور استفاده کنید .
- اگر واکشی کند است، می‌توانید یک پاسخ جایگزین برگردانید.
می‌توانید برنامه‌ها و اولویت‌های کاربر را لغو کنید.
شما می توانید … هر کاری که دلتان می خواهد، واقعاً انجام دهید.

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

نکات مشتری کجا در دسترس است؟ در 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 باز کنید .

Ilya Grigorik

فرمت مناسب را تعیین کنید (بردار در مقابل شطرنجی)
فرمت های کدگذاری بهینه (jpeg، webp و غیره) را تعیین کنید.
تنظیمات فشرده سازی مناسب را تعیین کنید (تلفات در مقابل بدون اتلاف)
تعیین کنید که کدام ابرداده باید نگهداری یا حذف شود
برای هر نمایشگر + رزولوشن DPR انواع مختلفی از هر کدام ایجاد کنید
...
نوع شبکه، سرعت و تنظیمات برگزیده کاربر را در نظر بگیرید

حماسه توسعه دهنده آگاه به عملکرد

جستجو در فضای بهینه سازی تصویر دارای دو مرحله مجزا است: زمان ساخت و زمان اجرا.

برخی از بهینه سازی ها ذاتی خود منبع هستند - به عنوان مثال انتخاب فرمت مناسب و نوع رمزگذاری، تنظیم تنظیمات فشرده سازی برای هر رمزگذار، حذف ابرداده های غیر ضروری و غیره. این مراحل را می توان در «زمان ساخت» انجام داد.
سایر بهینه‌سازی‌ها بر اساس نوع و ویژگی‌های مشتری درخواست‌کننده تعیین می‌شوند و باید در «زمان اجرا» انجام شوند: انتخاب منبع مناسب برای DPR مشتری و عرض نمایش مورد نظر، محاسبه سرعت شبکه مشتری، اولویت‌های کاربر و برنامه، و غیره.

<img src="/image/thing" sizes="50vw"
        alt="image thing displayed at 50% of viewport width">

برای دریافت بهترین فشرده‌سازی، او می‌خواهد از فرمت تصویر بهینه برای هر مشتری استفاده کند: WebP برای Chrome، JPEG XR برای Edge، و JPEG برای بقیه.
برای به دست آوردن بهترین کیفیت بصری، او باید چندین گونه از هر تصویر را با وضوح های مختلف تولید کند: 1x، 1.5x، 2x، 2.5x، 3x، و شاید حتی چند نوع دیگر در این بین.
برای جلوگیری از ارائه پیکسل‌های غیرضروری، او باید بفهمد که "50% نمای کاربر در واقع به چه معناست" - عرض‌های مختلف ویوپورت زیادی وجود دارد!
در حالت ایده‌آل، او همچنین می‌خواهد تجربه‌ای انعطاف‌پذیر ارائه دهد که در آن کاربران در شبکه‌های کندتر به‌طور خودکار وضوح پایین‌تری دریافت می‌کنند. پس از همه، همه چیز در مورد زمان شیشه است.
این برنامه همچنین برخی از کنترل‌های کاربر را در معرض نمایش می‌گذارد که بر منبع تصویری که باید واکشی شود تأثیر می‌گذارد، بنابراین باید این کنترل‌ها را نیز در نظر گرفت.

<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>

متأسفانه ، عنصر picture به ما اجازه نمی دهد هر قانونی را برای نحوه رفتار آن بر اساس نوع اتصال یا سرعت اتصال مشتری تعریف کنیم. گفته می شود ، الگوریتم پردازش آن به نماینده کاربر این امکان را می دهد تا در بعضی موارد چه منبعی را تنظیم کند - مرحله 5 را ببینید. ما فقط باید امیدوار باشیم که نماینده کاربر به اندازه کافی هوشمند باشد. (توجه: هیچ یک از پیاده سازی های فعلی). به همین ترتیب ، هیچ قلاب در عنصر picture وجود ندارد که بتواند منطق خاص برنامه را برای تنظیم برنامه ها یا تنظیمات کاربر فراهم کند. برای به دست آوردن این دو بیت آخر ، ما باید تمام منطق فوق را به JavaScript منتقل کنیم ، اما این بهینه سازی های اسکنر پیش بار را که توسط 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 پشتیبانی خود را از فرمت وب از طریق عنوان Accept Request تبلیغ می کند. مرورگر Edge New به طور مشابه پشتیبانی JPEG XR را از طریق هدر پذیرش تبلیغ می کند.

سه هدر درخواست بعدی هدر مشتری ها هستند که نسبت پیکسل دستگاه (3X) ، عرض نمای طرح (460px) و عرض صفحه نمایش در نظر گرفته شده از منبع (230px) ، نسبت پیکسل دستگاه (3X) ، و عرض نمایشگر در نظر گرفته شده است. این کلیه اطلاعات لازم را به سرور ارائه می دهد تا نوع تصویر بهینه را بر اساس مجموعه خط مشی های خاص خود انتخاب کند: در دسترس بودن منابع از پیش تولید شده ، هزینه رمزگذاری مجدد یا تغییر اندازه یک منبع ، محبوبیت یک منبع ، بار فعلی سرور و غیره. در این مورد خاص ، سرور از نکات DPR و Width استفاده می کند و یک منبع وب را باز می گرداند ، همانطور که توسط Content-Type ، Content-DPR و هدر های Vary نشان داده شده است.

اینجا هیچ جادویی وجود ندارد. ما انتخاب منابع را از HTML Markup و به مذاکره پاسخ درخواست بین مشتری و سرور منتقل کردیم. در نتیجه ، HTML فقط به الزامات ارائه مربوط می شود و چیزی است که می توانیم به هر طراح و توسعه دهنده ای برای نوشتن اعتماد کنیم ، در حالی که جستجو از طریق فضای بهینه سازی تصویر به رایانه ها معطل می شود و اکنون به راحتی در مقیاس خودکار است. توسعه دهنده آگاه از عملکرد ما را به خاطر می آورید؟ کار او اکنون نوشتن یک سرویس تصویری است که می تواند نکات ارائه شده را به دست آورد و پاسخ مناسب را برگرداند: او می تواند از هر زبانی یا سرور مورد علاقه خود استفاده کند ، یا اجازه دهید یک سرویس شخص ثالث یا یک CDN از طرف خود این کار را انجام دهد.

<img src="/image/thing" sizes="50vw"
        alt="image thing displayed at 50% of viewport width">

همچنین ، این مرد را در بالا به یاد دارید؟ با نکات مشتری ، برچسب تصویر فروتن اکنون DPR- ، Viewport- و عرض آگاه و بدون هیچ نشانه اضافی است. اگر نیاز به اضافه کردن مسیر هنری دارید می توانید از برچسب picture استفاده کنید ، همانطور که در بالا نشان دادیم ، و در غیر این صورت تمام برچسب های تصویر موجود شما بسیار باهوش تر شدند. نکات مشتری باعث تقویت عناصر img و picture موجود می شود.

کنترل بر انتخاب منابع با کارگر سرویس

سرویس دهنده ، در واقع ، یک پروکسی سمت مشتری در مرورگر شما است. این همه درخواست های خروجی را رهگیری می کند و به شما امکان می دهد تا پاسخ ها را بازرسی ، بازنویسی ، حافظه پنهان و حتی سنتز کنید. تصاویر فرقی نمی کنند و با استفاده از نکات مشتری ، سرویس دهنده فعال می تواند درخواست های تصویر را شناسایی کند ، نکات مشتری ارائه شده را بازرسی کند و منطق پردازش خاص خود را تعریف کند.

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 کنترل کامل سمت مشتری را در انتخاب منابع به شما می دهد . این مهم است. بگذارید این غرق شود ، زیرا امکانات تقریباً بی نهایت است:

می توانید مقادیر هدر مشتری را که توسط نماینده کاربر تنظیم شده است ، بازنویسی کنید.
می توانید مقادیر جدید Hains Headers را به درخواست اضافه کنید.
می توانید URL را بازنویسی کرده و درخواست تصویر را در یک سرور جایگزین (به عنوان مثال CDN) نشان دهید.
- حتی اگر این کار را در زیرساخت های خود آسانتر می کند ، می توانید مقادیر اشاره را از هدر و به URL منتقل کنید.
شما می توانید پاسخ ها را ذخیره کرده و منطق خود را تعریف کنید که برای آن منابع ارائه می شود.
می توانید پاسخ خود را بر اساس اتصال کاربران تطبیق دهید.
- می توانید از API NetInfo برای پرس و جو و تبلیغ تنظیمات برگزیده خود به سرور استفاده کنید .
- اگر واکشی کند باشد می توانید یک پاسخ متناوب را برگردانید.
می توانید برای برنامه و ترجیح کاربر بیش از حد حساب کنید.
شما می توانید ... هر کاری که قلب شما بخواهد انجام دهد ، واقعاً.

عنصر picture ، کنترل جهت گیری لازم را در نشانه HTML فراهم می کند. نکات مشتری در مورد درخواست های تصویر حاصل از آن که اتوماسیون انتخاب منابع را فعال می کند ، حاشیه نویسی را ارائه می دهد. Service Worker قابلیت های مدیریت درخواست و پاسخ را برای مشتری فراهم می کند. این وب گسترده در عمل است.

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

نکات مشتری از کجا موجود است؟ حمل شده در کروم 46 . مورد بررسی در Firefox و Edge .
چرا مشتری نکات انتخابی است؟ ما می خواهیم برای سایتهایی که از نکات مشتری استفاده نمی کنند ، سربار را به حداقل برسانیم. برای فعال کردن نکات مشتری ، سایت باید هدر Accept-CH یا معادل <meta http-equiv> را در نشانه صفحه ارائه دهد. با وجود هر یک از این شرکت ها ، نماینده کاربر نکات مناسب را به کلیه درخواست های Subresource اضافه می کند. در آینده ، ما ممکن است یک مکانیسم اضافی برای ادامه این اولویت برای یک منشأ خاص فراهم کنیم ، که به همان نکات ارائه شده در درخواست های ناوبری اجازه می دهد.
چرا در صورت داشتن کارگر سرویس به نکات مشتری نیاز داریم؟ Service Worker به اطلاعات چیدمان ، منابع و عرض نمای دسترسی دسترسی ندارد. حداقل ، بدون معرفی میزهای پر هزینه و تأخیر قابل توجهی در درخواست تصویر - به عنوان مثال وقتی درخواست تصویر توسط Preload Parser آغاز می شود. نکات مشتری با مرورگر ادغام می شود تا این داده ها را به عنوان بخشی از درخواست در دسترس قرار دهد.
آیا نکات مشتری فقط برای منابع تصویر است؟ مورد استفاده اصلی در پشت DPR ، Viewport-Width و Width Tints فعال کردن منابع برای دارایی های تصویر است. با این حال ، همان نکات برای کلیه منابع زیر بدون در نظر گرفتن نوع ارائه می شود - به عنوان مثال CSS و درخواست های JavaScript نیز همان اطلاعات را دریافت می کنند و می توانند برای بهینه سازی آن منابع نیز استفاده شوند.
برخی از درخواست های تصویر عرض را گزارش نمی کنند ، چرا؟ مرورگر ممکن است عرض صفحه نمایش مورد نظر را نشناسد زیرا سایت به اندازه ذاتی تصویر متکی است. در نتیجه ، اشاره عرض برای چنین درخواست هایی حذف شده است ، و برای درخواست هایی که "عرض نمایش" ندارند - به عنوان مثال یک منبع جاوا اسکریپت. برای دریافت نکات عرض ، حتماً مقدار اندازه را در تصاویر خود مشخص کنید.
در مورد <اشاره مورد علاقه من> چطور؟ Service Worker توسعه دهندگان را قادر می سازد تا همه درخواست های خروجی را رهگیری و اصلاح کنند (به عنوان مثال اضافه کردن عنوان های جدید). به عنوان نمونه ، اضافه کردن اطلاعات مبتنی بر NetInfo برای نشان دادن نوع اتصال فعلی آسان است -به " گزارش قابلیت با سرویس دهنده " مراجعه کنید. نکات "بومی" ارسال شده در Chrome (DPR ، عرض ، عرض منابع) در مرورگر اجرا می شود زیرا یک اجرای خالص مبتنی بر SW باعث تأخیر تمام درخواست های تصویر می شود.
از کجا می توانم بیشتر بیاموزم ، نسخه های نمایشی بیشتری را ببینم ، و در مورد چیست؟ در صورت داشتن بازخورد یا سؤالات دیگر ، سند توضیح دهنده را بررسی کنید و در صورت بازخورد در GitHub ، مشکلی را باز کنید .