AVIF Nedir, WebP'den Farkı Ne

Görselleri WebP'ye çevirdiniz, sayfa ağırlığı düştü, hız testi yeşile döndü. Sonra bir yerde AVIF'in aynı kalitede WebP'den de küçük dosya ürettiğini okudunuz ve haklı bir soru doğdu: "Bir kez daha mı dönüştüreceğim?" AVIF, AV1 video kodekinin durağan görüntü hâli olarak tanımlanabilecek bir formattır ve gerçekten de aynı algılanan kalitede WebP'den belirgin biçimde küçük dosyalar üretir. Ama bu kazancın bir bedeli var ve o bedeli bilmeden karar vermek, sunucunuzu gereksiz yere meşgul edebilir.

Bu yazıda AVIF'in teknik olarak WebP'den nerede ayrıldığını, dosya boyutu kazancının gerçekte ne kadar olduğunu, kodlama süresi farkının üretim akışınızı nasıl etkilediğini, tarayıcı desteğinin bugünkü durumunu ve ikisini birlikte kullanmanın en temiz yolunu anlatacağım. Sonunda "hangisini seçmeliyim" sorusuna bağlama göre net bir cevap çıkaracağız.

AVIF Tam Olarak Nedir#

AVIF, açılımı AV1 Image File Format olan bir görüntü formatıdır. Adından da anlaşılacağı gibi temeli AV1 video kodekidir: bir AVIF dosyası, aslında AV1 ile kodlanmış tek bir kare (intra frame) ve bunu saran HEIF kapsayıcısından oluşur. Video kodeklerinin durağan görüntü sıkıştırmasında iyi olması tesadüf değildir; modern video kodekleri, bir karenin içindeki tekrarları ve öngörülebilir yapıları bulmakta uzun yıllardır geliştirilmiş çok gelişmiş araçlara sahiptir ve bu araçlar tek kareye uygulandığında da işe yarar.

WebP ise VP8 video kodekinin intra kodlamasına dayanır. Yani ikisi de aynı fikirden doğmuştur; aradaki fark, VP8 ile AV1 arasındaki bir nesil farkıdır. AV1 daha büyük blok yapıları, daha zengin öngörü kipleri ve daha iyi entropi kodlaması kullanır. Bu, aynı bit bütçesiyle daha fazla detay saklamak anlamına gelir.

Formatın pratikte anlamlı olan yetenekleri şunlardır: 8, 10 ve 12 bit renk derinliği (WebP yalnızca 8 bit), geniş renk gamı ve HDR desteği, alfa kanalı (şeffaflık), animasyon ve hem kayıplı hem kayıpsız kip. 10 bit desteği kulağa akademik gelebilir ama pratik bir karşılığı vardır: gökyüzü, gradyan arka planlar ve düşük ışıklı fotoğraflardaki bantlanma sorunu 10 bit kodlamayla belirgin biçimde azalır.

Boyut Kazancı Gerçekte Ne Kadar#

Kaba bir kural olarak AVIF, aynı algılanan kalitede WebP'den yaklaşık %20-30, JPEG'den ise %40-50 daha küçük dosya üretir. Ancak bu rakamlar görselin türüne çok bağlıdır ve tek bir yüzdeyle özetlenmesi yanıltıcıdır:

Son satır özellikle önemli. AVIF'in HEIF kapsayıcısı, WebP'nin RIFF kapsayıcısından daha ağırdır. 3 KB'lık bir ikonda bu fark oransal olarak büyük olduğu için AVIF dosyası WebP'den daha büyük çıkabilir. Bu yüzden küçük görselleri AVIF'e dönüştürmenin bir anlamı yoktur; dönüşüm akışınıza bir boyut eşiği koyun.

Bir başka önemli nokta, AVIF'in düşük bit oranlarında davranışıdır. Agresif sıkıştırmada JPEG blok artefaktları, WebP bulanıklaşma üretirken AVIF daha çok detay yumuşatma eğilimindedir; yüzler ve ince dokular "plastik" görünebilir. Bu yüzden kalite değerini kulaktan dolma bir rakamla değil, kendi görsellerinizle göz testi yaparak seçmelisiniz.

Asıl Fark: Kodlama Süresi#

Dosya boyutu tablosu AVIF'i açık ara kazandırıyor gibi görünüyor. Ama üretim akışınızı belirleyen asıl değişken kodlama maliyetidir ve bu konuda tablo tam tersine döner.

