AVIF یا WebP؟ راهنمای Benchmark، Fallback و Production

تیم فروشگاه همه تصاویر را به AVIF تبدیل می‌کند و انتظار دارد LCP فوراً بهتر شود؛ اما Hero هنوز دو برابر عرض نمایشگر است، از JavaScript دیر کشف می‌شود و روی چند گوشی ضعیف Decode سنگینی دارد. تیم دیگری فقط WebP می‌سازد، ولی برای عکس‌های پرجزئیات فرصت کاهش حجم را از دست می‌دهد. پرسش درست «AVIF یا WebP کدام بهتر است؟» نیست؛ پرسش این است که برای هر خانواده تصویر، دستگاه و مسیر تحویل، کدام خروجی بهترین نسبت کیفیت، بایت و هزینه اجرا را می‌سازد.

این راهنما مالک انتخاب Format و Pipeline تولید/تحویل است: Capability، Browser matrix، Benchmark، Responsive variants، Fallback، CDN/cache، LCP، امنیت، Rollout و Rollback. برای زنجیره عمومی‌تر تصویر و ویدئو—از Asset contract تا Accessibility و SEO—راهنمای تصویر و ویدئو در طراحی سایت مکمل این مقاله است.

پاسخ کوتاه: AVIF، WebP یا هر دو؟

• AVIF برای بسیاری از عکس‌ها در Quality بصری مشابه می‌تواند فایل کوچک‌تری بسازد و HDR/WCG/عمق رنگ بالاتر را پشتیبانی می‌کند؛ اما نتیجه به Encoder، تنظیم، محتوا و Client وابسته است.
• WebP اکوسیستم بالغ و سابقه پشتیبانی بیشتری دارد و برای عکس، Lossless، Alpha و Animation گزینه عملی است؛ ولی در هر Corpus برنده بایت نیست.
• JPEG/PNG هنوز به‌عنوان Fallback، Source یا نیازهای خاص بی‌معنا نشده‌اند؛ SVG برای گرافیک برداری و متن/آیکن غالباً مناسب‌تر است.
• Production امن معمولاً AVIF → WebP → JPEG/PNG را با <picture> یا یک سرویس Negotiation درست ارائه می‌کند، اما ساخت سه فرمت برای هر Asset فقط وقتی TCO و Coverage آن توجیه شود.

فرمت را با داده همان سایت انتخاب کنید. درصد صرفه‌جویی عمومی، جای Benchmark روی عکس محصول، Screenshot، پرتره، بافت، Transparency و دستگاه کاربران شما را نمی‌گیرد.

AVIF چیست؟

AVIF یا AV1 Image File Format، بیت‌استریم AV1 را در ساختار فایل تصویری حمل می‌کند. طبق مشخصات Alliance for Open Media، حالت Lossy/Lossless، Alpha، Animation، HDR و Wide Color Gamut را پشتیبانی می‌کند. Capability استاندارد با پشتیبانی کامل در Encoder، CMS، مرورگر و Pipeline شما یکی نیست؛ هر Feature لازم باید End-to-end تست شود.

مزیت احتمالی Compression رایگان نیست. Encode ممکن است CPU/زمان بیشتری بخواهد و Quality knob دو Encoder قابل مقایسه عددی نیست. AVIF با کیفیت ۶۰ الزاماً معادل WebP با کیفیت ۶۰ نیست. برای فایل بزرگ نیز نباید به Progressive experience فرضی تکیه کنید مگر رفتار واقعی Client و ابزار تولید را سنجیده باشید.

WebP چیست؟

WebP فرمت تصویری گوگل با حالت Lossy و Lossless، Alpha و Animation است. Lossy آن بر VP8 و Lossless آن بر Coding جداگانه تکیه دارد. پشتیبانی تاریخی مرورگر و ابزار آن از AVIF عمیق‌تر است و cwebp کنترل‌هایی برای Quality، Preset، Lossless، Resize و سرعت ارائه می‌دهد.

