AVIF یا WebP: کدام کوچک‌تر است و چه زمانی

AVIF و WebP چه هستند

WebP فرمت تصویر گوگل است که در سال 2010 معرفی شد. حالت با اتلاف آن یک تصویر را همان‌طور فشرده می‌کند که کدک ویدیویی VP8 یک فریم را؛ یک حالت بی‌اتلاف جداگانه به نام VP8L برای گرافیک‌هایی با لبه‌های تیز و رنگ‌های کم طراحی شده است. هر دو حالت از شفافیت پشتیبانی می‌کنند و WebP متحرک می‌تواند جای GIF را بگیرد.

AVIF (AV1 Image File Format) یک فریم فشرده‌شده با AV1، کدک ویدیویی بدون حق امتیاز Alliance for Open Media، را درون یک ظرف HEIF نگه می‌دارد. مشخصات نسخهٔ 1.0 آن در سال 2019 منتشر شد. ابزارهای کدگذاری AV1 یک دهه از ابزارهای VP8 جدیدترند، پس AVIF در عکس‌ها جزئیات بیشتری به ازای هر بایت حفظ می‌کند و رنگ 10 و 12 بیتی و HDR را هم اضافه می‌کند. بهای آن زمان کدگذاری است: ساختن یک AVIF به‌طور محسوسی CPU بیشتری از WebP همان تصویر می‌برد، و به همین دلیل سرویس‌های تصویر هر تصویر را یک بار تبدیل می‌کنند و نتیجه را کش می‌کنند.

پشتیبانی مرورگرها دیگر پرسش تعیین‌کننده نیست. طبق caniuse.com (داده‌های 30 سپتامبر 2026)، حدود 97٪ مرورگرهای در حال استفاده WebP و حدود 95٪ آن‌ها AVIF را نمایش می‌دهند. WebP از Chrome 32، Firefox 65 و Safari 14 (روی macOS 11 یا جدیدتر) کار می‌کند؛ AVIF از Chrome 85، Firefox 93، Safari در iOS 16، Safari 16.4 روی Mac (تصاویر ثابت از Safari 16.1، روی macOS 13 Ventura یا جدیدتر) و Edge 121. همین چند درصد باقی‌مانده دلیل اهمیت یک جایگزین است، و وقتی انتخاب فرمت در سرور انجام شود این جایگزین هزینه‌ای ندارد.

کدام کوچک‌تر است؟ به تصویر بستگی دارد

بیشتر مقایسه‌ها یک عدد می‌گویند، «WebP سی درصد کوچک‌تر است» یا «AVIF تصویرهایتان را نصف می‌کند»، که میانگینی روی عکس‌هاست. اما یک سایت واقعی اسکرین‌شات، لوگو و آیکون هم سرو می‌کند و آنجا ترتیب ممکن است برعکس شود. در 5 اکتبر 2026 چهار تصویر را با تنظیمات واقعی محیط عملیاتی از بهینه‌ساز تصویری که پشت CDN.com.tr کار می‌کند گذراندیم و بایت‌هایی را که هر فرمت تولید کرد شمردیم.

عکس خبری با فرمت JPEG، در ابعاد 1920×1080. اصلی 262,025 بایت؛ JPEG بهینه‌شده 186,137؛ WebP 113,860؛ AVIF 86,936. نمونهٔ کلاسیک: WebP نسبت به JPEG بهینه‌شده 39٪ کوچک‌تر است و AVIF باز هم 24٪ از WebP کوچک‌تر، یعنی یک‌سوم بایت‌های فایل اصلی.

عکس خبری با فرمت JPEG، در ابعاد 926×594. اصلی 131,472 بایت؛ JPEG بهینه‌شده 93,348؛ WebP 89,360؛ AVIF 77,452. همان نوع تصویر، کوچک‌تر و از قبل خوب فشرده‌شده: در برابر JPEG، صرفه‌جویی WebP فقط 4٪ و صرفه‌جویی AVIF برابر 17٪ است.

اسکرین‌شات پنل با فرمت PNG، در ابعاد 1156×775. اصلی 105,078 بایت؛ PNG بهینه‌شده (pngquant و optipng) 40,379؛ WebP 41,218؛ AVIF 27,942. رنگ‌های تخت و متن نقطهٔ قوت PNG پالت‌دار است: WebP به اندازهٔ 839 بایت از PNG بزرگ‌تر درآمد، در حالی که AVIF همچنان 31٪ از آن کوچک‌تر بود.

