افزایش سرعت سایت

بهینه سازی تصاویر برای وب

بهینه سازی تصویر سه کار است و به همین ترتیب اهمیت دارد: کوچک کردن به همان اندازه ای که واقعا نمایش داده می شود، فرستادن در فرمت مدرن، و اعلام صریح ابعاد در HTML. تصویری که به درد نمی خورد اما، بهتر است اصلا فرستاده نشود؛ همین اول از همه است.

درس ۵ از ۱۰
مقدماتی
رایگان، بدون ثبت نام

همان تصویر، از فایل دوربین تا چیزی که به بازدیدکننده می رسد

گلوگاه وسط جایی است که تصمیم ها گرفته می شوند و اگر یک بار درست انجام شود، هر بازدیدکننده بعدی سود می برد.

آنچه دست شماست

فایل دوربین یا خروجی طراحی، چند مگابایت
عرضی چند برابر جایی که نمایش داده می شود
داده اضافه دوربین و موقعیت جغرافیایی

یک بار، قبل از آپلود

آنچه به بازدیدکننده می رسد

فایلی در همان عرضی که واقعا نمایش داده می شود
فرمت مدرن، با کیفیتی که چشم تفاوتش را نمی بیند
ابعاد صریح در HTML، پس هیچ جابه جایی چیدمان
بارگذاری تنبل برای هر تصویری جز اولی

این شکل ترتیب کار را نشان می دهد و نه مقدار صرفه جویی را. مقدارش به خود تصویر بستگی دارد: عکس با آسمان یکدست خیلی بهتر فشرده می شود و اسکرین شات پر از متن ریز خیلی بدتر.

آخرین بررسی: ۱۷ شهریور ۱۴۰۵ فکت ها و نام ابزارهای این درس در همین تاریخ با منابعشان بازبینی شده اند.

قبل از هر ابزاری، از خود تصویر بپرسید

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

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

دسته دوم مهم ترین است چون بیشترین بایت را می خورد و ساده ترین جایگزین را دارد. یک نمودار میله ای که به شکل PNG ذخیره شده، هم سنگین است، هم روی موبایل ناخواناست، هم متنش را هیچ موتور جستجویی نمی خواند. همان نمودار با HTML و CSS چند صد بایت است، در هر اندازه ای خوانا می ماند و متنش قابل انتخاب و ترجمه است. آیکن ها هم همین طور: یک SVG درون خطی از یک PNG کوچک سبک تر تمام می شود و رنگش با قالب عوض می شود.

این جایی است که ما موضع سختی داریم و بهایش را هم می دهیم: در کل صفحه اول این سایت صفر تگ img هست. هر چیزی که اینجا شبیه اینفوگرافیک است با HTML و CSS کشیده شده. محدودیتش را هم می پذیریم، چون هیچ کدام از این شکل ها نمی توانند عکس یک محصول واقعی باشند. اگر فروشگاه دارید، عکس محصول قابل حذف نیست و بقیه این درس دقیقا برای همان است.

چاپ عکس بسیار بزرگی که به داخل قاب سفید کوچکی تا می شود و لایه های اضافه اش قرمز، سبز و آبی باز مانده اند

سوالی که قبل از باز کردن هر ابزار فشرده سازی باید جواب بگیرد

این تصویر اصلا باید تصویر باشد؟

نه

با HTML و CSS بکشیدش

نمودار، جدول و اینفوگرافیک؛ متنش هم خوانده می شود
آیکن ها؛ یک SVG درون خطی از یک PNG کوچک سبک تر است
عکس تزئینی؛ حذفش کنید و چیزی از دست نمی رود

بله

پس درست بفرستیدش

در همان اندازه ای که نمایش داده می شود، نه اندازه اصلی
در فرمت مدرن، با کیفیتی که خودتان امتحان کرده اید
با ابعاد صریح در HTML و lazy برای هر چه پایین تر است

شاخه راست همه چیز را حذف نمی کند. عکس محصول، عکس واقعی کار انجام شده و اسکرین شات یک اندازه گیری، همگی محتوای واقعی اند و می مانند.

اندازه واقعی، نه اندازه ای که آپلود کرده اید

رایج ترین اشتباه در تصویر سایت این است که فایل دوربین یا خروجی فتوشاپ مستقیم آپلود می شود و بعد با CSS کوچک نمایش داده می شود. مرورگر تمام آن فایل را دانلود می کند و بعد کوچکش می کند. یعنی بازدیدکننده تمام بایت هایی را که هرگز نمی بیند پرداخت کرده.

