بهینه‌سازی تصویر از لحظه انتخاب فایل شروع می‌شود. اگر عکس اصلی تار باشد، تبدیل آن به AVIF جزئیات تازه‌ای ایجاد نمی‌کند. اگر برای یک کارت کوچک، خروجی چند هزار پیکسلی بفرستیم، پایین آوردن quality هم مسئله را کامل حل نمی‌کند. هدف این است که تصویر مناسب هر جایگاه، با کیفیت قابل قبول و هزینه انتقال معقول به کاربر برسد. فرمت و فشرده‌سازی دو بخش این تصمیم هستند؛ اندازه، محتوای تصویر، شیوه نمایش و فرایند تولید نسخه‌ها هم به همان اندازه اهمیت دارند.
برای همه سایت‌ها نمی‌توان درصد ثابت بهبود اعلام کرد. صفحه‌ای با عکس‌های بزرگ ممکن است از تغییر تصاویر سود زیادی ببرد، ولی صفحه‌ای که مشکل اصلی آن JavaScript یا پاسخ کند سرور است، نتیجه دیگری دارد. حتی دو عکس با ابعاد یکسان و یک quality مشابه، حجم یکسانی ندارند. بافت برگ درخت، نویز عکاسی و نوشته ریز با زمینه صاف رفتار متفاوتی دارند. مقایسه باید روی تصاویر واقعی پروژه انجام شود، نه روی وعده یک فرمت.
اول مقصد تصویر را مشخص کنید
پیش از انتخاب فرمت، نقش تصویر را بنویسید. عکس محصول باید رنگ، جنس و جزئیات تصمیم‌ساز را نشان دهد. تصویر یک خبر ممکن است بیشتر به تشخیص چهره و موقعیت نیاز داشته باشد. یک نمودار به لبه‌های واضح و متن خوانا وابسته است. تصویر تزئینی زمینه، معمولاً تحمل بیشتری برای کاهش جزئیات دارد. همین تفاوت تعیین می‌کند کدام آثار فشرده‌سازی پذیرفتنی هستند و کدام بخش باید سالم بماند. معیار کیفیت را به کاربرد وصل کنید تا بحث به پسند شخصی محدود نشود.
ابعاد نمایش را نیز از طراحی بگیرید. برای تصویری که در چند عرض نمایش داده می‌شود، یک اندازه واحد الزاماً کافی نیست. نسخه کوچک برای موبایل و نسخه بزرگ‌تر برای نمایشگر متراکم می‌توانند از یک منبع تولید شوند. اما تولید بی‌حساب اندازه‌ها، فضای ذخیره‌سازی و پیچیدگی مدیریت را افزایش می‌دهد. چند عرض واقعاً مصرف‌شده را انتخاب کنید و نام هر نسخه را قابل فهم نگه دارید. جزئیات انتخاب نسخه در مرورگر را در راهنمای اندازه و تحویل تصاویر وب دنبال کنید.
فرمت را با نوع محتوا بسنجید
JPEG برای بسیاری از عکس‌ها مناسب است و امکان فشرده‌سازی lossy دارد، اما کانال شفافیت ندارد. PNG می‌تواند پیکسل‌ها را بدون اتلاف نگه دارد و شفافیت را پشتیبانی کند؛ این ویژگی به معنی کم‌حجم بودن هر PNG نیست. برای عکس پرجزئیات، فایل PNG ممکن است بزرگ شود. WebP و AVIF گزینه‌های دیگری برای تصاویر raster هستند و قابلیت‌هایی مانند شفافیت دارند. انتخاب میان آن‌ها باید بر اساس کیفیت بصری، حجم، زمان تولید و نیاز مقصد انجام شود، نه یک جدول رتبه‌بندی همیشگی.
SVG ساختار برداری دارد و برای شکل‌ها، نمودارهای ساده و بعضی آیکون‌ها مناسب است. عکس دوربین با تبدیل ظاهری به SVG، خودبه‌خود به یک تصویر برداری تمیز تبدیل نمی‌شود. SVG پیچیده با مسیرهای فراوان یا منابع جاسازی‌شده هم می‌تواند بزرگ باشد. برای نمایش تصویر متحرک، تصمیم جداگانه‌ای لازم است؛ گاهی یک ویدئو بهتر از مجموعه فریم‌های تصویر به نیاز پاسخ می‌دهد. تعداد رنگ‌ها یا وجود شفافیت را به تنهایی معیار نهایی نگیرید؛ ترکیب ویژگی‌ها مهم است.
فشرده‌سازی چه چیزی را تغییر می‌دهد؟
در فشرده‌سازی lossless، داده تصویر طوری بازنمایی می‌شود که پیکسل‌های نتیجه از نظر اطلاعات تصویری حفظ شوند. در روش lossy بخشی از اطلاعات کنار گذاشته می‌شود تا فایل کوچک‌تر شود. افت کیفیت همیشه به شکل تاری آشکار دیده نمی‌شود؛ ممکن است دور نوشته هاله ایجاد شود، گرادیان نوارنوار شود یا بافت پارچه حالت مومی پیدا کند. این آثار را در همان ابعادی بررسی کنید که کاربر تصویر را می‌بیند، و برای قسمت‌های حساس یک بررسی نزدیک‌تر هم داشته باشید.
عدد quality میان ابزارها و فرمت‌ها واحد مشترک کیفیت نیست. خروجی quality هفتاد در یک encoder را نمی‌توان صرفاً با همان عدد در encoder دیگر برابر گرفت. مقدار پیش‌فرض ابزار نیز تضمین مناسب بودن برای محتوای شما نیست. چند خروجی با تنظیم‌های مشخص بسازید، حجم و ظاهر را کنار هم ببینید و نقطه قابل قبول را انتخاب کنید. اگر نسخه کوچک به خاطر تغییر ابعاد واضح‌تر و سبک‌تر شده، این اثر را از اثر تغییر فرمت جدا یادداشت کنید.
یک مقایسه محدود اما قابل تکرار
به جای تبدیل کل آرشیو در اولین روز، چند نمونه نماینده انتخاب کنید: عکس روشن، عکس تیره، محصول با زمینه ساده، بافت پرجزئیات، تصویر دارای متن و تصویری با شفافیت. برای هر نمونه، ابعاد مقصد را ثابت نگه دارید تا مقایسه منصفانه باشد. سپس نسخه‌های فرمت‌های مورد نظر را با چند تنظیم محدود تولید کنید. نتیجه‌ها باید از یک منبع اصلی باشند؛ تبدیل JPEG فشرده‌شده به چند خروجی دیگر، توان واقعی فرمت‌ها را به خوبی نشان نمی‌دهد.
برای هر فایل، حجم، ابعاد، تنظیم تولید و ایراد قابل مشاهده را ثبت کنید. وجود یک عدد کوچک‌تر در ستون حجم کافی نیست؛ ممکن است جزئیات ضروری حذف شده باشد. اگر تصاویر را افراد مختلف تأیید می‌کنند، معیار مشترک بنویسید: خوانایی نوشته روی بسته، طبیعی بودن پوست، حفظ خطوط محصول یا نبود نوار در زمینه. این توضیح کوتاه از برگشت مداوم تنظیم‌ها جلوگیری می‌کند. ابزار مقایسه باید نام نسخه‌ها را روشن نشان دهد تا خروجی تأییدشده اشتباهی جابه‌جا نشود.
منبع اصلی را نگه دارید
فایل اصلی را از نسخه تحویل وب جدا کنید. نسخه‌ای که امروز برای یک کارت تولید می‌شود، ممکن است برای طراحی بعدی کافی نباشد. اگر تنها همان نسخه باقی بماند، افزایش ابعاد یا فشرده‌سازی دوباره محدودیت ایجاد می‌کند. فایل اصلی نباید مستقیماً در همه صفحات مصرف شود، ولی باید در یک محل مدیریت‌شده باقی بماند. نام‌گذاری یا شناسه رسانه کمک می‌کند بدانید هر خروجی متعلق به کدام منبع است و تغییر منبع کدام نسخه‌ها را باید بازتولید کند.
فشرده‌سازی lossy پشت سر هم می‌تواند آثار قبلی را تشدید کند. هر بار از منبع مناسب خروجی بگیرید، نه از آخرین نسخه کوچک. اگر ویرایشگر عکس را اصلاح کرده، نسل تازه خروجی‌ها را از همان فایل اصلاح‌شده بسازید. در CMS بهتر است کاربر مقصد تصویر را انتخاب کند و سیستم نسخه‌ها را تولید کند؛ مجبور کردن نویسنده به انتخاب چند مقدار فنی، خطاهای تکراری ایجاد می‌کند. تنظیم‌های پیش‌فرض باید قابل تغییر باشند، اما تغییرشان دلیل مشخص داشته باشد.
رنگ، جهت و اطلاعات جانبی
عکس دوربین ممکن است اطلاعات جهت در metadata داشته باشد. حذف این اطلاعات بدون اعمال جهت درست می‌تواند تصویر را چرخیده نشان دهد. ترتیب پردازش را مشخص کنید: خواندن منبع، اصلاح جهت، تغییر ابعاد و سپس خروجی. رنگ نیز نیاز به تصمیم دارد. حذف بی‌فکر اطلاعات مرتبط با رنگ می‌تواند نمایش را تغییر دهد. برای کاربردی که رنگ محصول اهمیت دارد، بررسی خروجی روی مقصد واقعی و مدیریت profile باید بخشی از فرایند باشد، نه کاری که بعد از شکایت کاربر انجام شود.
بعضی metadataها شامل موقعیت جغرافیایی یا اطلاعات دستگاه هستند. نگه‌داشتن آن‌ها در نسخه عمومی معمولاً ضرورتی ندارد، اما سیاست حذف باید روشن باشد. اطلاعات حقوقی و منبع عکس را هم صرفاً به فایل وابسته نکنید؛ حق استفاده و نام صاحب اثر را در رکورد رسانه نگه دارید. یک optimizer مسئول مدیریت مجوز نیست. کاهش حجم زمانی درست انجام شده که هم نتیجه بصری مناسب باشد و هم اطلاعات مورد نیاز تیم برای استفاده و نگهداری از دست نرود.
تحویل و نگهداری نسخه‌ها
تولید فایل سبک، پایان مسیر نیست. مرورگر باید نسخه مناسب را دریافت کند و cache نیز با تغییر محتوا به‌روز شود. اگر URL یک فایل عوض نمی‌شود ولی محتوای آن تغییر می‌کند، تنظیم cache می‌تواند نسخه قدیمی را نگه دارد. استفاده از نام یا شناسه نسخه در مسیر، مدیریت این وضعیت را ساده‌تر می‌کند. وقتی CDN بر اساس درخواست فرمت را تبدیل می‌کند، رفتار cache و نسخه fallback را از تنظیم واقعی سرویس بررسی کنید؛ فرض نکنید همه درخواست‌ها یک پاسخ دارند.
تصویر مهم ابتدای صفحه را صرفاً به خاطر کوچک‌تر کردن درخواست‌ها lazy نکنید. تصاویر خارج از دید اولیه ممکن است از lazy loading سود ببرند، ولی زمان درخواست تصویر اصلی به تجربه بارگذاری مربوط است. همچنین width و height مناسب به مرورگر کمک می‌کنند فضای تصویر را پیش از دریافت آن در نظر بگیرد. در مطلب Web Vitals ارتباط این تصمیم‌ها با تجربه واقعی توضیح داده شده است. نتیجه را با یک شاخص منفرد قضاوت نکنید.
سیاستی که تیم بتواند نگه دارد
برای هر دسته رسانه، یک دستور کوتاه تدوین کنید: منبع قابل قبول، عرض‌های خروجی، فرمت‌ها، تنظیم آغازین، موارد نیازمند تأیید و محل ذخیره نسخه‌ها. عکس محصول و screenshot رابط الزاماً سیاست یکسانی ندارند. اگر ابزار عوض شد، چند نمونه قبلی را دوباره مقایسه کنید تا تغییر encoder بی‌صدا کیفیت را پایین نیاورد. این بررسی به معنای بازسازی دائمی تمام آرشیو نیست؛ اندازه تغییر و کاربرد تصویر تعیین می‌کند کجا بازبینی لازم است.
در نهایت، فرمت مناسب همان گزینه‌ای است که نیاز مشخص پروژه را با هزینه قابل قبول برآورده می‌کند. کوچک‌ترین فایل ممکن است جزئیات ضروری را از بین ببرد و باکیفیت‌ترین خروجی ممکن است داده اضافی بفرستد. تصمیم خوب میان این دو با نمونه واقعی و معیار روشن شکل می‌گیرد. برای شناخت تفاوت قابلیت فرمت‌ها، مرجع فرمت‌های تصویر MDN نقطه شروع مناسبی است؛ درصد صرفه‌جویی را از خروجی‌های خود پروژه به دست آورید.
هنوز دیدگاهی ثبت نشده
اولین نفری باشید که نظر می‌دهد!