فاویکون با فرمت PNG، در ابعاد 16×16. اصلی 701 بایت؛ PNG بهینه‌شده 483؛ WebP 314؛ AVIF 682. در این اندازه ظرف فایل تعیین‌کننده است: 429 بایت از 682 بایت AVIF جعبه‌های HEIF هستند که پیش از هر پیکسلی تصویر را توصیف می‌کنند، در حالی که پوشش WebP فقط 46 بایت است. AVIF در نهایت 41٪ از PNG بزرگ‌تر شد و WebP کوچک‌ترین بود.

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

سرور چطور فرمت را انتخاب می‌کند

هر درخواست تصویر یک هدر Accept دارد که فرمت‌هایی را که مرورگر می‌تواند نمایش دهد فهرست می‌کند. Chrome مقدار image/avif,image/webp,image/apng,image/svg+xml,image/*,*/*;q=0.8 را می‌فرستد؛ مرورگری که از AVIF پشتیبانی نمی‌کند image/avif را نمی‌آورد. سرور یا CDNی که تصویر تبدیل می‌کند این فهرست را می‌خواند و به همان URL با AVIF، WebP یا فایل اصلی پاسخ می‌دهد. نام فایل تغییر نمی‌کند، پس hero.png ممکن است به‌صورت AVIF برسد: آنچه فرستاده شده را هدر Content-Type می‌گوید، نه پسوند.

چون یک URL حالا چند پاسخ ممکن دارد، پاسخ باید Vary: Accept داشته باشد. این هدر به هر کشی در مسیر، از CDN تا پراکسی شرکت و مرورگر، می‌گوید برای هر مقدار Accept نسخهٔ جداگانه‌ای نگه دارد. بدون آن، یک کش مشترک ممکن است فایل AVIFی را که یک بازدیدکننده گرفته به بازدیدکنندهٔ بعدی بدهد که مرورگرش نمی‌تواند آن را نمایش دهد.

راه دیگر انتخاب را به HTML منتقل می‌کند. یک عنصر <picture> فایل‌های <source> را با type="image/avif" و type="image/webp" فهرست می‌کند، مرورگر اولین نوعی را که پشتیبانی می‌کند برمی‌دارد، و <img> داخل آن جایگزین است. نه منطق سمت سرور لازم است و نه Vary، اما باید هر نسخه را خودتان بسازید و نگه دارید و نشانه‌گذاری را به‌روز نگه دارید. در هر دو حالت، برای دیدن آنچه مرورگر واقعاً می‌گیرد سه درخواست کافی است.

یک تصویر، سه هدر Accept: پاسخ‌ها را مقایسه کنید

# a browser that accepts AVIF and WebP
curl -so /dev/null -w '%{content_type} %{size_download} bytes\n' \
  -H 'Accept: image/avif,image/webp,*/*' https://example.com/hero.png

# a browser with WebP only
curl -so /dev/null -w '%{content_type} %{size_download} bytes\n' \
  -H 'Accept: image/webp,*/*' https://example.com/hero.png

# a client that asks for nothing in particular
curl -so /dev/null -w '%{content_type} %{size_download} bytes\n' \
  -H 'Accept: */*' https://example.com/hero.png

# the header that keeps shared caches honest (a GET, not HEAD)
curl -s -D - -o /dev/null -H 'Accept: image/avif,*/*' \
  https://example.com/hero.png | grep -i '^vary'

بررسی کنید سایت شما چه سرو می‌کند