AV1 kodlaması hesaplama açısından ağırdır. Aynı görsel için cwebp ile avifencin harcadığı süre arasında, seçilen çaba (effort/speed) seviyesine bağlı olarak kat kat fark oluşur. Bu, tek bir görsel için fark etmez; ama şu senaryolarda doğrudan bir sorun hâline gelir. Bir e-ticaret sitesine günde yüzlerce ürün fotoğrafı yükleniyorsa dönüşüm kuyruğu birikir. Kullanıcıların görsel yüklediği bir platformda dönüşüm eş zamanlı yapılıyorsa yükleme isteği zaman aşımına uğrar. Paylaşımlı bir sunucuda CPU kotanız varsa toplu dönüşüm hesabınızı geçici olarak kısıtlatabilir.

Pratik çözüm, dönüşümü istek yolundan çıkarmaktır: yükleme anında orijinali kaydedin, dönüşümü arka plan kuyruğuna atın, hazır olana kadar WebP ya da JPEG sunun. Bir görsel CDN'i kullanıyorsanız bu iş zaten sizin altyapınızın dışında yapılır; modelin nasıl işlediğini resim CDN'i ile otomatik görsel optimizasyonu yazısında anlatıyorum.

Karar tablosunu şöyle özetleyebilirim:

avifenc ile Dönüştürme#

AVIF üretmenin en doğrudan yolu libavif paketiyle gelen avifenc komutudur:

# Debian / Ubuntu
sudo apt update && sudo apt install -y libavif-bin

# RHEL / AlmaLinux
sudo dnf install -y libavif-tools

# macOS
brew install libavif

avifenc --version

Temel kullanım ve önemli parametreler:

# Kalite tabanlı dönüşüm (0 = en kötü, 100 = kayıpsız)
avifenc -q 60 urun.jpg urun.avif

# Hız/kalite dengesi: -s 0 en yavaş ve en iyi, -s 10 en hızlı
avifenc -q 60 -s 6 urun.jpg urun.avif

# Tüm CPU çekirdeklerini kullan (toplu işlerde belirgin fark yaratır)
avifenc -q 60 -s 6 -j all urun.jpg urun.avif

# Şeffaf PNG: alfa kanalını kayıpsız tut
avifenc -q 60 --qalpha 100 seffaf.png seffaf.avif

# Kayıpsız kip
avifenc --lossless logo.png logo.avif

Buradaki -q ölçeğinin WebP ile aynı olmadığını mutlaka aklınızda tutun. cwebp -q 80 ile avifenc -q 80 benzer bir kaliteyi değil, çok farklı dosya boyutlarını verir; AVIF'te 50-65 aralığı genellikle WebP'nin 75-85 aralığına karşılık gelen algılanan kaliteyi üretir. Bu yüzden WebP kalite değerinizi AVIF'e olduğu gibi taşımayın; birkaç görselle göz testi yapıp kendi eşiğinizi bulun.

Toplu dönüşümde çekirdek kullanımını paralelleştirmek büyük fark yaratır:

# GNU parallel ile çekirdek başına bir dosya
find ./uploads -type f -size +30k \( -iname '*.jpg' -o -iname '*.png' \) \
  | parallel -j "$(nproc)" 'avifenc -q 60 -s 6 {} {.}.avif'

-size +30k filtresi, kazanç üretmeyecek küçük dosyaları baştan eler. Sıkıştırma araçlarının genel karşılaştırması ve hangi format için hangi aracın uygun olduğu konusunda görsel sıkıştırma araçları karşılaştırması yazısı tamamlayıcı bir kaynak.

İkisini Birlikte Kullanmak: Doğru Yol#

AVIF ile WebP arasında seçim yapmak zorunda değilsiniz; doğru kurulum ikisini de sunmaktır. picture elementi tam olarak bunun için vardır: tarayıcı listeyi yukarıdan aşağı okur, desteklediği ilk kaynağı alır, gerisini hiç indirmez.

<picture>
  <source srcset="/img/kapak.avif" type="image/avif">
  <source srcset="/img/kapak.webp" type="image/webp">
  <img src="/img/kapak.jpg" alt="Kapak görseli" width="1600" height="900" loading="lazy">
</picture>

Sıralama kritiktir ve en küçükten en büyüğe doğru olmalıdır: AVIF, sonra WebP, en sonda geri dönüş olarak JPEG. Sıralamayı ters yazarsanız AVIF destekleyen bir tarayıcı bile WebP alır, çünkü desteklediği ilk kaynakta durur.