WebP هم «یک تنظیم مناسب همه تصاویر» ندارد. Screenshot رابط با متن ریز، عکس پرنویز، تصویر شفاف محصول و Texture نیازهای متفاوتی دارند. Lossless WebP می‌تواند برای بعضی PNGها خوب باشد، اما PNG palette-optimized یا SVG ممکن است هنوز خروجی مناسب‌تری بسازد.

جدول مقایسه Capability؛ شروع تصمیم، نه پایان آن

راهنمای Format تصویر در MDN جزئیات MIME، Color mode، مرورگر و محدودیت هر فرمت را جمع کرده است. این جدول باید با Browser matrix و ابزار نسخه‌دار پروژه شما تکمیل شود.

Browser support را با کاربران خود بسنجید

عبارت «همه مرورگرهای مدرن» برای تصمیم Production کافی نیست. Analytics را با User-agent/Client hints معتبر، OS، Browser، WebView و نسخه اپ بررسی کنید. مرورگر درون پیام‌رسان، تلویزیون، WebView قدیمی یا Library نمایش تصویر ممکن است با مرورگر اصلی همان گوشی فرق داشته باشد.

Fallback حتی با Coverage بالا ارزش دارد، چون Failure فقط عدم پشتیبانی Format نیست: MIME اشتباه، فایل خراب، Encoder regression، CDN cache collision یا Decoder bug نیز ممکن است رخ دهد. Support table عمومی را Snapshot کنید، اما Acceptance را روی دستگاه‌های نماینده انجام دهید.

«۳۰ درصد کوچک‌تر» قانون نیست

اعداد مقایسه از Dataset، Source، Encoder/version، Speed، Chroma subsampling، Bit depth، Resize، Quality target و Metric اثر می‌گیرند. AOMedia می‌تواند نتیجه مرجع خود را گزارش کند و مطالعات دیگر عدد متفاوت بسازند. آن عدد برای Planning اولیه مفید است، نه SLA سایت شما.

مقایسه باید در کیفیت ادراکی مشابه انجام شود، نه با Quality slider برابر یا File size برابر بدون بررسی Artifact. Hair، متن، لبه پرکنتراست، Gradient، Noise و پوست به Artifactهای متفاوت حساس‌اند. برای عکاسی محصول نیز تغییر رنگ می‌تواند از چند کیلوبایت صرفه‌جویی پرهزینه‌تر باشد؛ راهنمای عکاسی محصول و کنترل رنگ این مرز را تکمیل می‌کند.

Corpus نماینده بسازید

حداقل چند ده Asset از Templateهای واقعی بردارید: Hero، کارت محصول، Gallery، Avatar، Screenshot، نمودار، تصویر شفاف، عکس کم‌نور، بافت، Gradient و تصویر دارای متن. سهم هر گروه را با Pageview و بایت فعلی وزن دهید. Corpus محرمانه را در محیط کنترل‌شده نگه دارید.

Source باید Master معتبر باشد؛ خروجی JPEG کم‌کیفیت را دوباره به AVIF و WebP تبدیل نکنید و نتیجه را «بهبود» ننامید. Crop، Resize، Orientation، ICC/EXIF و Alpha preprocessing را یکسان کنید. ابعاد خروجی را پیش از Format مشخص کنید؛ یک JPEG درست‌اندازه ممکن است از AVIF بزرگ‌ابعاد سریع‌تر باشد.

ماتریس Encode را منصفانه اجرا کنید

برای هر Asset و Width، چند نقطه Quality و Speed بسازید. Version کتابخانه، Codec backend، CPU، Thread، زمان، Peak memory و Command را ثبت کنید. عدد Quality میان ابزارها فقط پارامتر داخلی است؛ مقایسه را با خروجی بصری انجام دهید.

# نمونه آموزشی؛ نقطه شروع است، نه Quality معادل
cwebp -q 82 -mt input.png -o output.webp
avifenc -q 70 -s 6 -j all input.png output.avif

