تصویری با عرض 1920 پیکسل در صفحه، برای کاربر موبایل هم کامل دانلود می‌شود و بعد روی صفحه به 390 پیکسل کوچک می‌شود — پنج برابر پهنای باند و کندی بی‌دلیل. srcset به مرورگر اجازه می‌دهد نسخه‌ی متناسب با صفحه را برگزیند، به شرط اینکه آن نسخه‌ها را ساخته باشید.

چرا یک تصویر کافی نیست

شاخص LCP در Core Web Vitals معمولاً همان تصویر بزرگ بالای صفحه است. اگر به موبایل فایلی با عرض 1920 و حجم 400KB بدهید، LCP به‌ندرت به 2.5 ثانیه می‌رسد؛ نسخه‌ی 480 پیکسلی 40KBی در همان اتصال یک رتبه سریع‌تر است. سیگنال تجربه‌ی صفحه در Google هم مستقیماً همین عدد را می‌خواند.

در عوض، تصویر 768 پیکسلی روی دسکتاپ بزرگ نرم و کم‌جزئیات دیده می‌شود. برای همین چند اندازه لازم است تا مرورگر از میانشان انتخاب کند.

جدول کاربردی نقطه‌های شکست

نقطه‌های شکست اندازه‌ی تصاویر واکنش‌گرا
نقطه‌های شکست از عرض محتوا پیروی می‌کنند نه عرض صفحه

نقطه‌های شکست از عرضی پیروی می‌کنند که تصویر در صفحه نمایش داده می‌شود، نه عرض viewport. برای دو حالت رایج، بنرهای تمام‌عرض و تصاویر داخل مقاله:

  • تصاویر تمام‌عرض (هیرو، بنر): 480، 768، 1200، 1920. موبایل، تبلت، لپ‌تاپ، نمایشگر بزرگ.
  • تصاویر مقاله (ستون محتوا تا حدود 800): 400، 800، 1200؛ اندازه‌ی 1200 به صفحه‌های با تراکم 1.5x تا 2x خدمت می‌کند.
  • تصاویر بندانگشتی و کارت‌ها (نمایش حدود 300): 300 و 600.

پله‌های بیشتر بهتر نیست. هر پله یک خروجی گرفتن اضافه و یک فایل اضافه برای نگهداری است و مرورگرها با عدم تطابق کنار می‌آیند؛ پس بهترین نقطه فاصله‌ی 1.5 تا 2 برابری میان پله‌هاست. چهار پله بیش از نه دهم ترکیب‌های دستگاه را پوشش می‌دهد.

آیا نسخه‌ی 2x لازم است؟

نمایشگرهای Retina و بیشتر موبایل‌ها با تراکم 2x تا 3x کار می‌کنند؛ تصویری که با عرض 400 نمایش داده می‌شود برای تیز دیده شدن روی آن‌ها به 800 پیکسل نیاز دارد. پله‌های بزرگ‌تر جدول عملاً نقش نسخه‌ی 2x پله‌های کوچک‌تر را دارند — 768 برای موبایل 390 پیکسلی همان 2x است و 1200 برای ستون 600 پیکسلی.

پس به مجموعه‌ی جداگانه‌ی «@2x» نیازی نیست. فاصله‌ی تقریباً دو برابری میان پله‌ها را نگه دارید تا مرورگر بر اساس تراکم پله‌ی بالاتر را بردارد.

فرمت: اول WebP، JPG برای پشتیبان

با کیفیت یکسان، WebP حدود 25 تا 35 درصد از JPG کوچک‌تر است و همه‌ی مرورگرهای امروزی از آن پشتیبانی می‌کنند. از هر اندازه خروجی WebP بگیرید و با عنصر picture یک JPG پشتیبان برای مرورگرهای قدیمی نگه دارید؛ اگر مرورگرهای پیش از 2020 برای مخاطبتان مهم نیستند، WebP تنهایی کافی است.

AVIF باز هم کوچک‌تر است اما کدگذاری آن در مرورگر بسیار کندتر است و در دسته‌های بزرگ آزار می‌دهد. AVIF در برابر WebP و JPEG این مبادله را با جزئیات بررسی کرده است.

خروجی گرفتن از کل مجموعه به‌صورت دسته‌ای

تصاویر مبدأ را در پردازش دسته‌ای تصاویر بریزید و برای هر پله یک بار اجرا کنید و هر بار عرض و پسوند را عوض کنید:

  1. اندازه: عرض 480، «اجازه‌ی بزرگ‌نمایی» خاموش، خروجی WebP با کیفیت 80 درصد، پسوند -480.
  2. همین تنظیمات برای 768 با پسوند -768؛ بعد 1200؛ بعد 1920.
  3. برای JPG پشتیبان، خروجی را روی JPG بگذارید، پسوندها را نگه دارید و دوباره اجرا کنید.

هر اجرا چند ثانیه طول می‌کشد و ZIP از قبل hero-480.webp، hero-768.webp و بقیه را دارد، آماده‌ی پوشه‌ی تصاویر. «اجازه‌ی بزرگ‌نمایی» را خاموش نگه دارید تا تصویر اصلی 1000 پیکسلی هیچ‌وقت تا 1920 کش نیاید.

برای دیدن تفاوت حجم هر پله روی یک تصویر، تغییر اندازه تصویر را روی یک فایل امتحان کنید.

نوشتن HTML

برای تصویر تمام‌عرض:

<img src="hero-1200.jpg"
     srcset="hero-480.webp 480w, hero-768.webp 768w, hero-1200.webp 1200w, hero-1920.webp 1920w"
     sizes="100vw" width="1920" height="1080" alt="...">

برای تصاویر مقاله، sizes را روی عرض واقعی بگذارید، مثلاً sizes="(max-width: 840px) 100vw, 800px". width و height را همیشه بنویسید تا مرورگر جا را رزرو کند و صفحه نپرد.

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