کار درست دو قدم دارد. اول اندازه ای را که تصویر واقعا در آن نمایش داده می شود پیدا کنید: صفحه را در مرورگر باز کنید، روی تصویر راست کلیک و بازرسی کنید و عرض واقعی عنصر را بخوانید. دوم فایل را در همان اندازه بسازید، معمولا با ضریب دو برای صفحه های با تراکم بالا. اگر تصویری در قالب شما همیشه در عرض ۴۰۰ پیکسل نمایش داده می شود، فایل ۸۰۰ پیکسلی کافی است و فایل ۳۰۰۰ پیکسلی فقط پول اینترنت بازدیدکننده را می سوزاند.

در وردپرس این کار تا حد خوبی خودکار است: هر آپلود چند اندازه تولید می شود و قالب با srcset مناسب ترین را به مرورگر می سپارد. دو جا اما این زنجیره می شکند و هر دو رایج اند. اول تصویری که مستقیم در متن با آدرس فایل اصلی گذاشته شده و از این مسیر رد شده. دوم تصویری که ابعادش از تمام اندازه های تولید شده بزرگ تر است، مثل عکس ۴۰۰۰ پیکسلی که هیچ اندازه میانی برایش ساخته نشده.

فرمت و فشرده سازی، با عددهای واقعی

برای اینکه این بحث از حد سلیقه بیرون بیاید، یک فایل واقعی از همین سرور را برداشتیم و در دو عرض و سه فرمت ساختیم. تصویر اصلی یک کاور اشتراک گذاری ۱۲۰۰ در ۶۳۰ پیکسل است و همان طور که آپلود شده بود ۵۷.۸ کیلوبایت وزن دارد. با ImageMagick و کیفیت ۷۸ برای JPEG و WebP و کیفیت ۵۵ برای AVIF، این جدول در آمد:

فرمت	در عرض ۱۲۰۰	در عرض ۸۰۰
JPEG	۴۷.۲ کیلوبایت	۲۳.۵ کیلوبایت
WebP	۲۰.۹ کیلوبایت	۱۱.۷ کیلوبایت
AVIF	۱۴.۶ کیلوبایت	۸.۳ کیلوبایت

دو چیز از این جدول در می آید. اول اینکه هر دو کار جواب می دهند و هیچ کدام جای دیگری را نمی گیرد: عوض کردن فرمت در همان عرض، حجم را تقریبا نصف می کند، و نصف کردن عرض دوباره تقریبا نصفش می کند. دوم اینکه با هم رفتن این دو، همان فایل ۵۷.۸ کیلوبایتی را به ۱۱.۷ کیلوبایت رساند، یعنی حدود یک پنجم، بدون اینکه چشم تفاوتی ببیند.

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

دستوری که این خروجی ها را ساخت همین یک خط است و روی یک پوشه هم کار می کند:

for f in *.jpg; do convert "$f" -resize '800x>' -strip -quality 78 "${f%.jpg}.webp"; done

سه چیز در این دستور عمدی است. علامت بزرگ تر بعد از عرض یعنی فقط تصویرهای بزرگ تر کوچک شوند و تصویر کوچک تر بزرگ نشود، که اگر نباشد فایل های کوچک را باد می کند. strip داده های اضافه مثل مدل دوربین و مختصات جغرافیایی را حذف می کند، که هم بایت است و هم گاهی اطلاعاتی است که نمی خواستید منتشر شود. و کیفیت ۷۸ یک نقطه شروع است و نه یک قانون؛ روی تصویرهای خودتان چند عدد را امتحان کنید.

همان تصویر، چهار جور فرستادن

یک تصویر واقعی از همین سرور، اندازه گیری شده در ۱۷ شهریور ۱۴۰۵

اصل، همان طور که آپلود شده ۵۷.۸ کیلوبایت عرض ۱۲۰۰ پیکسل
JPEG در عرض ۸۰۰ ۲۳.۵ کیلوبایت فقط کوچک شده، فرمت همان است
WebP در عرض ۸۰۰ ۱۱.۷ کیلوبایت هر دو کار با هم، حدود یک پنجم اصل
AVIF در عرض ۸۰۰ ۸.۳ کیلوبایت سبک ترین، ولی ساختنش کندتر است