مستند رسمی cwebp و avifenc گزینه‌های جاری را شرح می‌دهند. نسخه را Pin و Release note را در Upgrade بررسی کنید؛ تغییر Encoder ممکن است File size، Color یا زمان Build را جابه‌جا کند.

کیفیت را با Metric و چشم انسان بسنجید

PSNR یا SSIM به‌تنهایی معادل ادراک نیست. یک Metric ادراکی مناسب و Inspection انسانی را کنار هم بگذارید. Zoom صددرصد و اندازه نمایش واقعی هر دو لازم‌اند. لبه متن، Banding آسمان، پوست، مو، Grain، Transparency halo و Color shift را با Source مرجع مقایسه کنید.

خروجی خوب معمولاً یک Pareto frontier است: چند Candidate که با بایت کمتر کیفیت یا هزینه پردازش را بهتر می‌کنند. Policy می‌تواند برای Photo از AVIF شروع کند، برای Screenshot WebP/Lossless را ترجیح دهد و برای Logo سراغ SVG برود.

Decode، حافظه و دستگاه ضعیف را فراموش نکنید

تصویر فشرده ۸۰KB پس از Decode می‌تواند چند مگابایت Bitmap بسازد؛ ابعاد و تعداد هم‌زمان تصاویر بر Memory و Scroll اثر دارد. Encoding روی CI/Server رخ می‌دهد، اما Decode روی گوشی کاربر است. Pixel count، DPR، List density و Lifecycle تصویر را همراه Format آزمایش کنید.

یک Grid با صد Thumbnail، Hero بزرگ و Zoom محصول سناریوهای متفاوتی‌اند. CPU throttling مصنوعی مفید است، ولی دستگاه واقعی Android اقتصادی و Safari/iOS و WebView پرتکرار را هم بسنجید. «WebP همیشه Decode سریع‌تر است» یا «AVIF همیشه کند است» را بدون Version/device/corpus گزارش نکنید.

Responsive image از انتخاب Format مهم‌تر می‌شود

برای هر Format، Width ladder متناسب با Slotهای واقعی تولید کنید و با srcset/sizes به مرورگر اجازه انتخاب دهید. Ladder کور ۳۲۰ تا ۲۵۶۰ برای هر Asset، Storage و Build را منفجر می‌کند. از داده Layout و DPR کاربران، Widthهای لازم را استخراج کنید.

<picture>
  <source type="image/avif"
          srcset="product-480.avif 480w, product-960.avif 960w"
          sizes="(max-width: 600px) 92vw, 560px">
  <source type="image/webp"
          srcset="product-480.webp 480w, product-960.webp 960w"
          sizes="(max-width: 600px) 92vw, 560px">
  <img src="product-960.jpg"
       srcset="product-480.jpg 480w, product-960.jpg 960w"
       sizes="(max-width: 600px) 92vw, 560px"
       width="960" height="720"
       alt="کفش چرمی قهوه‌ای از نمای سه‌رخ">
</picture>

مرورگر Sourceها را به‌ترتیب Capability بررسی می‌کند و img هم عنصر اصلی/جایگزین، محل Alt، Width/Height و رفتار Load است. مثال رسمی عنصر picture در MDN AVIF → WebP → fallback را نشان می‌دهد.

Fallback درست چه شرایطی دارد؟

• type="image/avif" و type="image/webp" صحیح باشد.
• سرور نیز Content-Type متناظر بفرستد؛ فقط Extension را عوض نکنید.
• img src URL معتبر JPEG/PNG داشته باشد، نه Placeholder شکسته.
• Crop/محتوای همه Candidateها معنای یکسان داشته باشد مگر Art direction عمدی.
• Alt فقط روی img و براساس هدف تصویر نوشته شود.
• Width/height یا aspect-ratio فضای Layout را رزرو کند.

اگر CMS/Service براساس Accept header همان URL را Negotiation می‌کند، Vary: Accept، Cache key، Purge و CDN behavior را آزمایش کنید. مخلوط‌شدن Variant در Cache می‌تواند AVIF را به Client ناسازگار بدهد یا Hit ratio را کاهش دهد. معماری Cache در راهنمای CDN پیشرفته پوشش داده شده است.

