یک عکس محصول ممکن است با عرض چند هزار پیکسل به صفحه‌ای ارسال شود که آن را فقط در یک کارت کوچک نمایش می‌دهد. تغییر پسوند فایل شاید حجم را کم کند، اما مشکل انتخاب اندازه همچنان باقی است. بهینه‌سازی تصویر از رابطه میان فایل اصلی، اندازه نمایش و اهمیت تصویر در صفحه شروع می‌شود. فرمت، کیفیت، زمان دریافت و تعداد نسخه‌ها هرکدام بخشی از همین تصمیم هستند.
نمی‌توان گفت تصاویر در همه سایت‌ها بزرگ‌ترین علت کندی‌اند یا همیشه با یک درصد ثابت کوچک می‌شوند. صفحه‌ای ممکن است بیشتر از JavaScript، پاسخ سرور یا فونت آسیب ببیند. حتی دو عکس هم با کیفیت ظاهری مشابه، نسبت فشرده‌سازی متفاوتی دارند. برای تصویر، هدف قابل بررسی تعیین کنید: جزئیات لازم در اندازه مقصد حفظ شود و داده‌ای بیشتر از نیاز همان موقعیت ارسال نشود.
اندازه فایل و ابعاد تصویر متفاوت‌اند
ابعاد تعداد پیکسل‌های عرض و ارتفاع را بیان می‌کند؛ حجم مقدار داده فایل است. دو فایل با ابعاد برابر ممکن است به دلیل محتوا، فرمت و تنظیم کیفیت حجم متفاوتی داشته باشند. پایین آوردن کیفیت بدون کاهش ابعاد، گاهی داده اضافی را نگه می‌دارد و همزمان جزئیات را خراب می‌کند. پیش از فشرده‌سازی، نقش تصویر و عرض معمول نمایش را مشخص کنید تا اندازه خروجی از نیاز واقعی بیاید.
نسخه اصلی را برای ویرایش نگه دارید و نسخه‌های وب را جدا تولید کنید. فایل کوچکی که برای کارت مناسب است، جای نسخه مناسب نمای نزدیک را نمی‌گیرد. اگر کاربر امکان بزرگ‌نمایی محصول دارد، تصویر بزرگ‌تر را در همان موقعیت درخواست کنید. دریافت نسخه پرجزئیات برای همه کارت‌ها، هزینه قابلیتی را به همه بازدیدها تحمیل می‌کند که شاید بسیاری از مخاطبان اصلاً از آن استفاده نکنند.
فرمت را با نوع محتوا انتخاب کنید
عکس، تصویر شفاف، نقاشی خطی و اسکرین‌شات نیازهای متفاوتی دارند. فشرده‌سازی مناسب عکس ممکن است نوشته‌های کوچک یک اسکرین‌شات را خراب کند. برای طرح برداری، SVG می‌تواند شکل را بدون وابستگی به تعداد پیکسل نگه دارد؛ ولی تبدیل یک عکس به فایل SVG پیچیده مزیت مشابهی ندارد. نوع فایل باید با ساختار تصویر هماهنگ باشد، نه اینکه همه خروجی‌ها به یک پسوند اجباری تبدیل شوند.
WebP و AVIF گزینه‌های مهم برای تصویر raster هستند، اما درصد کاهش ثابتی نسبت به JPEG برای هر فایل تضمین نمی‌کنند. مقایسه باید با کیفیت قابل قبول و ابعاد یکسان انجام شود. جزئیات چهره، گرادیان، بافت و نوشته را جدا نگاه کنید؛ یک عدد کیفیت در دو encoder الزاماً معنای بصری یکسان ندارد. ابزار و تنظیم خروجی را همراه نسخه تولیدکننده ثبت کنید تا نتیجه قابل تکرار باشد.
کیفیت را در اندازه نمایش قضاوت کنید
تصویری که در بزرگ‌نمایی شدید کمی نقص دارد، ممکن است در کارت مقصد کاملاً مناسب باشد. عکس محصولی که مخاطب برای بررسی جنس بزرگ می‌کند، معیار متفاوتی دارد. انتخاب کیفیت نباید فقط از کمترین حجم ممکن پیروی کند. مهم است چه جزئیاتی برای تصمیم مخاطب لازم‌اند. برای نوشته داخل تصویر، فشرده‌سازی شدید می‌تواند خوانایی را کم کند؛ بهتر است اطلاعات متنی ضروری به صورت متن واقعی صفحه ارائه شوند.
یک مجموعه نمونه از انواع محتوای خودتان بسازید: عکس روشن، عکس کم‌نور، تصویر دارای متن و سطح شفاف. تصمیم کیفیت را بر اساس یک عکس آسان تعمیم ندهید. در فرایند تولید، امکان انتخاب استثنا برای فایل‌های دشوار را حفظ کنید. خودکارسازی مفید است، اما وقتی خروجی نامناسب می‌شود باید بتوان علت و تنظیم متفاوت را بدون شکستن کل مسیر مدیریت فایل مشخص کرد.
srcset به مرورگر گزینه می‌دهد
در راهنمای تصاویر واکنش‌گرا MDN، srcset و sizes برای معرفی نسخه‌ها و اطلاعات اندازه نمایش توضیح داده شده‌اند. مرورگر می‌تواند بر اساس شرایط انتخاب کند. اعلام چند فایل به‌تنهایی کافی نیست؛ sizes باید به عرض مورد انتظار تصویر در چیدمان مربوط باشد. اگر اطلاعات اندازه با CSS هماهنگ نباشد، انتخاب نسخه می‌تواند با نیاز واقعی فاصله پیدا کند.
برای تولید محتوا، فهرست اندازه‌ها را از جایگاه‌ها استخراج کنید: کارت کوچک، بدنه مقاله و تصویر اصلی. تولید ده‌ها اندازه نزدیک به هم هزینه ذخیره‌سازی و نگهداری می‌آورد. چند نقطه منطقی که نیازهای اصلی را پوشش دهند معمولاً قابل مدیریت‌تر است. نسخه‌ها باید از منبع مناسب تولید شوند؛ بزرگ کردن فایل کوچک، جزئیات از دست‌رفته را به شکل قابل اعتماد بازسازی نمی‌کند.
Art Direction با انتخاب اندازه فرق دارد
گاهی برای فضای باریک باید قاب تصویر تغییر کند، نه فقط ابعاد آن. یک عکس افقی گروهی ممکن است در کارت عمودی چهره اصلی را از دست بدهد. picture امکان معرفی منبع‌های مناسب شرایط مختلف را دارد، اما انتخاب قاب نیاز به تصمیم تحریری دارد. نقطه تمرکز، نوشته روی عکس و بخش‌های مهم محتوا باید در هر خروجی حفظ شوند. برش خودکار از مرکز برای همه تصاویر نتیجه مناسب نمی‌دهد.
اگر فقط نسبت قاب نمایشی فرق دارد، object-fit می‌تواند نحوه پر کردن قاب را تنظیم کند؛ این ویژگی خود فایل دریافتی را کوچک نمی‌کند. برش با CSS ممکن است همچنان فایل بزرگ کامل را دریافت کند. فرق میان برش نمایشی و خروجی تازه را در مشخصات پروژه بنویسید. برای لوگو یا نمودار، بریدن حاشیه و بخش محتوا می‌تواند معنی را خراب کند و رفتار contain مناسب‌تری داشته باشد.
جای تصویر را پیش از دریافت حفظ کنید
وقتی نسبت تصویر معلوم نباشد، ورود آن می‌تواند محتوای پایین صفحه را جابه‌جا کند. اعلام ابعاد مناسب یا نسبت قاب به مرورگر کمک می‌کند فضای مورد نیاز را از قبل در نظر بگیرد. این تصمیم با کاهش حجم فرق دارد؛ فایل کوچک هم می‌تواند جابه‌جایی آزاردهنده بسازد. نسبت اعلام‌شده باید با تصویر واقعی و قواعد چیدمان هماهنگ بماند، به‌ویژه وقتی منبع در شرایط مختلف عوض می‌شود.
برای کارت‌هایی با نسبت مشترک، قرارداد قاب را در سیستم طراحی مشخص کنید. عکس بدون ابعاد، عکس بارگیری‌نشده و عکس متفاوت از نسبت معمول باید رفتار قابل پیش‌بینی داشته باشند. اگر فایل ناموفق شد، عنوان و توضیح کارت هنوز باید قابل استفاده باشد. اطلاعات مهم را صرفاً در عکس پنهان نکنید. درباره رابطه این تصمیم‌ها با عملکرد صفحه، راهنمای Web Vitals زمینه بیشتری فراهم می‌کند.
Lazy Loading را بر اساس جایگاه اعمال کنید
راهنمای Lazy Loading تصویر در web.dev رفتار دریافت تصاویر نزدیک ناحیه دید را شرح می‌دهد. این روش برای بسیاری از تصاویر پایین صفحه مفید است، اما تصویر مهم ابتدای صفحه نباید صرفاً به دلیل سیاست یکسان سایت با تأخیر درخواست شود. تصویر احتمالی LCP را از تصاویر آرشیو طولانی جدا کنید. اولویت دریافت، زمان کشف فایل و محل واقعی نمایش با هم اثر می‌گذارند.
روی فهرست‌های بلند، صرفاً تأخیر دریافت تصویر مسئله تعداد عناصر و محتوای صفحه را حل نمی‌کند. اگر کاربر صدها کارت دریافت می‌کند، صفحه‌بندی و ساختار فهرست هم نیاز به تصمیم دارند. برای تصویرهای پنهان داخل تب یا اسلایدر، رفتار هنگام آشکار شدن را مشخص کنید. پیش‌بارگذاری همه اسلایدها نیز ممکن است هزینه‌ای ایجاد کند که کاربر بدون دیدن آن محتوا پرداخت می‌کند.
CDN و کش قرارداد می‌خواهند
سرویس تبدیل تصویر می‌تواند بر اساس پارامترهای URL اندازه و فرمت تولید کند. این قابلیت وقتی قابل کنترل است که اندازه‌های مجاز، کیفیت، کش و مدیریت خطا روشن باشند. باز گذاشتن همه ترکیب‌های ممکن می‌تواند تعداد خروجی‌ها را بی‌دلیل زیاد کند. نسخه فایل و کلید کش باید با تغییر محتوای تصویر هماهنگ شوند تا عکس تازه با نشانی قدیمی و خروجی مانده مخلوط نشود.
تصاویر عمومی و خصوصی را در یک سیاست قرار ندهید. تصویر مدارک یا محتوای محدود به حساب، نیازهای دسترسی جدا دارد. کپی کردن آن به CDN عمومی برای بهبود سرعت تصمیم مناسبی نیست. نام فایل، metadata و پارامترهای نشانی هم می‌توانند اطلاعاتی افشا کنند. فرایند بهینه‌سازی باید همان مرز دسترسی منبع را حفظ کند و رفتار حذف یا تغییر فایل را برای خروجی‌های تولیدشده مشخص سازد.
تحویل قابل نگهداری
برای هر جایگاه، نسبت قاب، اندازه‌های تولیدی، معیار کیفیت و سیاست دریافت را ثبت کنید. محتوای جایگزین فارسی باید نقش تصویر را توضیح دهد؛ برای تزئین، تکرار بی‌دلیل متن اطراف لازم نیست. اگر تصویر نمودار دارد، داده و نتیجه ضروری را در متن هم بیاورید. خواننده‌ای که فایل را نمی‌بیند باید بتواند موضوع مقاله یا کار محصول را بفهمد.
برای بررسی بیشتر انتخاب فرمت، راهنمای فرمت و فشرده‌سازی تصویر و برای شکل‌های برداری راهنمای SVG مکمل این تصمیم‌ها هستند. بهینه‌سازی زمانی پایدار می‌شود که تولید نسخه‌ها از نیاز چیدمان پیروی کند و تیم بداند چرا هر فایل وجود دارد. کاهش حجم نتیجه قابل اندازه‌گیری این فرایند است، نه وعده درصدی یکسان برای همه تصاویر.
هنوز دیدگاهی ثبت نشده
اولین نفری باشید که نظر می‌دهد!