AVIF Fallback Stratejisi Nasıl Kurulur?

<picture> ile AVIF-WebP-JPEG fallback zinciri

En yaygın çözüm HTML düzeyinde çalışır. <picture> etiketi içine birden fazla <source> tanımlanır; tarayıcı yukarıdan aşağıya kontrol ederek desteklediği ilk formatı alır. Sıra önemlidir: AVIF üstte, WebP ortada, JPEG altta.

<picture>
  <source srcset="/img/fotograf.avif" type="image/avif">
  <source srcset="/img/fotograf.webp" type="image/webp">
  <img src="/img/fotograf.jpg" alt="Açıklayıcı metin" width="1200" height="800">
</picture>

Buradaki <img> etiketi yalnızca fallback değil, alt, width, height ve loading gibi kritik özelliklerin tanımlandığı asıl öğedir. AVIF veya WebP desteklemeyen her tarayıcı doğrudan img src değerini kullanır. Bu yapı ek JavaScript gerektirmez, sunucu konfigürasyonu istemez ve CDN'den bağımsız çalışır.

Responsive kullanım için srcset boyut listesiyle birleştirilebilir:

<picture>
  <source
    srcset="/img/fotograf-800.avif 800w, /img/fotograf-1600.avif 1600w"
    type="image/avif"
    sizes="(max-width: 900px) 100vw, 1200px">
  <source
    srcset="/img/fotograf-800.webp 800w, /img/fotograf-1600.webp 1600w"
    type="image/webp"
    sizes="(max-width: 900px) 100vw, 1200px">
  <img src="/img/fotograf-1600.jpg" alt="..." width="1600" height="1000" loading="lazy">
</picture>

Bu yaklaşımın bedeli dosya sayısıdır. Her görüntü için üç farklı format tutmak gerekir; boyut varyantları eklenince bu çarpanlanır. Dosya sayısını yönetilebilir tutmak için genellikle en kritik veya en sık görüntülenen görsellerde AVIF üretimi yapılır; tüm kütüphanede zorunlu tutulmaz.

Tarayıcı desteğinin fotoğrafı ve neyin önemli olduğu