این عددها مال یک تصویر است و روی تصویرهای شما فرق می کند. کیفیت ۷۸ برای JPEG و WebP و کیفیت ۵۵ برای AVIF استفاده شده؛ با کیفیت دیگر، عددها هم عوض می شوند.

کدام تصویر نباید lazy شود

بارگذاری تنبل یعنی مرورگر تصویری را که هنوز نزدیک کادر دید نیست دانلود نکند. با یک صفت در HTML فعال می شود و برای صفحه ای با ده ها تصویر برد بزرگی است.

و دقیقا همین جا رایج ترین اشتباه سرعت اتفاق می افتد: کسی افزونه ای نصب می کند که همه تصویرها را تنبل می کند، از جمله همان تصویر بزرگ بالای صفحه. حالا مرورگر تصویری را که باید اول از همه بیاید، عمدا عقب می اندازد و LCP بدتر می شود، نه بهتر. مستندات خود گوگل صریح است: تصویرهایی را که احتمالا هنگام بارگذاری داخل کادر دید هستند تنبل نکنید، به خصوص تصویر LCP.

قاعده ای که از این در می آید ساده است. هر تصویری که کاربر بدون اسکرول کردن می بیند، تنبل نمی شود. هر چیزی که پایین تر است، می شود. برای همان تصویر بالای صفحه یک قدم اضافه هم هست: می توانید با صفت اولویت واکشی به مرورگر بگویید این یکی از بقیه مهم تر است. و ترکیب تنبل با اولویت بالا کار نمی کند؛ مستندات گوگل می نویسد چنین تصویری باز هم تا نزدیک شدن به کادر دید عقب می افتد و بعد با اولویت بالا گرفته می شود، که همان چیزی نیست که می خواستید.

راه چک کردنش هم دستی است و یک دقیقه وقت می برد: صفحه را باز کنید، سورس را ببینید، و روی اولین تصویر بزرگ صفحه دنبال صفت تنبل بگردید. اگر آنجا بود، پیدایش کردید.

ابعاد صریح، و تله ای که خودمان در آن افتادیم

قاعده آخر ساده ترین است و بیشتر از همه نادیده گرفته می شود: هر تگ تصویر باید width و height واقعی خودش را داشته باشد. بدون آنها مرورگر نمی داند چقدر جا خالی بگذارد، پس متن را می چیند و وقتی تصویر می رسد همه چیز را هل می دهد. همان جابه جایی است که در CLS شمرده می شود.

با این دو صفت، مرورگر نسبت ابعاد را از خودشان حساب می کند و جا را از قبل نگه می دارد. یعنی حتی اگر CSS شما تصویر را کشسان کند، جای خالی درست است و جابه جایی رخ نمی دهد. این همان چیزی است که به یک سایت اجازه می دهد CLS صفر داشته باشد و باز هم تصویر واکنش گرا داشته باشد.

و حالا تله ای که خودمان در آن افتادیم، چون هیچ آموزشی این را نمی نویسد. تقریبا هر سایت واکنش گرایی یک قاعده سراسری دارد که ارتفاع تصویر را خودکار می کند؛ در فایل استایل اصلی این سایت هم دقیقا همین قاعده هست. برای جلوگیری از جابه جایی این هیچ مشکلی ندارد و درست هم هست. ولی معنای دیگری هم دارد که به موقعش گران تمام می شود: اگر جایی عرض را از CSS بدهید و ارتفاع را به صفت HTML بسپارید، آن قاعده سراسری برنده می شود و کادر به نسبت ذاتی خود فایل جمع می شود. برای ما این روی آواتارهای صفحه فریلنسرها اتفاق افتاد: کادرها باید دایره می شدند و به شکل بیضی در می آمدند، و بدترین حالت مال عکسی بود که در اصل یک اسکرین شات بلند موبایل بود. راه درست این است که CSS شکل را صاحب شود، یعنی عرض و ارتفاع را خودش بدهد و برش را با object-fit مشخص کند؛ صفت های HTML برای جا نگه داشتن اند و نه برای شکل دادن.

چهار چیزی که باید باشد، و چهار چیزی که نباید

برگه تصویرقبل از انتشار

باید باشد

عرض فایل نزدیک به عرضی که واقعا نمایش داده می شود
فرمت مدرن با کیفیتی که خودتان امتحان کرده اید
width و height صریح روی هر تگ تصویر
اولین تصویر بالای صفحه، بدون بارگذاری تنبل

