<

Web'de Görsel Optimizasyonu: WebP, AVIF ve Lazy Loading Pratiği

Pazarlama ekibinin "kampanya sayfası neden yavaş" sorusuyla açtığımız incelemede sayfanın ağırlığı 11 megabayt çıktı. Bunun 9,6 megabaytı görseldi ve tek başına kapak görseli 4,2 megabaytlık bir PNG'ydi — tasarımcının dışa aktardığı hâliyle, dokunulmadan yayına konmuş. Görselleri elden geçirdik, başka hiçbir şeye dokunmadık: sayfa ağırlığı 1,1 megabayta indi, LCP 4,8 saniyeden 1,9 saniyeye düştü. Ürün detay sayfalarında da benzer bir temizlikle görsel ağırlığını yüzde doksanın üzerinde azaltmıştık.

Ortalama bir web sayfasının ağırlığının yarısından fazlası görsellerdir; dolayısıyla hız probleminizin de muhtemelen yarısı orada duruyor. Ve güzel haber şu: görsel optimizasyonu, web performansı dünyasının en yüksek getirili, en düşük riskli işidir. Kod değişikliği minimum, kazanç dramatik. Reçetemizi adım adım anlatayım.

Format meselesi: WebP güvenli liman, AVIF iddialı komşu

2026 itibarıyla JPEG ve PNG'yi ham hâlleriyle sunmak için neredeyse hiçbir geçerli sebep kalmadı. WebP bugün güvenli standart: tüm modern tarayıcılarda tam destek, JPEG'e göre kabaca yüzde 25-35 küçük dosya, üstelik şeffaflık desteği de var (PNG'nin tekelini kırdı). AVIF ise daha da iddialı: yüzde 40-50'ye varan ek kazanç sunuyor ve özellikle düşük kalite ayarlarında WebP'den gözle görülür biçimde temiz sonuç veriyor. Tarayıcı desteği artık geniş; bedeli ise encode süresinin uzunluğu — toplu dönüştürmelerde bunu hissedersiniz.

Kalite ayarı konusunda da bir gözlem paylaşayım: çoğu fotoğraf için kalite 75-80 bandı, gözle ayırt edilemeyen sonuç verir. "Kalite 100 olsun, bozulmasın" refleksi dosyayı iki-üç katına şişirir ve o farkı ekranda kimse görmez — ürün görsellerinde kör test yaptık, tasarımcı arkadaşlar dahil kimse 80 ile 95'i ayıramadı. Görselin türü de önemli: fotoğraflar kayıplı formatların alanıdır; logo, ikon ve çizim türü grafiklerde ise SVG varsa her zaman kazanır, yoksa kayıpsız WebP düşünülür.

Pratikte iki strateji öneriyoruz. Titiz olanı: <picture> elemanıyla AVIF → WebP → JPEG sıralı sunum; tarayıcı ne anlıyorsa onu alır, kimse dışarıda kalmaz. Pragmatik olanı: her şeyi WebP'ye çevirip AVIF işini CDN'e bırakmak — modern görsel CDN'leri, isteği yapan tarayıcının desteğine göre formatı anında seçebiliyor. Küçük ve orta ölçekli projelerde genellikle ikinci yol kazanır; basitlik de bir mühendislik değeridir.

Herkese aynı görseli göndermek nezaketsizlik

Format kadar önemli ikinci konu boyut — ve bence görsel israfının asıl büyük kalemi burası. Ekiplerin çoğu formatı konuşurken boyutu unutuyor; oysa yanlış boyut, yanlış formattan çok daha fazla bayt israf eder. 2400 piksel genişliğindeki fotoğrafı 360 piksellik telefon ekranına indirtmek, kullanıcının mobil kotasına da LCP sürenize de hakarettir. (Girişteki 4,2 megabaytlık kapak görseli tam buydu: tasarım dosyasından 5000 piksel genişliğinde çıkmış, sitede 1200 piksellik alanda gösteriliyordu.) Çözüm yıllardır standartta hazır bekliyor: srcset ve sizes öznitelikleriyle aynı görselin 3-4 genişlik varyantını sunarsınız, tarayıcı cihaza uygun olanı seçer. Elle varyant üretmek angarya gibi geliyorsa (haklısınız), CDN'lerin URL parametresiyle anlık boyutlandırma özellikleri bu işi tamamen otomatikleştiriyor.

Retina ekranlar için küçük bir sınır çizelim: gösterim boyutunun 2 katı çözünürlük yeterli. 300 piksellik alanda gösterilen görsel için 600 piksellik varyant idealdir; 1200 piksel göndermek fark yaratmaz, sadece bant genişliği israf eder. "Ne olur ne olmaz, büyüğünü koyalım" içgüdüsü görsel dünyasında hep kaybettirir.

Lazy loading'in en çok yapılan yanlışı

Şimdi kritik bir ayrım — çünkü sahada en sık gördüğümüz LCP hatası tam burada yatıyor. loading="lazy" harika bir araçtır ama ekranın altındaki görseller içindir. Kapak görselini, yani sayfanın en büyük ve ilk görünen elemanını lazy'lemek, tarayıcıya "bunu yüklemeye acele etme" demektir. Sonuç: LCP metriğiniz kendi elinizle gecikir. Tam tersini yapın — LCP görseline fetchpriority="high" verin ki tarayıcı onu kuyruğun başına alsın. Ekran altındaki her şeye ise gönül rahatlığıyla loading="lazy": tarayıcı yerleşik desteğiyle, JavaScript kütüphanesiz, bedava performans.

Aynı bölgede yaşayan ikinci hata, boyutsuz img etiketleri. width/height (ya da CSS'te aspect-ratio) belirtilmeyen görsel, yüklendiği anda sayfa düzenini iter; kullanıcı tam butona basarken içerik zıplar, yanlış yere tıklar. Bunun metrikteki adı CLS, kullanıcıdaki adı sinirdir. Her img etiketinde boyut bilgisi — istisnasız. Bu kadar basit bir kuralın bu kadar sık ihlal edilmesi, açıkçası hâlâ şaşırtıyor beni; yıllar içinde incelediğim sitelerin yarısından fazlasında bu eksikti ve düzeltmesi kelimenin tam anlamıyla iki öznitelik yazmaktan ibaret.

Tek seferlik temizlik değil, çalışan bir hat

Gelelim işin sürdürülebilirlik tarafına, çünkü asıl mesele burası. Yukarıdaki reçeteyle sitenizi bugün pırıl pırıl yaparsınız; üç ay sonra içerik ekibinden biri 6 megabaytlık bir fotoğrafı yönetim panelinden yükler ve emek sessizce erir. Suç o kişide değil — içerik ekleyen kişinin format ve boyut bilmek zorunda olduğu bir sistem, kötü tasarlanmış bir sistemdir.

Bu yüzden platformda optimizasyonu boru hattına gömdük: yükleme anında otomatik dönüşüm (upload → boyut varyantları → WebP/AVIF → CDN). İçerik ekibi de satıcı da panele istediği dosyayı atar; ziyaretçiye giden her zaman doğru format, doğru boyut olur. İyi sistem, doğru davranışı varsayılan yapar — kullanıcısını eğitmeye çalışmaz.

Hattın yanına bir de bekçi koymakta fayda var: CI ya da yayın öncesi kontrol adımına basit bir bütçe kuralı ekliyoruz — "hiçbir sayfa toplamda şu kadar kilobayt görsel aşamaz" gibi. Kural ihlal edildiğinde yayın durur ve konu, kullanıcı şikâyetine dönüşmeden ekip içinde çözülür. Performans bütçesi kulağa kurumsal bir tören gibi geliyor ama pratikte tek satırlık bir eşik kontrolü; kurması yarım saat.

Ölçmeden bırakmayın bu işi. Optimizasyon öncesi ve sonrası Lighthouse skorlarını, LCP değerlerini ve mümkünse dönüşüm oranını kaydedin. Girişte anlattığım 11 megabaytlık vakada yönetimin asıl ikna olduğu an, skor tablosu değil, mobilden gelen sipariş oranındaki artıştı — hız soyut bir erdem değil, ölçülebilir bir gelir kalemi. Rakamla konuşan optimizasyon, bütçe toplantısından her zaman güçlü çıkar.

Son bir hatırlatma: bu reçetenin hiçbir maddesi yeni bir framework, büyük bir refactor ya da altyapı değişikliği istemiyor. Doğru format, doğru boyut, doğru yükleme sırası ve otomatik bir hat — hepsi bu. Web performansında bundan daha yüksek getirili bir hafta geçirmek zor.

Sitenizin görsel karnesini merak ediyorsanız, tarayıcının ağ sekmesini açıp görsel satırlarını toplamak yarım saatinizi alır; çoğu sitede, o 11 megabaytlık kampanya sayfası hikâyesindeki gibi, rakam şaşırtıcı çıkıyor. Bulduklarınızı konuşmayı severim; iletişim sayfası açık.

📅 Yayınlanma:  ·  Yakup Zengin