WebP mi AVIF mi: hangisi ne zaman kazanır

İkisi de aslında bir video codec'i

WebP, VP8'in anahtar kare kodlayıcısını RIFF kabına koyar; kayıpsız modu ise VP8 ile ilgisi olmayan ayrı bir algoritmadır. AVIF, AV1 codec'inin tek kare çıktısını HEIF (ISOBMFF) kabına koyar. Yani iki format da hareketli görüntü için tasarlanmış araçların durağan görsele uyarlanmış hali. Aralarındaki farkların çoğu bu mirastan geliyor: AV1 daha yeni ve daha güçlü bir codec, ama aynı zamanda çok daha pahalı bir kodlayıcı.

Önce sert sınırlar

Tartışmanın kalitesinden önce bakılması gereken şey, formatın neyi yapamadığı. Bunlar tercih değil, biçim tanımından gelen sınırlar.

WebP'nin 16383 piksel sınırı VP8'in genişlik ve yüksekliği 14 bitle saklamasından gelir. Uzun panoramalarda ya da büyük tarama çıktılarında bu sınıra beklediğinizden erken çarparsınız. Kayıplı WebP'nin 4:2:0 zorunluluğu ise daha sinsi: kroma kanalları her iki eksende yarıya inecek şekilde örneklenir, yani beyaz zemindeki kırmızı yazı ya da ince renkli çizgiler formatın yapısı gereği yumuşar. Kayıpsız WebP bu sorunu taşımaz, çünkü doğrudan RGBA üzerinde çalışır.

Ne kadar küçülüyor, sayılar kimin

Bu konuda dolaşan yüzdelerin çoğu kaynaksız. Doğrulanabilir olanlar şunlar:

• Google'ın WebP çalışması, aynı SSIM değerinde WebP dosyalarının JPEG'den %25-34 küçük olduğunu ölçüyor; WebP SSS sayfası ortalamayı %30 olarak veriyor.
• Aynı kaynağa göre kayıpsız WebP, PNG'ye kıyasla %26 daha küçük.
• web.dev'in AVIF yazısı, JPEG'e karşı %50'nin üzerinde tasarruf gördüklerini, ancak gerçek kazancın içeriğe, kodlayıcı ayarına ve hedef kaliteye bağlı olduğunu söylüyor.
• MDN, CTRL Blog'un karşılaştırmasına dayanarak aynı JPEG kümesinde medyan sıkıştırmayı AVIF için %50, WebP için %30 olarak aktarıyor.

Bu rakamlardan çıkan dürüst sonuç şu: AVIF'in WebP'ye üstünlüğü gerçek ama JPEG ile arasındaki uçurumdan çok daha dar, ve içeriğe aşırı duyarlı. Gürültülü, dokulu fotoğraflarda AV1'in araçları fark yaratır. Düz renk alanları, keskin kenarlar ve ekran görüntülerinde fark küçülür, hatta tersine döner. Kendi görsellerinizde ölçmeden bir yüzdeye yaslanmayın; iki dosyayı da üretip boyutları karşılaştırmak birkaç saniyelik iş. JPEG'den AVIF'e ve JPEG'den WebP'ye araçları aynı kaynaktan iki çıktı üretmenizi sağlar.

AVIF'in kaybettiği yerler

Küçük görseller

AVIF'in HEIF kabı, ilk pikselden önce bir kutu zinciri yazar: ftyp, meta, iloc, iinf ve özellik kutuları. Bu sabit yük 3000 pikselik bir fotoğrafta görünmez, ama 32 × 32 bir ikonda dosyanın önemli bir bölümünü kaplar. Bu yüzden küçük ikon ve rozetlerde AVIF sıklıkla PNG ya da kayıpsız WebP'ye yenilir. Vektör olarak üretilebilecek her şeyi zaten SVG araçlarıyla SVG olarak servis etmek daha doğru.

Kodlama maliyeti

AVIF üretmek WebP üretmekten kat kat pahalıdır. web.dev, libaom 2.0.0 ile 3.1.0 sürümleri arasında hâlâ görüntü kodlamasında 6,5 kat CPU ve 5 kat bellek düşüşü sağlandığını yazıyor (speed=6, cq-level=18, 8,1 megapiksel görseller). Yani iyileştirmeden sonraki durum bile ciddi bir işlem yüküdür. Kodlayıcının hız ayarı doğrudan bir takas: yavaş ayar daha küçük dosya, hızlı ayar daha büyük dosya verir. Kullanıcı yüklemesini anında dönüştüren bir akışta bu süre kuyruk demektir; önceden üretilen kataloglarda ise sorun değildir.