Sunucu tarafında Accept başlığına göre otomatik seçim yapmak da mümkündür. Nginx ile üç kademeli bir kurulum şöyle görünür:

# Tarayıcının desteklediği en iyi formatı belirle
map $http_accept $tercih_uzanti {
    default        "";
    "~*image/avif" ".avif";
    "~*image/webp" ".webp";
}

server {
    location ~* ^(/.+)\.(jpe?g|png)$ {
        try_files $1$tercih_uzanti $uri =404;

        # Bu başlık olmadan önbellek zehirlenmesi kaçınılmazdır
        add_header Vary Accept;
        expires 30d;
    }
}

map bloğunda sıralamanın önemli olduğunu unutmayın: Nginx map içinde eşleşen ilk desene göre değil, tanımlanan son eşleşmeye göre karar verebilir; bu yüzden karmaşık kurulumlarda try_files ile üç kademe denemek ($1.avif, $1.webp, $uri) daha öngörülebilir sonuç verir. Her durumda Vary: Accept başlığı zorunludur; yoksa bir CDN, AVIF destekleyen bir istemciye verdiği yanıtı desteklemeyen bir istemciye de servis eder ve görseller bozuk görünür. Aynı riskin WebP tarafındaki ayrıntıları için WebP'ye dönüştürme rehberi yazısına bakabilirsiniz.

Hangisini Seçmelisiniz#

Karar vermeyi kolaylaştıracak birkaç somut senaryo:

1. Trafiğiniz görsel ağırlıklı, ekibiniz küçük, işi basit tutmak istiyorsunuz. Yalnızca WebP kurun. Kazancın büyük kısmını alırsınız, kodlama maliyeti düşüktür, sürpriz çıkmaz.
2. Fotoğraf ağırlıklı bir site işletiyorsunuz ve bant genişliği maliyeti sizin için gerçek bir kalem. AVIF + WebP ikilisini picture ile kurun. Fotoğraflarda AVIF'in kazancı doğrudan faturaya yansır.
3. Kullanıcılar görsel yüklüyor ve yükleme akışı hızlı olmalı. Dönüşümü arka plan kuyruğuna alın ya da bir görsel CDN'i kullanın. Yükleme isteği içinde AVIF kodlamayın.
4. Görselleriniz ağırlıklı olarak logo, ikon ve arayüz grafiği. SVG'ye geçmeyi düşünün. Vektör, hiçbir raster formatın rekabet edemeyeceği bir çözümdür; kalan raster grafikler için WebP kayıpsız kip yeterlidir.

Görsel formatı seçimini yaparken toplam bant genişliği tasarrufunu kabaca hesaplamak isterseniz bant genişliği hesaplayıcı aracımız ay sonundaki farkı görmenize yardımcı olur.

Sık Yapılan Hatalar#

WebP kalite değerini AVIF'e aynen taşımak. İki formatın kalite ölçeği aynı değildir. -q 80 ile ürettiğiniz AVIF gereğinden büyük olur ve kazancın bir kısmını kaybedersiniz. AVIF'te 50-65 aralığından başlayın.

Kodlamayı istek yolunda yapmak. Yükleme isteği içinde AVIF üretmek, yoğun anlarda zaman aşımı ve CPU tükenmesi üretir. Dönüşüm her zaman asenkron olmalıdır.

picture sıralamasını ters yazmak. AVIF'i WebP'den sonra koyarsanız hiçbir tarayıcı AVIF almaz. Sıralama en küçük dosyadan en büyüğe doğrudur.

Geri dönüş img etiketini unutmak. picture tek başına hiçbir şey göstermez; içindeki img hem geri dönüş hem de gerçek görüntüleyendir. alt, width ve height özniteliklerini de mutlaka yazın, aksi halde yükleme sırasında düzen kayar.

Her şeyi dönüştürmek. 30 KB'ın altındaki dosyalarda AVIF genellikle kazanç üretmez, hatta büyütür. Toplu dönüşüm betiğinize boyut eşiği koyun ve sonucu karşılaştırıp kazanç yoksa üretilen dosyayı silin.

Sıkça Sorulan Sorular#

AVIF WebP'den ne kadar küçük#

Aynı algılanan kalitede AVIF genellikle WebP'den yaklaşık %20-30 daha küçük dosya üretir; JPEG ile karşılaştırıldığında fark %40-50 seviyesine çıkar. Ancak bu ortalama bir aralıktır: detaylı fotoğraflarda ve gradyan içeren görsellerde kazanç daha yüksek, ürün fotoğrafı gibi sade görsellerde daha düşüktür. Çok küçük ikonlarda ise AVIF kapsayıcı yükü nedeniyle daha büyük bile olabilir.