نباید باشد

فایل دوربین که مستقیم آپلود شده و با CSS کوچک شده
نمودار یا جدولی که به شکل عکس ذخیره شده
افزونه ای که همه تصویرها را بدون استثنا تنبل می کند
ارتفاعی که به صفت HTML سپرده شده و CSS آن را می برد

ردیف آخر ستون بالا تنها موردی است که ابزار خودکار نمی تواند برایتان انجام بدهد، چون فقط شما می دانید کدام تصویر اول دیده می شود.

مسیر سریع با هوش مصنوعی

راه معمولی این است که تصویرها را یکی یکی در یک سرویس آنلاین بالا بدهید و خروجی را دانلود کنید. برای پنج تصویر جواب می دهد و برای دویست تا نه. راه سریع یک تغییر ذهنی دارد که بیشتر آدم ها نمی کنند: از مدل نخواهید تصویرها را بهینه کند، از او بخواهید دستوری بنویسد که این کار را بکند. مدل ابزار نیست، ابزارساز است. خروجی این کار یک اسکریپت است که همان روز روی دویست تصویر اجرا می شود و دفعه بعد هم دوباره به کار می آید.

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

نسخه آماده کپی

برای من یک دستور خط فرمان بنویس که یک پوشه تصویر را برای وب آماده کند. من دستور را خودم اجرا می کنم، پس کارت نوشتن آن است و نه انجام دادنش.

وضعیت من:
سیستم عامل: {لینوکس | مک | ویندوز}
ابزاری که نصب دارم: {ImageMagick | ffmpeg | هیچ کدام، بگو چه چیزی لازم است}
پوشه: {مسیر}، حدود {تعداد} فایل با پسوند {jpg | png | هر دو}
بیشترین عرضی که این تصویرها در سایت نمایش داده می شوند: {عدد} پیکسل

شرط ها، همه اجباری:
۱. تصویری که از آن عرض کوچک تر است بزرگ نشود.
۲. فایل های اصلی پاک یا بازنویسی نشوند؛ خروجی در یک پوشه جدا.
۳. داده های اضافه مثل مدل دوربین و موقعیت جغرافیایی حذف شود.
۴. اسم فایل خروجی از اسم ورودی ساخته شود و فاصله و حروف غیرلاتین اسم را نشکند.
۵. اگر یک فایل خراب بود، حلقه متوقف نشود و اسمش را چاپ کند.

بعد از دستور، این سه چیز را بنویس:
۱. جلوی هر پرچم یک خط توضیح که دقیقا چه کار می کند.
۲. یک نسخه آزمایشی که فقط روی سه فایل اول اجرا می شود.
۳. یک دستور جدا که بعد از تبدیل، حجم قبل و بعد را کنار هم چاپ کند.

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

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

هوش مصنوعی در این کار

موضع ما اینجا برخلاف انتظار است: در بهینه سازی تصویر، بهترین استفاده از هوش مصنوعی این است که خودش به تصویرها دست نزند. کاری که واقعا خوب انجام می دهد نوشتن دستور، توضیح دادن پرچم ها و بازرسی قالب سایت است. کاری که در آن ضعیف است، تولید یا بازسازی خود تصویر برای وب است؛ آنجا هم کیفیت غیرقابل پیش بینی است و هم رد پایی به جا می ماند که بخش بعدی درباره اش است.

ابزارهایی که واقعا کمک می کنند

Claude برای همان کار مسیر سریع مناسب است: دستور دسته ای می نویسد، پرچم ها را توضیح می دهد و نسخه آزمایشی روی سه فایل را هم می سازد. ایران در فهرست کشورهای پشتیبانی شده انتروپیک نیست، پس نه ثبت نام رسمی انجام می شود و نه کارت ایرانی پذیرفته می شود.
Gemini برای نگاه کردن به خود صفحه مفید است: اسکرین شات صفحه را بدهید و بپرسید کدام تصویر اول از همه دیده می شود و کدام ها زیر خط تا هستند. همین یک جواب معلوم می کند کدام تصویر نباید تنبل شود. صفحه خود گوگل می گوید اپ وب جمنای در بیش از دویست و سی کشور و منطقه کار می کند و ایران در آن فهرست نیست.
ChatGPT برای همان نوشتن و توضیح دادن دستور کافی است. درباره دسترسی از ایران ادعایی نمی کنیم، چون صفحه کشورهای پشتیبانی شده اوپن ای آی مثل بقیه آن دامنه به این سرور پاسخ ۴۰۳ می دهد.

