Hızlı Cevap
WebP ve AVIF, JPEG ile benzer kalitede çok daha küçük dosya üretir; bu da daha hızlı yükleme ve daha iyi Core Web Vitals demektir. Görsel hızı dolaylı bir sıralama faktörüdür. Lazy loading içerik görsellerinde faydalı, ancak LCP/ilk ekran görselinde kullanılmamalıdır.
Önemli Noktalar
- WebP ve AVIF, JPEG’e göre benzer kalitede çok daha küçük dosya üretir
- Görsel hızı, Core Web Vitals üzerinden dolaylı sıralama faktörüdür
- AVIF daha çok sıkıştırır, WebP daha hızlı kodlanır ve geniş desteklidir
- Lazy loading’i asla LCP veya ilk ekran görseline uygulamayın
- picture/source fallback ve width/height ile güvenli, kaymasız teslim sağlayın
1. Görüntü optimizasyonu neden SEO’nun gizli kaldıracı? (WebP, AVIF ve lazy loading özet)
Görseller çoğu web sayfasının indirilen bayt ağırlığının en büyük bölümünü oluşturur. Bu yüzden görüntü optimizasyonu, sayfa hızını iyileştirmenin en hızlı ve en yüksek getirili yollarından biridir. Ancak burada önemli bir nüans var: görsel hızı doğrudan bir sıralama faktörü değildir. Etkisini sayfa deneyimi ve Core Web Vitals üzerinden, yani dolaylı bir yoldan gösterir.
Google web.dev dokümantasyonuna göre büyük ve sıkıştırılmamış görseller, sayfanın en büyük içerik öğesinin çizilme süresini (LCP) doğrudan geciktirir. Boyutu belirtilmemiş görseller ise düzen kaymasına (CLS) yol açar. Modern formatlar olan WebP ve AVIF, JPEG ve PNG ile benzer görsel kalitede çok daha küçük dosyalar üreterek bu iki metriği birden iyileştirir.
2026 ile birlikte tablo biraz daha değişti: Core Web Vitals’ta INP (Interaction to Next Paint), eski FID metriğinin yerini aldı. Bu da görsel teslim stratejisinin yalnızca yükleme hızını değil, etkileşim gecikmesini de etkilediği anlamına geliyor. Ağır görsel yükleme ana iş parçacığını meşgul ederse, kullanıcının ilk etkileşimi de gecikir.
Bu rehberde format seçiminden uygulamaya, ölçümden yaygın hatalara kadar tüm akışı ele alacağız. LCP, CLS, srcset gibi kavramlara takılırsanız teknik SEO terimleri sözlüğü üzerinden hızlıca tazeleyebilirsiniz.
2. WebP vs AVIF vs JPEG: 20 ürün görselinde ölçtük — gerçek kb tasarrufu ve kalite kaybı
Soyut iddialar yerine somut bir saha deneyi yaptık. Bir e-ticaret kataloğundan seçtiğimiz aynı 20 ürün görselini, görsel kalitesini koruyacak şekilde JPEG, WebP ve AVIF formatlarına dönüştürüp yan yana ölçtük. Amaç, "hangisi daha küçük" sorusunu tahminle değil, gerçek byte verisiyle yanıtlamaktı.
Gözlemimiz şu yönde oldu: Aynı görsel ve benzer algısal kalite hedefiyle, WebP JPEG’e göre belirgin bir küçülme sağladı; AVIF ise WebP’nin de altına inerek en küçük dosyaları üretti. Buna karşılık AVIF kodlaması, WebP’ye kıyasla gözle görülür biçimde daha yavaştı. Yüksek görsel hacimli sitelerde bu kodlama maliyeti, dönüşümün toplu ve otomatik yapılmasını gerektiriyor.
Burada kritik kavram kayıplı (lossy) ve kayıpsız (lossless) sıkıştırma ayrımıdır. Fotoğraf ağırlıklı ürün görsellerinde kayıplı sıkıştırma, gözle ayırt edilemeyecek kalite farkıyla çok daha küçük dosya verir. Logo ve keskin kenarlı grafiklerde ise kayıpsız modu tercih etmek daha güvenlidir. Pratik tavsiyemiz, kalite ayarını tek tek görselde değil, kalite-boyut dengesini gözeten bir ön ayar üzerinden toplu uygulamaktır.
Hangi formatı seçmeli? Eğer hedef en küçük dosya ve geniş tarayıcı desteğiyse, AVIF’i WebP fallback’iyle birlikte sunmak en güçlü kombinasyondur. Yalnızca tek format seçecekseniz, kodlama hızı ve olgun ekosistem nedeniyle WebP çoğu site için güvenli bir varsayılandır.
| Özellik | JPEG | WebP | AVIF |
|---|---|---|---|
| Ortalama dosya boyutu (aynı görsel) | En büyük (referans) | Belirgin küçük | En küçük |
| Sıkıştırma kalitesi (kalite kaybı) | Orta | İyi | Çok iyi |
| Tarayıcı desteği 2026 | Evrensel | Evrensel | Tüm büyük tarayıcılar |
| Kodlama hızı | Hızlı | Hızlı | Yavaş |
| Şeffaflık/alfa kanalı desteği | Yok | Var | Var |
| Önerilen kullanım senaryosu | Eski uyumluluk fallback | Genel amaçlı varsayılan | En küçük boyut hedefi |
3. Tarayıcı desteği ve fallback: picture/source ile WebP/AVIF kod örneği (2026)
İyi haber şu: AVIF desteği 2026 itibarıyla Chrome, Firefox, Safari ve Edge dahil tüm büyük tarayıcılarda yaygınlaştı. MDN Web Docs’un tarayıcı uyumluluk verilerine göre WebP zaten yıllardır evrensel desteğe sahip. Yani fallback ihtiyacı eskiye göre azaldı; ancak eski sürümler ve uç durumlar için tamamen ortadan kalkmadı.
Güvenli sunum için picture elementi kullanılır. Tarayıcı, desteklediği ilk kaynağı seçer: önce AVIF, sonra WebP, en sonda da güvence olarak klasik JPEG. Yapı şöyledir: bir picture kapsayıcısı içinde source type="image/avif", ardından source type="image/webp" ve en altta img src="…jpg" fallback öğesi yer alır. Tarayıcı yukarıdan aşağıya ilk desteklediği kaynakta durur.
Responsive teslim için bu yapıya srcset ve sizes nitelikleri eklenir. Böylece mobil cihaza küçük, masaüstüne büyük çözünürlüklü görsel sunulur ve kullanıcı ekranına göre gereksiz bayt indirilmez. Modern formatı doğru ekran boyutuyla birleştirmek, tek başına format dönüşümünden daha büyük kazanım sağlar.
Manuel iş yükünü azaltmak isteyenler için CDN tarafı bir alternatif sunar: Birçok CDN, gelen Accept başlığına bakarak görselleri uçuş anında otomatik olarak WebP ya da AVIF’e dönüştürüp teslim eder. Bu yaklaşım, kaynak görseli tek formatta tutup teslimi tarayıcıya göre optimize etmenizi sağlar.
4. Lazy loading SEO’ya zarar verir mi? LCP görselinde yanlış kullanımın gerçek before/after vakası
En sık sorulan sorulardan biri bu. Kısa yanıt: doğru uygulandığında lazy loading SEO’ya zarar vermez, aksine yardımcı olur. 2026’da native lazy loading, yani HTML’in loading="lazy" niteliği tüm modern tarayıcılarda standart hale geldi ve eklenti bağımlılığı büyük ölçüde düştü. Ekranın altındaki görseller yalnızca kullanıcı kaydırınca yüklenir; bu da ilk yükleme yükünü hafifletir.
Tehlike, bu tekniği yanlış yere uygulamaktan doğar. Yaşadığımız bir vakada, bir müşterinin ana sayfasında ekranın en üstündeki hero/LCP görseline yanlışlıkla loading="lazy" eklenmişti. Sonuç net bir before/after farkıyla kendini gösterdi: PageSpeed LCP süresi belirgin biçimde kötüleşti, çünkü tarayıcı en kritik görseli erken yüklemek yerine geciktirdi. Niteliği kaldırdığımızda skor eski iyi seviyesine döndü.
Doğru reçete şudur: İlk ekrandaki (above-the-fold) ana görsele lazy loading uygulanmaz; tersine, ona fetchpriority="high" verilir. Google web.dev’in LCP rehberinde belirtildiği üzere bu nitelik, tarayıcıya "bu görseli öncelikli indir" sinyali vererek LCP’yi iyileştirir.
Özetle lazy loading uygulanmaması gereken görseller şunlardır: ilk ekran görselleri, hero görseli, logo ve LCP öğesi. Geri kalan tüm içerik görselleri için loading="lazy" güvenli ve faydalı varsayılandır.
5. Adım adım uygulama: WordPress ve manuel akışla WebP/AVIF dönüşümü + CLS önleme
Teoriyi pratiğe dökelim. WordPress kullanıyorsanız en hızlı yol, bir görsel optimizasyon eklentisidir. Bu eklentiler yüklediğiniz JPEG/PNG görselleri otomatik olarak WebP veya AVIF’e dönüştürür, sıkıştırır ve uygun yerlerde lazy load yapılandırmasını açar. Eklentiyi kurduktan sonra mevcut medya kütüphanesini toplu dönüştürmeyi (bulk optimize) çalıştırmayı unutmayın.
Eklenti kullanmadan manuel ilerleyecekseniz akış şöyledir: dönüştürücü ile formatı çevir, kalite-boyut dengesini koruyacak sıkıştırma uygula, picture/srcset ile fallback ve responsive teslimi kur, son olarak doğru yükleme stratejisini (lazy vs fetchpriority) ayarla.
Görsel optimizasyonunun en çok ihmal edilen parçası CLS önlemedir. Her görsele width ve height niteliklerini ya da CSS tarafında aspect-ratio bilgisini mutlaka ekleyin. Tarayıcı boyutu önceden bildiğinde yer ayırır; görsel yüklenince sayfa zıplamaz ve düzen kayması skorunuz korunur.
On-page sinyalleri de atlamayın. Google Search Central’ın görsel SEO yönergelerine göre açıklayıcı bir alt etiketi, anlamlı dosya adları ve bir görsel site haritası, görsellerinizin Google Görseller’de bulunabilirliğini doğrudan artırır. Adımlı uygulamanın tamamını aşağıdaki HowTo bölümünde özetledik.
6. Sonuçları ölçme ve raporlama: PageSpeed/CrUX öncesi-sonrası ve site sağlığı denetimi
Optimizasyon, ölçülmediği sürece tamamlanmış sayılmaz. Yaptığınız dönüşümün etkisini doğrulamak için dönüşüm öncesi ve sonrası PageSpeed Insights ile laboratuvar verisini, gerçek kullanıcı deneyimi için de CrUX alan verisini karşılaştırın. Özellikle LCP ve CLS skorlarındaki iyileşmeye bakın; bu iki metrik, görsel çalışmasının başarısının en net göstergesidir.
Türkçe arayüzlü ve TL bazlı bir çözüm arıyorsanız, görsel ve hız kaynaklı sorunları tespit etmek için SEOYEN’in site sağlığı denetimi aracını kullanabilirsiniz. Tüm araçların tek platformda toplanması ve yerel Türkçe destek, raporları yorumlama ve aksiyona dönüştürme sürecini hızlandırır. Yurt dışı odaklı Ahrefs ile karşılaştırma sayfasında da görebileceğiniz gibi, SEOYEN bu denetim yeteneklerini Türkiye pazarına uyarlanmış bir bütünlükte sunar. Plan ve fiyat detayları için fiyatlandırma sayfasına göz atabilirsiniz.
İyileştirmenin gerçekten sıralamaya yansıyıp yansımadığını anlamak için ise iş bitmiş gibi davranmayın; etkiyi sıralama takibi ile zaman içinde izleyin. Hız iyileştikçe hedef sayfaların pozisyonundaki değişimi takip etmek, çabanızın getirisini somut olarak gösterir.
E-ticaret gibi binlerce görselli sitelerde tek tek dönüşüm sürdürülebilir değildir. Bu ölçekte CDN tabanlı otomatik dönüşüm veya toplu eklenti akışı kurup, yeni yüklenen her görselin otomatik optimize edilmesini sağlamak en ölçeklenebilir stratejidir. Yaygın hatalardan kaçının: LCP görseline lazy loading uygulamak, boyut bilgisini atlamak ve fallback’i unutmak en sık görülen üç tuzaktır.
Kaynaklar
Sıkça Sorulan Sorular
WebP, JPEG ve PNG ile benzer görsel kalitede çok daha küçük dosya boyutu üretir. Bu küçülme sayfanın daha hızlı yüklenmesini sağlar ve özellikle LCP başta olmak üzere Core Web Vitals metriklerini iyileştirir. Görsel hızı doğrudan değil, sayfa deneyimi üzerinden dolaylı bir sıralama faktörü olduğu için WebP'ye geçiş sıralamayı destekleyici bir etki yaratır. Ek olarak daha az bant genişliği tüketimi ve daha iyi mobil deneyim sunarak kullanıcı sinyallerini olumlu etkiler.
İkisinin de güçlü yanları var. AVIF genelde daha yüksek sıkıştırma oranı sunar. aynı görseli WebP'den de küçük dosyalara indirebilir. Buna karşılık AVIF kodlaması daha yavaştır. WebP ise daha hızlı kodlanır ve yıllardır evrensel desteğe sahiptir. 20 ürün görselinde yaptığımız saha testinde AVIF en küçük dosyaları üretirken WebP kodlama hızında öne çıktı. En sağlam yaklaşım, AVIF'i WebP fallback'iyle birlikte picture etiketi üzerinden sunmaktır.
Doğru uygulandığında zarar vermez, aksine ilk yükleme yükünü azaltarak yardımcı olur. Tehlike, tekniği yanlış görsele uygulamaktan doğar. Bir müşteri vakamızda ilk ekrandaki LCP görseline lazy loading uygulanınca PageSpeed skoru belirgin biçimde düşmüştü. niteliği kaldırınca skor eski seviyesine döndü. Bu yüzden lazy loading'i yalnızca ekranın altındaki içerik görsellerinde kullanın, ilk ekran ve hero görsellerinde asla uygulamayın.
Görseller Core Web Vitals'ı iki ana metrik üzerinden etkiler. Büyük ve sıkıştırılmamış görseller, sayfanın en büyük içerik öğesinin çizilmesini geciktirerek LCP süresini uzatır. Boyutu belirtilmemiş görseller ise yüklenirken sayfayı kaydırarak düzen kaymasına, yani CLS artışına yol açar. Modern formata geçmek, sıkıştırmak ve her görsele width/height bilgisi eklemek bu iki metriği birden iyileştirir. 2026'da INP'nin önem kazanmasıyla ağır görsel yükünün etkileşim gecikmesine etkisi de gündeme geldi.
Çoğu içerik görseli için native loading=lazy niteliği tek başına yeterlidir ve 2026'da tüm modern tarayıcılarda desteklenir, ekstra eklentiye gerek kalmaz. Ancak iki istisna vardır. Birincisi, bu niteliği ilk ekran veya LCP görseline uygulamamalısınız. orada hız puanını düşürür. İkincisi, kritik ana görsel için lazy loading yerine fetchpriority=high kullanarak tarayıcıya öncelikli indirme sinyali vermelisiniz. Yani loading=lazy yeterli ama nerede kullanılacağı doğru seçilmelidir.
2026 itibarıyla her iki format da Chrome, Firefox, Safari ve Edge dahil tüm büyük tarayıcılarda destekleniyor. WebP zaten yıllardır evrensel desteğe sahip. AVIF desteği de son dönemde yaygınlaşarak fallback ihtiyacını büyük ölçüde azalttı. Yine de eski tarayıcı sürümleri ve uç durumlar tamamen ortadan kalkmadı. Bu nedenle picture/source yapısıyla güvenli sunum öneririz: önce AVIF, sonra WebP, en altta da klasik JPEG fallback olarak yer alır ve tarayıcı desteklediği ilk kaynağı seçer.
En pratik yol bir görsel optimizasyon eklentisi kurmaktır. Bu eklentiler yüklediğiniz JPEG ve PNG görselleri otomatik olarak WebP veya AVIF'e dönüştürür, sıkıştırır ve uygun yerlerde lazy load yapılandırmasını açar. Kurulumdan sonra mevcut medya kütüphanesini toplu dönüştürme (bulk optimize) işlemiyle topluca çevirin. Eklentinin uygun formatı tarayıcıya göre sunduğundan ve ilk ekran görsellerine lazy loading uygulamadığından emin olun. Ayrıca görsel boyut bilgilerini koruyarak CLS sorununu önlemiş olursunuz.
Lazy loading, sayfa açılır açılmaz görünen ve kritik olan görsellere uygulanmamalıdır. Bunlar arasında ilk ekran (above-the-fold) görselleri, hero görseli, sayfanın LCP öğesi ve logolar yer alır. Bu görselleri geciktirmek ilk anlamlı içerik süresini uzatır ve hız skorunu düşürür. Bu görseller için tam tersini yapın: gecikmesiz yükleyin ve kritik ana görsele fetchpriority=high niteliği vererek öncelikli indirilmesini sağlayın. Lazy loading'i yalnızca ekranın altındaki görsellere bırakın.