Chromium tabanlı tarayıcılar (Chrome, Edge, Opera, Samsung Internet'in güncel sürümleri) AVIF'i uzun süredir destekler. Firefox 93'ten itibaren tam destek vardır. Safari ise 16.0'dan (macOS Ventura, iOS 16) itibaren AVIF'i kabul eder; ancak bu, hâlâ dolaşımda olan eski iOS ve macOS sürümlerinin dışarıda kaldığı anlamına gelir.

Bu rakamlar toplu "genel destek" olarak okunduğunda yanıltıcı olabilir. Önemli olan sitenize gelen trafiğin cihaz ve işletim sistemi dağılımıdır. iOS kullanıcı payınız yüksekse ve iOS 15 veya altı hâlâ analiz verilerinde görünüyorsa, fallback olmayan AVIF bu kitle için boş görüntü üretir.

Android tarafında da tablo homojen değildir. Sistem WebView sürümü güncellenmemiş cihazlar, medya desteği kısıtlı bazı üçüncü parti tarayıcılar ve kurumsal ağ proxy'leri görüntü başlıklarına müdahale edebilir. Bu kenar durumlar istatistiksel olarak küçük kalabilir; ama bir e-ticaret sayfasında "ürün görseli hiç yüklenmiyor" sorunu olarak yansıyabilir. AVIF'in WebP'ye göre sıkıştırma üstünlüğü gerçektir; ancak bu üstünlüğü güvenli bir fallback olmadan sunmak risk yaratır.

CDN'de AVIF sunumunu WebP'ye düşürmek

Cloudflare, Fastly, Akamai veya ImageKit gibi bir CDN ya da SaaS görüntü hizmeti kullanıyorsanız, format kararını HTML'den bağımsız olarak CDN düzeyine taşıyabilirsiniz. Bu yaklaşımda tek bir URL kullanılır; CDN gelen isteğin Accept başlığını okur ve en uygun formatı dinamik olarak sunar.

Örneğin Cloudflare Image Resizing etkinleştirildiğinde, Accept: image/avif,image/webp,*/*;q=0.8 gönderen bir Chrome AVIF alır. Accept: image/webp,image/png,*/*;q=0.8 gönderen eski bir Safari WebP alır. Hiçbirini desteklemeyen ortam JPEG'e düşer. HTML'de tek bir <img src> yeterli olur; üç ayrı format dosyası ayrıca saklamak gerekmez, CDN dönüşüm cache'i bunu yönetir.

Kendi sunucunuzu çalıştırıyorsanız benzer davranış Nginx'te $http_accept değişkeniyle elde edilebilir. Accept başlığında image/avif geçiyorsa AVIF, image/webp geçiyorsa WebP, geçmiyorsa JPEG sunacak şekilde map ve try_files kombinasyonu kurulabilir. Bu yapı <picture> etiketinin sunucu tarafındaki muadilidir: aynı mantık, farklı katmanda çalışır. Dezavantajı ise CDN bypass edildiği senaryolarda — doğrudan origin isteği gibi — fallback zincirinin kaybolma riskidir.

Fallback için kalite ayarı nasıl seçilmeli

Fallback zinciri kurulduğunda üç dosya için üç ayrı kalite kararı gerekir. Yaygın bir hata, tüm formatlara aynı değeri uygulamaktır; ancak farklı formatların codec yapısı nedeniyle aynı rakam aynı görsel kaliteye karşılık gelmez.

AVIF için quality 60–75 aralığı genellikle WebP 80'e ya da JPEG 85'e yakın görsel sonuç verir; ama AVIF dosyası belirgin biçimde küçük kalır. Bu asimetriden yararlanmak için AVIF'te daha düşük kalite değeri kullanmak mantıklı olabilir; dosya boyutu kazancı artar, algısal fark ise minimal kalır. WebP'deki lossy/lossless ayrımında da benzer bir dinamik geçerlidir: "quality=80" farklı içeriklerde farklı sonuçlar üretir.

JPEG fallback için dikkat noktası farklıdır: JPEG, AVIF veya WebP'nin kullanılamadığı koşullarda kullanıcıya ulaşan tek görüntüdür. Bu nedenle JPEG kalitesini fazla kısmak, fallback aktif olduğunda gerçekten bozuk bir görüntü sunmak anlamına gelir. Pratikte 75–85 aralığı makul bir pencere olarak tutulur. İçerik türü de burada belirleyicidir: keskin kenarlı ve düz renk alanlı görsellerde (logo, infografik, ekran görüntüsü) yüksek kalite ya da lossless tercih edilmeli; fotoğraf içeriğinde ise agresif sıkıştırma görsel farkı maskeleyebilir.

Server-side format müzakeresi ne zaman daha temizdir

HTML tabanlı <picture> zinciri kontrolü size verir ve sunucu bağımlılığı yoktur. Ama her zaman en temiz seçenek değildir. İçerik yönetim sisteminiz görselleri doğrudan <img> olarak yerleştiriyorsa ve <picture> yapısına geçiş büyük bir şablonlama değişikliği gerektiriyorsa, CDN veya sunucu düzeyi operasyonel olarak daha sürdürülebilir olabilir.

E-ticaret platformları, headless CMS'ler ve medya kütüphaneleri bu kategoriye sıklıkla girer. Shopify, Contentful veya benzeri sistemlerde görseller tek URL formatında yönetilir; format dönüşümü için şablon katmanını değiştirmek yerine platform düzeyindeki görüntü optimizasyon ayarlarını kullanmak daha az müdahale demektir.

Sunucu tarafı çözümlerde cache keying kritik bir detaydır. AVIF ve JPEG aynı URL'den sunuluyorsa, CDN'nin Vary: Accept başlığına göre ayrı cache girdisi oluşturması gerekir. Bu konfigüre edilmezse AVIF alan bir tarayıcının cache'i, AVIF desteklemeyen bir tarayıcıya yanlış formatta yanıt verebilir. srcset ve responsive görsel kurulumunda da benzer cache davranışları belirleyici hale gelir; format kararları URL yapısıyla birlikte değerlendirilmelidir.

Fallback zincirini test etmek

<picture> yapısındaki <source type="image/avif"> satırını geçici olarak yorum satırına alın; sayfayı yenilediğinizde WebP'ye geçiş yapılıp yapılmadığını, ardından her iki source'u da kaldırınca JPEG'e düşülüp düşülmediğini doğrulayabilirsiniz. Bu basit test fallback zincirinin HTML düzeyinde çalıştığını teyit eder.

CDN düzeyinde test için cURL kullanışlıdır. Accept: image/avif ile yapılan istek AVIF, Accept: image/jpeg ile yapılan istek JPEG döndürmeli; yanıt başlıklarındaki Content-Type ve varsa Vary: Accept değerleri kontrol edilmelidir. Görsel SEO açısından da doğru içerik tipi başlığı önemlidir: tarayıcılar ve arama motoru botları dosya formatını uzantıdan değil, Content-Type başlığından okur. Bu değer yanlışsa aynı dosya farklı ortamlarda tutarsız biçimde işlenebilir.

Fallback zincirinin doğru kurulması, AVIF'i yalnızca destekleyen tarayıcılar için kullanılabilir kılmaktan ibaret değildir. Aynı zamanda desteklemeyen tarayıcıların görüntüyü kaybetmeden devam etmesini sağlayan altyapıdır. İkincisi olmadan birincisinin değeri yoktur.

Hangi yolu seçeceğiniz — HTML tabanlı <picture> zinciri, CDN format müzakeresi ya da sunucu tarafı yönlendirme — büyük ölçüde mevcut altyapınıza ve CMS yapınıza bağlıdır. Yeni bir proje kuruyorsanız HTML tabanlı çözüm başlamak için en öngörülebilir yoldur: ek konfigürasyon gerektirmez, CDN'den bağımsızdır ve tarayıcı davranışı belgelenmiş bir standarttır. Mevcut bir sistemi güncelliyorsanız CDN düzeyine taşımak şablon değişikliklerini azaltabilir; ancak cache keying ayarını atlamak ileride tutarsız format dağıtımına yol açar.

Her proje için AVIF + WebP + JPEG zinciri zorunlu değildir. Trafiğin tarayıcı dağılımına, içeriğin türüne ve işlem kapasitesine göre bu zinciri kısmak mümkündür. Fallback stratejisinin amacı performans değil güvenilirliktir; zincir ne kadar sade kalırsa, bakımı da o kadar kolay olur.