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

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

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

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

رایج‌ترین اتلاف، سرویس‌دادن یک تصویر عظیم در یک فضای کوچک است — یک عکس ۴۰۰۰ پیکسلی که در ۸۰۰ پیکسل نمایش داده می‌شود باز هم تمام ۴۰۰۰ پیکسل را دانلود می‌کند. تصاویر را نزدیک به اندازه‌ای که واقعاً نمایش داده می‌شوند صادر کنید. سپس با 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 یا PNG با همان کیفیت بصری تولید می‌کنند. این همان تغییری است که توصیه 'تصاویر را با فرمت‌های نسل جدید سرویس دهید' در PageSpeed Insights را برطرف می‌کند. آن‌ها را با یک عنصر picture سرویس دهید تا مرورگرهایی که از فرمت جدید پشتیبانی می‌کنند آن را بگیرند و مرورگرهای قدیمی‌تر به‌طور خودکار به نسخه اصلی بازگردند.

سرویس 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 سرویس می‌دهد، با نسخه اصلی به‌عنوان جایگزین خودکار. تنها زمانی یک فایل تبدیل‌شده را سرویس می‌دهد که واقعاً کوچک‌تر باشد، پس یک عکس خوب‌فشرده‌شده هرگز بزرگ‌تر نمی‌شود، و می‌تواند کل کتابخانه رسانه شما را به‌صورت گروهی تبدیل کند.

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

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

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