بررسی‌کنندهٔ زیر همین درخواست‌ها را برای یک صفحهٔ کامل انجام می‌دهد. HTML صفحه را می‌خواند، تا 20 تصویر را از <img>، srcset، <picture> و og:image برمی‌دارد و هر کدام را دو بار درخواست می‌کند: یک بار مثل یک مرورگر امروزی (Accept: image/avif,image/webp,…) و یک بار مثل کلاینتی که همه‌چیز را می‌پذیرد (Accept: */*). بایت‌های اول هر پاسخ را می‌خواند تا فرمت واقعی را تشخیص دهد، هر چه نام فایل بگوید، بایت‌ها را می‌شمارد و Vary و وضعیت کش را گزارش می‌کند. نشانی یک تصویر تنها را هم می‌توانید وارد کنید.

درخواست‌ها از سرور ما در ترکیه فرستاده می‌شوند، پس ممکن است یک CDN از مکانی متفاوت با بازدیدکنندگان شما به ما پاسخ دهد. تصویرهایی که JavaScript پس از بارگذاری صفحه اضافه می‌کند و پس‌زمینه‌های CSS در HTML نیستند و بررسی نمی‌شوند. همهٔ محدودیت‌ها در صفحهٔ خود بررسی‌کننده آمده است.

خواندن نتیجه‌ها

AVIF یا WebP. مرورگری که فرمت‌های مدرن خواسته بود یکی از آن‌ها را گرفت. اندازهٔ کنار آن همان چیزی است که آن مرورگر دانلود کرد؛ ستون «سایر مرورگرها» چیزی است که هر مرورگر بدون پشتیبانی AVIF و WebP می‌گیرد. سطر صرفه‌جویی فقط تصویرهایی را جمع می‌زند که هر دو پاسخشان کامل خوانده شده و با فرمت‌های متفاوت رسیده‌اند: یک اندازه‌گیری است، نه تخمین.

فقط فرمت اصلی. حتی مرورگری که AVIF و WebP خواسته بود JPEG، PNG یا GIF گرفت؛ یعنی چیزی در مسیر تصویر را تبدیل نمی‌کند. اگر بعضی تصویرها AVIF می‌رسند و بعضی فقط با فرمت اصلی، ببینید گروه دوم چه وجه مشترکی دارد: میزبانی دیگر، مسیری که هیچ قانونی پوشش نمی‌دهد، پسوندی که مبدل از آن رد می‌شود.

یک فایل برای همهٔ مرورگرها. هر دو درخواست یک فرمت گرفتند. این نتیجهٔ سایتی است که انتخاب فرمت ندارد، و همچنین سایتی که از قبل به همه فایل .webp می‌دهد: همهٔ مرورگرهای امروزی آن را نمایش می‌دهند، اما صرفه‌جویی اضافهٔ AVIF بی‌استفاده می‌ماند. چون چیزی برای مقایسه نیست، صرفه‌جویی نشان داده نمی‌شود.

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

محدودیت نرخ یا مسدود شدن. بعضی سایت‌ها به درخواست‌های خودکار با 429، 403، یک بررسی ربات یا یک صفحهٔ کوچک 503 پاسخ می‌دهند. آن‌وقت بررسی‌کننده تا پایان آن بررسی دیگر به آن میزبان درخواست نمی‌فرستد و تصویرهای باقی‌مانده را «بررسی‌نشده» علامت می‌زند. این چیزی دربارهٔ محافظت سایت می‌گوید، نه دربارهٔ تصویرهایش: چند دقیقهٔ بعد دوباره امتحان کنید، یا نشانی یک تصویر را مستقیم بررسی کنید.

یک راهبرد معقول: اول AVIF، بعد WebP، هرگز بزرگ‌تر

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

بعد قاعده‌ای را اضافه کنید که فاویکون ما یادمان داد: بایت‌ها را تصویر به تصویر مقایسه کنید و هرگز فایل تبدیل‌شده‌ای نفرستید که از فایلی که در غیر این صورت می‌فرستادید بزرگ‌تر باشد. فرمت وسیله است؛ هدف بایت کمتر است. خط پردازشی که کورکورانه تبدیل می‌کند بخشی از تصویرهای شما را سنگین‌تر می‌کند و باز هم آن‌ها را «بهینه‌شده» گزارش می‌دهد.

دو نکتهٔ عملی. به‌جای تبدیل در هر درخواست، یک بار تبدیل کنید و نتیجه را کش کنید، روی لبهٔ یک CDN یا در مرحلهٔ build: بخش پرهزینه کدگذاری AVIF است. و لوگوها و آیکون‌هایی را که کشیده شده‌اند، نه عکاسی‌شده، تا جای ممکن SVG نگه دارید: چیزی برای تبدیل ندارند و روی هر صفحه‌نمایشی واضح می‌مانند.

AVIF و WebP در CDN.com.tr

بهینه‌سازی تصویر یک کلید در پنل است، برای کل حساب یا برای یک قانون تحویل. وقتی روشن باشد، لبه تصاویر JPEG و PNG را برای مرورگرهایی که پشتیبانی می‌کنند به‌صورت WebP سرو می‌کند؛ سرویس تصویر ما هر تصویر را یک بار تبدیل می‌کند و لبه نتیجه را کش می‌کند. برای حساب می‌توانید WebP + AVIF را هم انتخاب کنید: آن‌وقت مرورگرهایی که AVIF را می‌پذیرند AVIF می‌گیرند، سایر مرورگرهای مدرن WebP و بقیه تصویر را با فرمت اصلی‌اش، همه از همان URL، با Vary: Accept و یک نسخهٔ کش جداگانه برای هر فرمت.

پردازش از سهمیهٔ ماهانهٔ شما کسر می‌شود، و AVIF با نرخی بالاتر از WebP چون CPU بیشتری می‌برد؛ پنل نرخ را کنار کلید نشان می‌دهد. بررسی‌کنندهٔ بالا را روی صفحه‌های خودتان اجرا کنید تا تصویر به تصویر ببینید هر مرورگر چه فرمتی و با چند بایت دریافت می‌کند.