Fotoğraf formatı kararı görünürde basit, pratikte değil. JPEG onlarca yıldır standarttır; WebP ise web için optimize edilmiş, daha genç bir format. İkisi arasındaki seçimi "hangisi daha yeni" sorusuna indirgemek, yanlış bağlamlarda yanlış kararlar doğurur.
Bu karşılaştırma, benchmarkların söylediği değil; fotoğraf tipi, içerik yapısı ve sistem mimarisi değişkenlere göre farkın nerede açıldığını ve nerede kapandığını gösteriyor.
Farklı sorunlara verilen iki farklı yanıt
JPEG (Joint Photographic Experts Group) 1992'de fotoğrafa özgü bir sıkıştırma sorunu için geliştirildi: insan gözünün yüksek frekans detaylara karşı daha az duyarlı olduğu gözlemine dayanarak, renk bilgisini parlaklık bilgisinden daha agresif sıkıştırır. DCT (Discrete Cosine Transform) tabanlı bu yaklaşım fotoğraf sıkıştırmasında uzun süre standart olarak kaldı çünkü soruyu doğru tanımlamıştı.
WebP ise Google tarafından 2010'da önerilen ve VP8 video codec'inden türetilen bir format. Predictive coding ve block transform kombinasyonu kullanır; hem lossy hem lossless modda çalışabilir. Tasarım amacı fotoğraf değil, web sayfasındaki her tür görsel içeriktir; fotoğraflar onun için bir alt küme.
Bu fark önemli: WebP fotoğraf sıkıştırması için özelleştirilmiş değil, web görsel taşıma için genelleştirilmiş bir format.
WebP daha yeni. Daha iyi değil.
Aynı fotoğraf, iki encoder: fark nerede açılır?
JPEG ve WebP'nin lossy modları farklı artifakt imzaları bırakır. JPEG yüksek sıkıştırma oranlarında 8x8 piksel bloklarla çalışır; bu bloklardaki sınır geçişleri "blocking" denen kare artifaktı üretir. WebP ise daha esnek blok yapısıyla (4x4'ten 64x64'e kadar) bu sınır sorununu azaltır ama renk geçişlerinde farklı bir artifact tipi, banding, daha sık görülebilir.
Kalite kaybı nerede açılır? Düşük frekans içerikli fotoğraflarda, yani düz gökyüzü, arka fon blur, sade stüdyo çekimi gibi içeriklerde WebP belirgin avantaj sağlar. Aynı görsel kalitede dosya boyutu yüzde 20-35 arasında küçülür. Yüksek frekans detay barındıran fotoğraflarda ise bu avantaj daralmaya başlar: kürk dokusu, yaprak damarları, kum yüzeyi gibi içeriklerde her iki encoder da benzer boyutlara düşer ve artifakt tipi farka rağmen toplam kayıp eşit ağırlıkta olabilir.
Pratik eşik şöyle düşünülebilir: quality 80 JPEG ile quality 75 WebP karşılaştırıldığında, fotoğraf içeriğine göre WebP boyut avantajı yüzde 15 ile 35 arasında değişir. Bu sayıların sabit olmadığını vurgulamak gerekir; içerik belirleyicidir.
| Fotoğraf içeriği | JPEG q80 (örnek) | WebP q75 (örnek) | Boyut farkı |
|---|---|---|---|
| Sade stüdyo portresi, düz arka plan | 180 KB | 115 KB | ~%36 küçük |
| Sokak fotoğrafı, orta detay | 240 KB | 170 KB | ~%29 küçük |
| Yakın çekim, kürk/doku yoğun | 310 KB | 255 KB | ~%18 küçük |
| Gece çekimi, yüksek gürültü | 420 KB | 370 KB | ~%12 küçük |
Gürültü her şeyi değiştirir.
Bu tablodaki değerler genel eğilimi göstermek içindir; gerçek sonuçlar encoder versiyonuna, çözünürlüğe ve kaynak görsel sıkıştırma geçmişine göre değişir. Yüksek gürültülü gece fotoğraflarında kazanım belirgin biçimde azalır çünkü gürültü paterni yüksek frekanslı rastlantısal veri olarak kodlanır ve WebP bu veriyi JPEG'e göre daha iyi bastırmaz. Gürültü azaltma ön işlemi uygulanmış aynı görselde fark daha büyük açılır.
Peki kaynaktaki görüntü zaten gürültülüyse optimizasyon öncesi mi işlenmeli, sonra mı? Bu sıra farkı çıktı boyutunu etkiler mi?
Dosya boyutu kazancı: hangi senaryoda ne kadar önemli?
Boyut farkının pratikte anlam kazandığı yer, servis edilen görsel sayısı ve boyutuyla orantılıdır. Tek bir 1.2 MB hero fotoğrafı WebP'ye dönüştürüldüğünde 0.8 MB'a düşerse 400 KB tasarruf tek sayfa yüklemesinde ciddi etkidir; özellikle LCP hesabına giren bir görsel söz konusuysa.
Thumbnail grid başka bir senaryo. Bir ürün listesi sayfasında 40 küçük görsel bulunuyorsa ve her biri 60 KB JPEG'den 38 KB WebP'ye dönüşüyorsa, toplam 880 KB fark oluşur. Bu fark LCP skorunu doğrudan etkilemez çünkü LCP büyük ölçüde viewport'taki en büyük görsel elemanı hesaplar; ama toplam sayfa ağırlığı ve bant genişliği tüketimi belirgin düşer.
Pipeline yoksa kazanım kağıt üzerinde kalır.
Buradaki karar değişkeni şu: eğer görselleri JPEG'den WebP'ye dönüştürmek için otomatik bir pipeline kurabiliyorsanız, kazanım tüm kataloga yayılır. Kurulum maliyeti sabittir, avantaj lineer büyür.
Tarayıcı desteği artık sorun değil ama sistem karmaşıklığı öyle
Fallback artık zorunlu değil. Safari 14 (Eylül 2020) WebP desteğini eklemesiyle Chrome, Firefox ve Edge ile birlikte tüm yaygın tarayıcılar bu formatı yerel olarak destekliyor, ama bu cümle sistemi yeterince anlatmıyor.
Ama sistem katmanlarına bakıldığında tablo daha karmaşık. CDN önbellekleme, özellikle dikkat gerektiriyor: aynı URL'den hem JPEG hem WebP sunmak için sunucunun gelen isteğin Accept başlığını okuyup doğru versiyonu dönmesi gerekir. Yanlış yapılandırılmış bir CDN, önbelleğe JPEG alır ve WebP isteyen tarayıcılara da onu döner. Veya tersine, WebP önbelleğe alınır ve onu desteklemeyen eski bir istemciye gönderilir.
CMS ekosisteminde durum biraz daha iyi: WordPress 5.8 ile birlikte yerel WebP yükleme desteği geldi ve Imagick/GD kütüphaneleri varsa otomatik WebP çıktısı veren eklentiler sorunsuz çalışır. Ama özelleştirilmiş bir medya pipeline'ı olan sistemlerde, eski thumbnail boyutları JPEG olarak üretilmiş olabilir ve toplu dönüşüm ayrı bir iş gerektirir.
picture etiketiyle fallback mantığı hala kullanılabilir ve kurulum gerektiren bir güvencedir:
<picture>
<source srcset="fotograf.webp" type="image/webp">
<img src="fotograf.jpg" alt="Açıklama">
</picture>Bu yapı tarayıcı desteğine bakılmaksızın çalışır; modern tarayıcı WebP alır, eski tarayıcı JPEG'e düşer. Karmaşıklık eklese de geriye dönük uyumluluk garantisi verir.
LCP skoru üzerindeki gerçek etki
Performans kararlarını LCP (Largest Contentful Paint) üzerinden değerlendirirken, hangi görselin LCP elemanı olduğunu bilmek gerekiyor. Çoğu sayfada bu, görünür alandaki en büyük resimdir; genellikle hero görsel veya ürün ana fotoğrafı.
Hero görsel WebP'ye geçişinin LCP üzerindeki etkisini sayfa performans testi ile ölçmek mümkün. 300 KB JPEG'i 190 KB WebP'ye dönüştürmek, yavaş mobil bağlantıda 300-500 ms LCP farkına dönüşebilir. Bu aralık Core Web Vitals sınırı açısından belirleyici olabilir: 2.5 saniyenin altı "iyi", 4 saniyenin altı "geliştirilmeli", üstü "zayıf" olarak değerlendirilir.
Ama thumbnail veya galeri grid'indeki görseller, LCP hesabına genellikle girmez. Buradaki WebP avantajı kullanıcının bant genişliğine ve veri maliyetine yansır; Lighthouse skoru üzerindeki etkisi görece dolaylıdır.
Küçük görseller LCP'ye girmiyor.
LCP odağıyla yaklaşıldığında öncelik nettir: hero görseli WebP'ye taşımak, küçük görsel sayısını optimize etmekten daha yüksek getiri sağlar; orada kazanılan her kilobayt kullanıcının veri kotasına yansır ama Core Web Vitals notunu değiştirmez.
JPEG'de kalmayı mantıklı kılan senaryolar
WebP'nin teknik avantajı genel olarak belgelenmiş olmakla birlikte, JPEG'i korumak bazı bağlamlarda hala makul bir tercihtir.
Fotoğrafçılık iş akışı birinci senaryo. Lightroom ve Capture One gibi yazılımlar kayıt ve düzenleme adımında JPEG veya RAW üretir; dışa aktarma çıktısı doğrudan web'e gidiyorsa WebP dönüşümü için ek bir adım gerekir. Bu adım bant akışına sürtünme ekler ve otomatize edilmemişse elle yapılan bir iş haline gelir. Büyük hacimli fotoğrafçılık sitelerinde bu maliyet göz ardı edilemez.
Üçüncü taraf gömme ikinci senaryo. Outlook ve Apple Mail gibi masaüstü e-posta istemcileri WebP desteklemez; bülten ve bildirim e-postalarında gönderilen görsel JPEG olmak zorundadır. Sosyal medya platformlarının bazıları WebP kabul etse de boyutları ve sıkıştırma parametrelerini yeniden işler; gönderilen format bu durumda çıktıyı etkilemez.
Arşiv ve uzun vadeli saklama üçüncü senaryo. Dijital arşiv sistemleri, yedekleme yazılımları ve eski NAS aygıtları büyük çoğunluğuyla JPEG'i tanır. Arşivlenen görseli ileride farklı bir formatın girişiyle yeniden işleme ihtiyacı doğurabilecek bir karar yapmak yerine JPEG'de bırakmak, bakım yükünü azaltır.
Renk profili yönetimi de ayrı bir sürtünme noktası. JPEG, ICC renk profillerini (sRGB, Adobe RGB, P3) dosya içine gömer ve fotoğraf yazılımları bu profili okuyarak doğru renk dönüşümü yapar. WebP de teknik olarak ICC profili destekler; ama baskı hazırlık akışlarında ve renk yönetimi sistemlerinde WebP desteği henüz JPEG kadar olgunlaşmamış. Özellikle Adobe RGB veya wide-gamut renk uzayında çalışan fotoğraf stüdyoları için bu teknik ayrıntı pratik bir seçim belirleyici olabilir.
Karar satırı şöyle kurulabilir: web'e sunulan her fotoğraf için WebP tercih edilmeli; fotoğraf arşivleri, yazım iş akışları ve 3rd party dağıtım için JPEG mantığı korunabilir. Sıkıştırma parametrelerini test ederken her iki format arasındaki kalite/boyut kırılma noktasını içeriğe özgü değerlendirmek, sabit bir "hangisi daha iyi" cevabından daha güvenilir bir yaklaşım üretir.
Format seçimi aslında yalnızca teknik bir soru değil. Web pipeline'ı, CDN yapılandırması, CMS versiyonu ve dağıtım kanalları bir arada değerlendirilmeden verilen format kararı, avantajı teorik düzeyde bırakır. Mevcut JPEG arşivini WebP'ye dönüştürmek için hazır bir araç kullanmak başlangıç noktası olabilir; ama asıl çalışma, pipeline'ın bu dönüşümü tutarlı biçimde uygulamasını sağlamaktır.