LCP فقط با کوچک‌شدن فایل حل نمی‌شود

LCP شامل TTFB، Resource load delay، Resource load duration و Element render delay است. فرمت بیشتر روی بایت و بخشی از Load/Decode اثر دارد؛ Hero کشف‌نشده، Lazy-load شده، Priority پایین یا Render-blocked همچنان دیر ظاهر می‌شود. عنصر LCP را در Field و Template واقعی پیدا کنید.

تصویر LCP باید در HTML قابل کشف باشد و معمولاً Lazy نشود. fetchpriority="high" یک Hint است و Preload تعهد Fetch؛ هر دو را پس از مشاهده waterfall استفاده کنید، نه روی چند تصویر. راهنمای Core Web Vitals و RUM مرز Lab/Field و p75 را توضیح می‌دهد.

Lazy loading را متناسب با Viewport اعمال کنید

تصاویر زیر Fold می‌توانند loading="lazy" داشته باشند، اما اولین Gallery row یا Hero را کورکورانه Lazy نکنید. Placeholder باید نسبت ابعاد را حفظ کند. Infinite scroll به Pagination/URL/Accessibility و Memory lifecycle نیاز دارد؛ Format کوچک به‌تنهایی Long page را حل نمی‌کند.

برای تصویر بسیار دور، decoding="async" ممکن است مفید باشد، اما رفتار و اولویت را روی Browser matrix بسنجید. هدف، کمترین تعداد Attribute نیست؛ ترتیب درست Discovery، Fetch، Decode و Paint است.

CMS و Pipeline تولید: On-demand یا Build-time؟

سه الگوی رایج داریم: تولید هنگام Upload/Build، Image CDN on-demand و Hybrid. Build-time هزینه Runtime را کم می‌کند ولی Storage و زمان Deploy را بالا می‌برد. On-demand Variant انعطاف دارد ولی First request، Cache stampede، Vendor cost و Lock-in اضافه می‌کند. Hybrid Widthهای پرتکرار را از قبل و Long-tail را در درخواست می‌سازد.

Pipeline باید Idempotent باشد: Asset ID + Source checksum + transform policy + encoder version → خروجی یکتا. Job state، Retry، Dead letter، Timeout، Resource limit و Fallback لازم است. Request کاربر نباید منتظر Encode سنگین بدون سقف بماند.

variant_key = hash(source_checksum,
                   width, crop, format, quality_policy,
                   encoder_name, encoder_version)

Storage و TCO سه‌فرمتی

AVIF+WebP+JPEG برای چند Width تعداد Variant را ضرب می‌کند. Storage ارزان ممکن است باشد، اما Encode CPU، Build time، Cache، Purge، Backup، Log، Migration و پیچیدگی QA نیز هزینه‌اند. ارزش پوشش WebP یا Legacy fallback را با سهم Traffic و Risk بسنجید.

CDN و ایران: مسیر واقعی را تست کنید

پشتیبانی Browser تنها بخشی از Availability است. CDN باید MIME، Range در صورت نیاز، Cache key، Purge و Variant URL را درست تحویل دهد. از چند ISP ثابت/موبایل و شهر، زمان اوج، Cold/Warm cache و دستگاه‌های پرتکرار ایران تست کنید. برای طراحی Probe و انتخاب Provider، راهنمای راه‌اندازی CDN برای سایت ایرانی مفید است.

اگر Image service خارجی استفاده می‌کنید، Eligibility، Terms، Payment، FX، Support، Data location، Origin egress و Exit را تاریخ‌دار بررسی کنید. URL اختصاصی و امکان بازسازی Variant از Master، ریسک Vendor lock-in را کاهش می‌دهد.

امنیت: فرمت مدرن ذاتاً امن‌تر نیست

