بهینه‌سازی تصویر: سایت خود را با WebP و AVIF سریع‌تر کنید

چرا تصاویر سرعت صفحه شما را تعیین می‌کنند

در بیشتر صفحات، تصاویر بزرگ‌ترین سهم را از بایت‌هایی که مرورگر دانلود می‌کند دارند. همین آن‌ها را به هدف شماره‌یک برای یک سایت سریع‌تر تبدیل می‌کند — و دلیل اصلی اینکه یک صفحه در Core Web Vitals رد می‌شود، چون بزرگ‌ترین تصویر اغلب همان عنصر LCP (Largest Contentful Paint) است که Google اندازه می‌گیرد. بهینه‌سازی تصاویر به معنای کیفیت پایین‌تر نیست؛ یعنی ارسال همان تصویر با بایت‌های بسیار کمتر. این را درست انجام دهید و همه‌چیز دیگر — LCP، امتیازهای موبایل، مصرف داده — یک‌جا بهبود می‌یابد.

اندازه‌گذاری درست و واکنش‌گرا شدن

رایج‌ترین اتلاف، سرویس‌دادن یک تصویر عظیم در یک فضای کوچک است — یک عکس 4000 پیکسلی که در 800 پیکسل نمایش داده می‌شود باز هم تمام 4000 پیکسل را دانلود می‌کند. تصاویر را نزدیک به اندازه‌ای که واقعاً نمایش داده می‌شوند صادر کنید. سپس با srcset و sizes اندازه‌های مختلف را به صفحه‌نمایش‌های مختلف سرویس دهید، تا یک تلفن یک فایل کوچک و یک دسکتاپ یک فایل بزرگ‌تر بگیرد.

تصاویر واکنش‌گرا با srcset

<img
  src="/hero-800.jpg"
  srcset="/hero-400.jpg 400w, /hero-800.jpg 800w, /hero-1600.jpg 1600w"
  sizes="(max-width: 600px) 400px, 800px"
  alt="Product hero"
  width="800" height="500">

به فرمت‌های نسل جدید سوئیچ کنید: WebP و AVIF

روی عکس‌ها، WebP و AVIF با همان کیفیت بصری فایل‌هایی بسیار کوچک‌تر از JPEG تولید می‌کنند: در اندازه‌گیری ما یک عکس 1920×1080 در قالب JPEG بهینه‌شده 186 کیلوبایت بود و در WebP به 114 و در AVIF به 87 کیلوبایت رسید. روی اسکرین‌شات‌ها، گرافیک‌های تخت و آیکون‌های ریز این فاصله کم یا حتی برعکس می‌شود، پس بایت‌ها را مقایسه کنید (عددها در راهنمای AVIF یا WebP آمده‌اند). این همان تغییری است که توصیه 'تصاویر را با فرمت‌های نسل جدید سرویس دهید' در PageSpeed Insights را برطرف می‌کند. اگر فایل‌ها را خودتان میزبانی می‌کنید، آن‌ها را با یک عنصر picture سرویس دهید تا مرورگرهایی که از فرمت جدید پشتیبانی می‌کنند آن را بگیرند و مرورگرهای قدیمی‌تر به‌طور خودکار به نسخه اصلی بازگردند. روی لبه CDN.com.tr یک URL کافی است: لبه هدر Accept مرورگر را می‌خواند و برای هر درخواست فرمت را خودش انتخاب می‌کند.

سرویس AVIF/WebP همراه با نسخه جایگزین

<picture>
  <source srcset="/photo.avif" type="image/avif">
  <source srcset="/photo.webp" type="image/webp">
  <img src="/photo.jpg" alt="Photo" width="1200" height="800">
</picture>

lazy-load کنید — اما نه تصویر اصلی خود را

lazy-loading تصاویر را تا زمانی که در آستانه ورود به viewport باشند به تعویق می‌اندازد، تا یک صفحه بلند همه‌چیز را از همان ابتدا دانلود نکند. بیشتر پلتفرم‌ها این کار را به‌طور پیش‌فرض انجام می‌دهند. تنها استثنا تصویر hero یا تصویر اصلی شماست، که معمولاً عنصر LCP است: آن را با اولویت بارگذاری کنید (و fetchpriority="high" را در نظر بگیرید) تا مهم‌ترین پیکسل هرچه سریع‌تر ترسیم شود. هر چیز زیر خط تا را lazy-load کنید، و آن یک چیز بالای آن را در اولویت بگذارید.

از edge تحویل دهید — و به‌طور خودکار تبدیل کنید

حتی یک تصویر کاملاً فشرده‌شده هم کند است اگر از یک سرور دوردست سفر کند. یک CDN تصاویر شما را در edge کش می‌کند و هر بازدیدکننده را از نزدیک‌ترین مکان سرویس می‌دهد، تا بایت‌ها هرجا که باشند سریع برسند. cdn.com.tr این کار را برای هر دارایی، روی HTTP/2 و Brotli مدرن، و با SSL خودکار در جلو انجام می‌دهد.

و لازم نیست فرمت‌ها را دستی تبدیل کنید. برای WordPress، افزونه رایگان CDNTR روی سرور خودتان WebP (و AVIF در جایی که سرورتان پشتیبانی می‌کند) می‌سازد و آن‌ها را از طریق یک عنصر picture از CDN سرویس می‌دهد، با نسخه اصلی به‌عنوان جایگزین خودکار. تنها زمانی یک فایل تبدیل‌شده را سرویس می‌دهد که واقعاً کوچک‌تر باشد، پس یک عکس خوب‌فشرده‌شده هرگز بزرگ‌تر نمی‌شود، و می‌تواند کل کتابخانه رسانه شما را به‌صورت گروهی تبدیل کند.

روی هر سایتی پشت cdn.com.tr، بهینه‌سازی تصویر تبدیل را روی لبه انجام می‌دهد: آن را برای حساب یا یک قانون تحویل روشن کنید تا تصاویر JPEG و PNG بدون تغییر URLهایشان به‌صورت WebP به مرورگرهای سازگار برسند، یا به‌صورت AVIF اگر برای حساب WebP + AVIF را انتخاب کنید. در اندازه کامل، تصویری که تازه تبدیل شده فقط وقتی ارسال می‌شود که از نسخه اصلی کوچک‌تر باشد؛ اگر تبدیل شکست بخورد، لبه به‌جای آن نسخه اصلی را سرویس می‌دهد. پردازش از سهمیه ماهانه شما کسر می‌شود. بررسی‌کنندهٔ فرمت تصویر نشان می‌دهد هر کدام از تصاویر شما با چه فرمتی به مرورگر می‌رسد. راهنمای CDN تصویر ما سمت لبه را با جزئیات بیشتری توضیح می‌دهد: یک URL که با چند قالب پاسخ می‌دهد، تغییر اندازه با URL و اینکه چرا هر نسخه یک شیء جداگانه در کش است.

اندازه‌گیری و تأیید

صفحه خود را پیش و پس از تغییر از PageSpeed Insights عبور دهید. دنبال دو چیز هستید: ناپدید شدن توصیه‌های 'تصاویر را با فرمت‌های نسل جدید سرویس دهید' و 'تصاویر را به‌درستی اندازه‌گذاری کنید'، و افت LCP شما. اگر بزرگ‌ترین تصویر همچنان کند است، بررسی کنید که lazy-load نشده باشد و با یک فرمت نسل جدید از CDN سرویس شود. یک مقایسه سریع پیش/پس شما را نسبت به آنچه واقعاً کمک کرده صادق نگه می‌دارد.

کجا بیشترین بازده را دارد