کجا نتیجه معکوس می دهد

دو خطر، و دومی مخصوص همین درس است. اول پرچم های ساختگی: مدل الگوی دستورهای ImageMagick و ffmpeg را دیده و می تواند پرچمی بنویسد که وجود ندارد یا در نسخه شما معنای دیگری دارد. روی یک پوشه تصویر این خطا برگشت پذیر نیست اگر اصل ها را بازنویسی کرده باشید، پس نسخه پشتیبان قدم اول است و نه آخر. خطر دوم مال جای دیگری از همین کار است: اگر تصویرهایی که بهینه می کنید خودشان با هوش مصنوعی ساخته شده باشند، ممکن است چیزی همراهشان باشد که نمی بینید. گوگل دیپ مایند ابزاری به اسم SynthID دارد که در خروجی مدل های تصویری گوگل یک نشان دیجیتال نامحسوس جاسازی می کند و خود گوگل می تواند بعدا آن را تشخیص بدهد. یعنی سایتی که انبوهی تصویر تولید شده منتشر می کند، برای صاحب همان مدل قابل شناسایی است، و فشرده سازی و تغییر اندازه هم برای پاک کردنش طراحی نشده. موضع ما ساده است: مدل دستور را بنویسد، شما اجرا کنید و خروجی را با چشم ببینید. اگر می خواهید خود تصویر با هوش مصنوعی ساخته شود، آن بحث دیگری است و در درس نشان های پنهان تصویرهای هوش مصنوعی باز شده.

منبع ها: Google DeepMind: SynthID Anthropic: supported countries Google: where Gemini Apps are available

حد این توصیه

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

از تجربه خود ما

مهم ترین چیزی که درباره ابعاد صریح یاد گرفتیم را از یک باگ خودمان یاد گرفتیم و در هیچ آموزشی ندیدیم. در فایل استایل اصلی این سایت، خط ۶۸ یک قاعده سراسری دارد که به هر تصویر و ویدیو می گوید حداکثر عرض صد درصد و ارتفاع خودکار. این قاعده درست است و نگه داشتن جا برای تصویر را هم خراب نمی کند، چون مرورگر نسبت را از صفت های width و height حساب می کند. ولی معنای دومی هم دارد: هر جا که CSS فقط عرض بدهد و ارتفاع را به صفت HTML بسپارد، همان قاعده سراسری برنده می شود و کادر به نسبت ذاتی فایل جمع می شود. در ۶ شهریور ۱۴۰۵ همین اتفاق روی آواتارهای صفحه فریلنسرها افتاد: کادرهایی که باید دایره می شدند بیضی شدند، و بدترینشان تصویری بود که در اصل یک اسکرین شات بلند موبایل بود. راه حل درست هم افزودن صفت بیشتر به HTML نبود؛ این بود که CSS شکل را صاحب شود، یعنی کلاس آواتار خودش عرض و ارتفاع بدهد و برش را با object-fit مشخص کند. حالا چیزی که این تجربه به ما تحمیل کرد: هر بار که یک کادر تصویر با شکل ثابت می سازیم، باید در CSS دنبال همان قاعده سراسری بگردیم، و این هزینه ای است که یک قاعده خوب بابت خوب بودنش می گیرد.

سوال هایی که واقعا پرسیده می شوند

همه تصویرها را به WebP تبدیل کنم؟

برای عکس ها بله و بردش هم قابل توجه است. ولی قبل از تبدیل فرمت، اندازه را درست کنید: در اندازه گیری ما، کوچک کردن عرض همان قدر اثر داشت که عوض کردن فرمت. اگر فایل هایتان همان اول در اندازه درست ساخته شده اند، تبدیل به WebP یک برد اضافه است و نه یک نجات.

افزونه بهینه سازی تصویر نصب کنم یا خودم انجام بدهم؟

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

کیفیت را روی چه عددی بگذارم؟

عدد جهانی درستی وجود ندارد، چون به خود تصویر بستگی دارد. ما برای این درس ۷۸ را برای JPEG و WebP امتحان کردیم و نتیجه اش برای یک عکس معمولی خوب بود. روش درست این است که سه عدد را روی چند تصویر واقعی خودتان بگیرید و با چشم مقایسه کنید، به خصوص روی تصویرهایی که متن ریز دارند.