Decoder/Encoder نرم‌افزار است و ممکن است Vulnerability داشته باشد. فایل Upload را با Magic bytes/MIME، ابعاد، Pixel count، Frame count، Metadata و سقف Resource اعتبارسنجی کنید. پردازش را Sandbox و Library را Patch کنید؛ Timeout، Memory/CPU limit و Queue isolation داشته باشید. Extension کاربر قابل اعتماد نیست.

Decompression bomb، تصویر بسیار بزرگ، Animation طولانی یا Metadata مخرب می‌تواند منابع را مصرف کند. Original محرمانه را عمومی نکنید و EXIF/GPS را طبق Policy نگه دارید یا حذف کنید. فرمت، جای Access control، Malware scanning یا Content Security Policy نیست.

SEO: گوگل هر دو فرمت را پشتیبانی می‌کند

راهنمای رسمی Google Images AVIF و WebP را در فهرست فرمت‌های پشتیبانی‌شده دارد و توصیه می‌کند تصویر با img src قابل کشف باشد؛ Google تصاویر CSS background را Index نمی‌کند. هنگام picture نیز یک img src fallback معتبر نگه دارید.

فرمت Keyword یا عامل محتوایی نیست. صفحه مقصد، متن/Caption/Alt مناسب، URL پایدار، دسترسی Crawler، Image sitemap در صورت نیاز و کیفیت Thumbnail مهم‌اند. راهنمای سئوی محتوای غیرمتنی مالک Search intent و Asset evidence است.

Discover و تصاویر بزرگ

انتخاب AVIF یا WebP به‌خودی‌خود ورود به Discover را تضمین نمی‌کند. ابعاد/کیفیت، Rights، محتوای صفحه و Eligibility جدا هستند. برای Card image، Crop در نسبت‌های مختلف و وضوح واقعی را تست کنید؛ فایل کوچک اما تار یا Crop مخرب هدف را شکست می‌دهد. راهنمای بهینه‌سازی Google Discover Card contract و اندازه‌گیری را جداگانه پوشش می‌دهد.

آزمایش Production و RUM

پس از Lab، درصدی از Traffic یا چند Template را Rollout کنید. Bytes transferred، Content-Type، selected currentSrc، LCP subparts، decode/render timing در حد داده قابل اتکا، error، memory/crash telemetry، CDN hit و Outcome را به تفکیک Device/Network/Format بسنجید. Privacy و حجم Telemetry را کنترل کنید.

نرخ تبدیل یا Bounce را مستقیماً به Format نسبت ندهید مگر طراحی آزمایش اجازه دهد. تغییر هم‌زمان Crop، Quality، Width و Lazy policy Attribution را مبهم می‌کند. تغییرات را مرحله‌ای و با Release marker منتشر کنید؛ راهنمای سرعت سایت، UX و تبدیل مرز Performance metric و Outcome را توضیح می‌دهد.

Rollout امن در شش مرحله

1. Inventory: Asset class، Template، Width، Source، بایت و ترافیک را استخراج کنید.
2. Corpus/Benchmark: Quality-size-encode-decode Pareto را برای هر Class بسازید.
3. Policy: Format/width/quality/fallback/LCP/lazy rules را Version کنید.
4. Shadow generation: Variantها را بدون Serve عمومی بسازید و Integrity/Color/Alpha را QA کنید.
5. Canary: یک Template و درصد محدود را با RUM/CDN log منتشر کنید.
6. Scale/Rollback: پس از Guardrail، توسعه دهید؛ Manifest قبلی و Purge plan را نگه دارید.

چک‌لیست Production برای AVIF و WebP

• Corpus واقعی و Asset class تعریف شده است.
• Resize/Crop/Color/Alpha preprocessing میان Candidateها یکسان است.
• Encoder، Version، Command، Speed، CPU و زمان ثبت شده‌اند.
• Quality slider برابر به‌عنوان Quality بصری برابر استفاده نشده است.
• File size، Metric ادراکی، Human review و Device decode بررسی شده‌اند.
• picture، srcset، sizes، MIME، fallback و dimensions درست‌اند.
• LCP discoverability/priority و Lazy policy جدا از Format سنجیده شده‌اند.
• Cache key/Vary/Purge/immutable URL و Variant version آزمایش شده‌اند.
• Upload validation، Sandbox، Resource limit و Library patch برقرار است.
• Canary، RUM، Guardrail، Rollback و TCO تأیید شده‌اند.