İlerlemeli yükleme yok

MDN'in açıkça belirttiği gibi AVIF tarayıcılarda ilerlemeli olarak çözülmez: dosya tamamen inmeden hiçbir şey görünmez. Küçük dosyalarda bu fark edilmez, çünkü zaten hızlı iner. Sayfanın en üstündeki büyük görselde ve yavaş bağlantıda ise bir JPEG'in bulanıktan nete gitmesi, boş bir kutunun aniden dolmasından daha iyi bir deneyim olabilir.

Ekran görüntüsü ve düz renk

Arayüz ekran görüntüleri, grafikler, çizim ve metin ağırlıklı görseller az sayıda renk ve çok sayıda keskin kenar içerir. Bu tür içerikte kayıplı kodlayıcıların hepsi kenarlarda halka (ringing) üretir. Doğru cevap genelde kayıpsız WebP ya da iyi optimize edilmiş bir PNG olur; ikisini de üretip karşılaştırmadan kayıplı AVIF'e geçmek metni okunaksızlaştırabilir. PNG'den WebP'ye aracı kayıpsız modda bu karşılaştırmayı hızlı yapmanızı sağlar.

Tarayıcı tabanı

MDN'in verdiği ilk destek sürümleri: AVIF için Chrome 85, Opera 71, Firefox 93, Safari 16.1 ve Edge 121. Edge'in tarihi dikkat çekici, çünkü diğerlerinden yıllar sonra geliyor. WebP tarafında tablo çok daha rahat: Chrome 23, Edge 18, Firefox 65 ve Safari 14. Pratikte bu, AVIF servis edecekseniz yedek formatın hâlâ şart olduğu, WebP'yi ise çoğu sitede tek başına verebileceğiniz anlamına gelir.

WebP'nin kaybettiği yerler

WebP bugün güvenli seçenek olsa da tavanı düşük. 8 bitle sınırlı olması, modern telefonların çektiği geniş gamlı ve yüksek dinamik aralıklı fotoğrafları taşıyamaması demek: görsel sRGB'ye sıkıştırılır, gökyüzü geçişlerinde bantlanma görünür. Kayıplı modda 4:4:4 seçeneği yoktur, yani renkli ince detayı korumak istediğinizde kayıpsıza geçmek zorunda kalırsınız ve dosya birden büyür. Telefondan gelen HEIC fotoğraflarını web için hazırlarken bu tavana sık çarpılır; HEIC'ten JPG'ye ara adımı işe yarar ama kaynak kalitesini korumak istiyorsanız AVIF daha uygun hedeftir.

İkisini birden servis etmek

Doğru mekanizma picture elemanıdır: önce image/avif kaynağı, sonra image/webp, en sonda yedek olarak img içinde JPEG ya da PNG. Tarayıcı ilk desteklediğini alır. Alternatifi, isteklerdeki Accept başlığına bakıp sunucuda seçim yapmaktır; bu durumda Vary: Accept göndermeyi unutmayın, yoksa ara katmanlar yanlış formatı önbelleğe alır.

Bedeli de hesaba katın: üç format üretmek depolama ve önbellek anahtarı sayısını üçe katlar, kodlama maliyetini artırır, ve bir görseli güncellediğinizde üç kopyanın da yenilenmesi gerekir. Küçük bir site için tek format seçip iyi sıkıştırmak, üç formatı yarım yamalak yönetmekten daha iyi sonuç verir.

Karar kuralları

• Büyük fotoğraf (100 kB üzeri JPEG): AVIF'i deneyin, kazanç genelde emeğe değer.
• Küçük fotoğraf ve küçük resim: WebP; AVIF'in kap yükü kazancı yiyip bitirir.
• Ekran görüntüsü, arayüz, çizim: kayıpsız WebP ya da optimize PNG.
• İkon, logo, basit grafik: SVG.
• HDR ve geniş gam fotoğraf: AVIF; WebP bu veriyi taşıyamaz.
• Tek format seçmek zorundaysanız: WebP, çünkü tarayıcı tabanı ve kodlama maliyeti rahat.

Hangisini seçerseniz seçin, format değişimi sıkıştırma ayarının yerine geçmez. Boyutu asıl düşüren şey görseli servis edeceğiniz ölçüye indirmek ve kaliteyi ölçerek seçmektir; bunu ayrı bir yazıda ele aldık: görsel sıkıştırma ve kalite kaybı. Toplu işler için görsel sıkıştırma aracı, geri dönüş gerektiğinde AVIF'ten PNG'ye ve WebP'den PNG'ye araçları yeterli olur.