JPEG → WEBP dönüştürücü

Hâlâ ana görsel formatı olarak JPEG yayınlayan sitelerin çoğu bunu bilinçli olarak yapmıyor; daha çok beş yıl önce biri bir telefon fotoğrafı yüklemiş, CMS de varsayılan olarak JPEG çıkarmış ve o günden beri kimse asset arşivine geri dönmemiş. JPEG’leri WEBP ile değiştirmek, elde olan en ucuz performans kazanımlarından biri — algılanan kalitede neredeyse hiçbir fark olmadan transfer boyutunda yüzde 25–35’lik bir düşüş; görsel ağırlıklı bir makalede ya da ürün sayfasında bu çoğu zaman mobilde Largest Contentful Paint’in bir saniye geri çekilmesi anlamına geliyor. Bu dönüştürücü tam olarak o değişimin dosya bazındaki adımını üstleniyor: JPEG’i koy, WEBP’yi al, sayfanın geri kalanı olduğu gibi kalsın.

Bu dönüşümü gerçekten anlamlı kılan, sayfa ağırlığında belirleyici olan dosyalar oluyor. Sayfanın tepesindeki hero görseli, ürün galerisi küçük resimleri, blog yazısı içine yerleştirilmiş fotoğraflar ve yemek tarifi tarzı foto‑grid’ler en bariz adaylar; çünkü byte bütçesini gerçekten bu dosyalar tüketiyor. 5 KB altındaki minik UI sprite’ları ve dekoratif ikonlar bu işten neredeyse hiç kazanç sağlamıyor, çünkü o boyutta format başlığının kapladığı alan görselin kendisiyle yarışır hâle geliyor. Gerçek anlamda büyük dosyalara odaklanmak, her şeyi sırf yapmış olmak için dönüştürmekten çok daha dürüst bir hızlandırma stratejisi.

Kalite ayarı işin merkezindeki ayar ve bunu içeriğe göre ayarlamak, tek bir global varsayılan dayatmaktan çok daha verimli. Fotoğraflar agresif WEBP kalite değerlerini sorunsuz kaldırıyor — 75–80 aralığı çoğu zaman kaynaktan ayırt edilemeyen bir sonuç veriyor ve boyut kazanımı tam burada zirveye çıkıyor. Ekran görüntüleri, line‑art ve içinde metin geçen grafikler daha yüksek kalite (85–92) istiyor; çünkü WEBP de tıpkı JPEG gibi keskin kenarları ilk feda ettiği yerlerden biri yapıyor. Buradaki kaydırıcı, görselin gerçekten neyi içerdiğine göre ayarı eşleştirebilmen için var.

JPEG’den WEBP’ye geçiş sahici anlamda bir yeniden kodlama; kopyalama değil. Orijinal kayıplı sıkıştırma piksellere çözülüp ardından yeniden sıkıştırılıyor. Bu da her dönüşümün, JPEG’in zaten taşıdığı kayba küçük bir kayıp daha eklemesi demek; dönüşümleri zincirlemek (JPEG → WEBP → tekrar JPEG → tekrar WEBP) bu kaybı tahminden hızlı biriktiriyor. Önerilen yol, orijinal JPEG’den tek seferde dönüşmek, sunulan dosya olarak WEBP’yi kullanmak ve orijinal JPEG’i kenarda saklamak; gelecekte farklı ayarlarla yeniden dışa aktarmak gerektiğinde temiz kaynağa dönmek mümkün oluyor.

Tarayıcı desteği 2020 civarından bu yana gerçek bir endişe değil. WEBP; Chrome, Edge, Firefox, Safari, Opera’nın güncel sürümlerinde, mobil tarayıcılarda ve iOS / Android uygulamalarındaki gömülü webview’larda çalışıyor. Geride kalan uç durumlar; eski iç araçlar, az sayıda e‑posta istemcisi ve pandemiden bu yana güncellenmemiş bir Windows masaüstündeki fotoğraf görüntüleyicisi gibi yerler. Normal, kamuya açık bir site için bu kalıntılar artık hesaba katılacak ölçüde değil; bilinen bir istemci filosuna hizmet veren kurum içi bir portal söz konusuysa JPEG’de kalmak hâlâ doğru karar olabilir.

Boyut kazancının teslimat altyapısıyla nasıl etkileşeceğini bilmekte fayda var. Accept başlıklarına göre format pazarlığı yapan CDN’ler, kaynak dosya JPEG olsa bile uyumlu tarayıcılara zaten WEBP gönderiyor; kaynakta WEBP’ye dönmenin asıl kazancı CDN bunu yapmadığında, origin depolama maliyeti önemli olduğunda ya da bytes’ı bir kez üretip dağıtan statik site üreteçleriyle çalışırken ortaya çıkıyor. Platform anında format pazarlığı yapmıyorsa, build sürecinde manuel WEBP dönüşümü gerçek byte düşüşünün yaşandığı yer oluyor.

İki küçük teknik not. EXIF metadata dönüşüm sırasında genellikle düşürülüyor; bu, kamuya açık webde aslında istenen bir şey — her sayfa yüklemesinde dolaşan kamera detayları ve gömülü thumbnail kilobyte’ları azalıyor. Bir dosyanın erişilebilirlik, telif veya denetim sebebiyle EXIF taşıması gerekiyorsa, orijinal JPEG’i metadata bozulmadan saklayıp WEBP’yi yalnızca teslimat için kullanmak doğru yaklaşım. Renk profilleri sRGB olarak korunuyor; modern tarayıcıların zaten varsayım yaptığı uzay bu. Geniş gamutlu Display P3 kaynaklar, beklenmedik bir ton kayması olmadan sRGB’ye düzgünce indirgeniyor.