سؤالات متداول درباره AVIF و WebP

۱. آیا AVIF همیشه از WebP کوچک‌تر است؟

خیر. در بسیاری از عکس‌ها مزیت دارد، اما نتیجه به Content، Encoder/version، Speed، Chroma، Resize و Quality target وابسته است. Corpus واقعی را در کیفیت ادراکی مشابه Benchmark کنید؛ Quality عددی برابر مقایسه منصفانه‌ای نیست.

۲. آیا WebP در حال منسوخ‌شدن است؟

خیر. WebP پشتیبانی و ابزار بالغی دارد و می‌تواند خروجی اصلی یا Fallback مفیدی باشد. معماری Production را بر پیش‌بینی تاریخ مرگ Format نسازید؛ بر Browser matrix، Asset class، TCO و داده واقعی تکیه کنید.

۳. AVIF و WebP مستقیماً رتبه سئو را بهتر می‌کنند؟

فرمت به‌خودی‌خود تضمین رتبه نیست. کاهش بایت ممکن است Load را بهتر کند، اما LCP به TTFB، کشف، اولویت، Decode و Render هم وابسته است. Google هر دو را پشتیبانی می‌کند؛ قابلیت Crawl، صفحه مقصد و Metadata نیز لازم‌اند.

۴. ترتیب source در picture چگونه باشد؟

اگر Policy شما AVIF را ترجیح می‌دهد، Source AVIF را اول، WebP را بعد و img src JPEG/PNG را fallback بگذارید. Browser نخستین Source سازگار را انتخاب می‌کند. MIME، srcset/sizes و معادل‌بودن محتوای Candidateها را تست کنید.

۵. برای Logo، Screenshot و Animation چه کنیم؟

Logo/آیکن هندسی معمولاً SVG، Screenshot متنی ممکن است PNG یا WebP lossless و Animation طولانی غالباً Video مناسب‌تری باشد. پاسخ را از Requirement—برداری‌بودن، Alpha، متن، Loop، Accessibility و Size—و Benchmark بگیرید، نه از یک Format پیش‌فرض.

موضوعات مکمل برای توسعه این خوشه

۱. Benchmark خودکار Quality–Size برای تصاویر فارسی

Corpus شامل متن RTL، فونت فارسی، عکس محصول، Gradient و Transparency همراه نسخه‌گذاری Encoder، Metric ادراکی و Human review می‌تواند Policy بومی قابل‌اعتماد بسازد.

۲. معماری Image CDN با Variant key و Cache contract

راهنمایی فنی برای Accept negotiation، Vary/cache key، Signed transform، width allowlist، stampede، purge، cost و origin protection خلأ مهم Production است.

۳. RUM انتخاب تصویر و LCP subparts

ثبت privacy-safe از currentSrc، format، intrinsic/displayed size، bytes، LCP resource delay/duration/render delay و device cohort، تصمیم Format را به تجربه واقعی وصل می‌کند.

جمع‌بندی

AVIF و WebP رقیب‌هایی با یک برنده همیشگی نیستند؛ ابزارهایی در یک Pipeline‌اند. AVIF می‌تواند برای بسیاری از عکس‌ها بایت کمتری بسازد و WebP پوشش و ابزار بالغی دارد، اما ابعاد درست، Crop، Responsive variants، کشف LCP، Cache و امنیت گاهی اثر بزرگ‌تری دارند. Corpus خود را بسازید، در کیفیت ادراکی مشابه Benchmark کنید، Fallback معتبر بدهید و با Canary/RUM/rollback منتشر کنید. بهترین Format همان خروجی‌ای است که روی کاربران واقعی، کیفیت لازم را با کمترین هزینه کل تحویل می‌دهد.