AVIF tüm tarayıcılarda çalışır mı#

Modern Chrome, Edge, Firefox ve Safari sürümlerinin tamamı AVIF'i destekler, dolayısıyla ziyaretçilerinizin büyük çoğunluğu görebilir. Ancak destek WebP kadar evrensel değildir ve eski cihazlarda eksik olabilir. Bu yüzden AVIF'i tek başına değil, picture elementinde WebP ve JPEG geri dönüşleriyle birlikte sunmak gerekir; böylece desteklemeyen istemci otomatik olarak bir alt formata düşer.

AVIF dönüşümü neden bu kadar yavaş#

Çünkü AVIF'in temelindeki AV1 kodeki, sıkıştırma oranını artırmak için çok sayıda öngörü kipini deneyerek en iyisini seçer ve bu arama hesaplama açısından pahalıdır. avifenc komutundaki -s parametresi bu aramanın ne kadar derin yapılacağını belirler; -s 8 gibi yüksek bir değer süreyi kısaltır ama dosya biraz büyür. Toplu işlerde -j all ile tüm çekirdekleri kullanmak ve dönüşümü arka plana almak pratik çözümdür.

Mevcut WebP dosyalarımı AVIF'e çevirmeli miyim#

Hayır, WebP'den AVIF'e çevirmeyin. WebP zaten kayıplı sıkıştırılmış bir dosyadır; onu tekrar kayıplı bir formata kodlamak, ilk sıkıştırmanın artefaktlarını da kodlamak anlamına gelir ve kaliteyi gereksiz yere düşürür. Dönüşümü her zaman elinizdeki en yüksek kaliteli kaynaktan, yani orijinal fotoğraftan yapın. Orijinaller elinizde değilse mevcut WebP kurulumunuzda kalmak daha doğrudur.

AVIF SEO'ya zarar verir mi#

Hayır. Arama motorları picture elementini ve içindeki img etiketini doğru yorumlar; görsel indekslemesi geri dönüş img üzerinden yapılır. Dikkat etmeniz gereken tek şey alt metnini eksiksiz yazmak ve width ile height özniteliklerini vermektir. Daha küçük dosyalar sayfa hızını iyileştirdiği için etki, olumsuz olmak bir yana genellikle olumludur.

AVIF mi WebP mi, sadece birini seçeceksem hangisi#

İş gücünüz sınırlıysa ve kurulumu basit tutmak istiyorsanız WebP daha az sürprizle sonuç verir: kodlaması hızlıdır, araç ekosistemi olgundur ve tarayıcı desteği neredeyse evrenseldir. Bant genişliği maliyeti sizin için gerçek bir kalemse ve fotoğraf ağırlıklı bir siteniz varsa AVIF'in ek kazancı bu maliyeti karşılar. Yine de en doğru cevap ikisini birden picture ile sunmaktır; ek maliyeti yalnızca dönüşüm adımıdır.

Kapanış#

AVIF, WebP'nin yerini alan değil, üstüne eklenen bir katman. Daha küçük dosya verir, 10 bit renk desteğiyle gradyanlarda bantlanmayı azaltır, ama kodlaması pahalıdır ve küçük görsellerde kazanç üretmez. Aklınızda kalması gereken dört alışkanlık şunlar: kalite ölçeğini WebP'den kopyalamayın ve AVIF'te 50-65 aralığından başlayın, dönüşümü asla istek yolunda yapmayın, picture sıralamasını AVIF → WebP → JPEG olarak kurun ve boyut eşiğinin altındaki dosyaları hiç dönüştürmeyin. İkisini birlikte sunduğunuzda hiçbir ziyaretçiyi geride bırakmadan mümkün olan en küçük dosyayı göndermiş olursunuz.

Toplu dönüşüm işlerini kendi zamanlanmış görevlerinizle yönetmek isterseniz tam root erişimi ve gerçek CPU kaynağı sunan VDS ile sanal sunucu paketlerimiz bu iş yükü için uygundur. Yoğun görsel trafiği olan projelerde kaynak planlamasını ve dönüşüm kuyruğunu bize bırakmak isterseniz sunucu yönetimi hizmetimiz bu kurulumu üstlenir; hazır ve optimize bir zemin arıyorsanız e-ticaret hosting paketlerimize göz atabilirsiniz.