Operasyonel olarak iş tek bir adıma iniyor. JPEG’i sürükle, varsayılan kalite içeriğe uymuyorsa kaydırıcıyı oynat, WEBP’yi al. Dosyalar geçici depolamada işleniyor, indirme bağlantıları kısa sürede geçersizleşiyor, hesap açma yok, filigran yok, birkaç dosyadan sonra çıkacak günlük kota da yok. Birden fazla JPEG’i arka arkaya geçirmek mümkün; statik site rebuild’i için blog asset’i hazırlarken ya da küçük bir ürün kataloğunun tek seferlik göçünde bu fark hissediliyor. Çoğu dosya bir saniyenin altında dönüyor; büyük orijinaller oransal olarak biraz uzasa da ara adıma gerek kalmadan tek seferde tamamlanıyor.

Şu küçük detayı da hatırlamak gerek: WEBP’nin asıl avantajı yalnızca dosya boyutunda değil, aynı zamanda destek verdiği animasyon ve şeffaflık desteğinde. Statik bir JPEG’den WEBP’ye geçtiğinde animasyonu kullanmıyor olabilirsin, ama formatı bir kez WEBP’ye geçirdiğinde aynı asset’in ileride yeniden kullanımı (animasyonlu varyant, GIF yerine kısa döngü) doğrudan mümkün hâle geliyor. Bu, WEBP’nin sadece anlık bir performans tercihi değil, gelecekte ihtiyaç duyacağın seçeneklere kapı açan bir altyapı kararı olduğunun altını çiziyor. JPEG’i WEBP’ye çevirmek, dosyayı bugün küçültürken yarınki potansiyel asset türleri için de zemini hazırlıyor.

WordPress ve Drupal üzerine kurulu, yıllardır yayında olan Türk içerik siteleri için doğrudan etki eden bir senaryo. Büyük WordPress görsel optimizasyon eklentileri — Smush, ShortPixel, Imagify, EWWW — kurulup yapılandırıldıktan sonra JPEG’i otomatik WEBP’ye çeviriyor; ama site ne kadar eskiyse, eklentinin etkin olmadığı dönemden kalan JPEG içerik o kadar fazla oluyor ve eklenti bu eski dosyaları açıkça istemediğin sürece yeniden ele almıyor. Trafiğin hâlâ geldiği eski blog yazılarının (2017’de yayımlanmış ama 2024’te de Google’dan tıklama almaya devam edenler) görselini elle WEBP’ye çevirmek genelde en hızlı yakalanma yolu; dönüşüm yapıldıktan sonra o belirli arşiv sayfalarının hızı anında iyileşiyor, eklentinin toplu işine sıra gelmesini beklemek gerekmiyor. Eski yazıları yeniden ziyaret etmenin başka bir kapısı bu küçük adımdan açılıyor.

Türk e‑ticaretinde Hepsiburada’dan Trendyol’a, ÇiçekSepeti’nden Modanisa’ya kadar görsel ağırlıklı tüm sitelerde sayfa hızı doğrudan dönüşüm oranına bağlanmış durumda. Mobilde sayfanın açılması iki saniyeyi geçtiğinde sepete ekleme oranı hissedilir biçimde düşüyor; üç saniyeyi geçtiğinde kullanıcının sayfa açılmadan önce geri tuşuna basması olağan hâline geliyor. JPEG ürün galerilerini WEBP’ye çevirmek bu eşiği aşağı çekmenin en hızlı tek hamlelerinden biri, çünkü ürün sayfasının byte bütçesinin büyük kısmı genelde galeri görsellerinden oluşuyor. Türkiye’de mobil veri tarifelerinin pek çok kullanıcı için hâlâ bir kısıt olduğu düşünüldüğünde, sayfa başına 1‑2 MB tasarruf, bir aylık veri kotasının yetip yetmemesini doğrudan etkileyen bir ayrıntı; bu da SEO metriklerinin ötesinde gerçek bir kullanıcı deneyimi farkı oluşturuyor.

Yayıncılık tarafına, blog ve haber sitelerine bakanlar için küçük bir gözlem: makale arşivinin görsel ağırlığı zamanla şişiyor ve bunun ne kadar olduğunu kimse takip etmiyor. Üç yıl önce yayınlanmış 800 makale, ortalama 400 KB’lık üç JPEG ile birlikte sayfada toplamda 1,2 MB civarında bir hero ağırlığı taşıyor; aynı görseller WEBP’ye çevrildiğinde sayfa başına 700‑800 KB indirmek mümkün hâle geliyor. Bu farkın asıl etkisi sıralama hızında değil, arama sonuçlarının ön izleme küçük resimlerinin yüklenme süresinde — Google haber kart önizlemesinin görseli yüklenemediğinde tıklama oranı belirgin biçimde düşüyor. Toplu bir migrasyon tek seferlik bir iş olduğu için bu araç çoğu yayıncı için yeterli; her yayın sonrası tek tek dönüştürmek de yine bu sayfa üzerinden yapılabiliyor.