Image optimization: WebP, AVIF, responsive images stratejisi

Performans projelerinin çoğu görsel optimizasyonuyla %50’lik kazancı zaten yakalıyor. WebP, AVIF, responsive images, lazy loading doğru kombinlendiğinde LCP dramatic iyileşme gösteriyor.

Son 3 e-ticaret projesinde görsel optimizasyonundan öğrendiklerim.

Sorunun boyutu

Bir WooCommerce projesinde audit yaptığımda sayfa ağırlığı 4.2 MB’dı, bunun 3.1 MB’ı görsel, 2.8 MB’ı ise tek bir banner JPEG. LCP 4.8 saniye, mobile kullanıcıların yarısı sayfayı hiç göremeden kaçıyordu.

Sorun 3 katmanda:
1. Yanlış format (JPEG/PNG 2020’lerin default’u değil)
2. Yanlış boyut (2400px viewport için 3840px görsel)
3. Yanlış yükleme timing’i (below-the-fold her şey eager yükleniyor)

WebP: default artık

2024’e kadar WebP hala “modern tarayıcılar için” idi, 2026’da browser support %98+. Internet Explorer dışında her şey destekliyor. Safari, Firefox, Chrome, Edge hepsi WebP render ediyor.

WebP avantajları:
– JPEG’e göre %25-35 daha küçük (aynı kalitede)
– PNG’ye göre %50-80 daha küçük (transparent desteği var)
– Lossless ve lossy her iki modu destekler

WebP’ye geçmenin yolu: bir kerelik conversion yapmak değil, CDN seviyesinde auto-format serve etmek. Cloudflare Polish, Imgix, Cloudinary, Bunny Optimizer – kullanıcının browser’ına bakıp uygun format serve ediyorlar.

WordPress’te wp-content/uploads/ altındaki tüm JPEG’i WebP’ye çeviren plugin’ler var (EWWW, ShortPixel, Smush). Ben ShortPixel’i tercih ediyorum, CDN entegrasyonu iyi.

AVIF: daha iyi ama henüz default değil

AVIF WebP’den de küçük file size veriyor (%30-50 daha küçük), ama:
– iOS Safari AVIF desteği 16.0+
– Encoding CPU-heavy, batch conversion’da 10x daha yavaş
– Resim kalitesinde bazı edge case’lerde artifact oluşturabiliyor

AVIF’i default yapmak yerine progressive enhancement olarak kullanıyorum:

<picture>
    <source type="image/avif" srcset="hero.avif">
    <source type="image/webp" srcset="hero.webp">
    <img src="hero.jpg" alt="...">
</picture>

Browser AVIF destekliyorsa onu alır, yoksa WebP, yoksa JPEG. En iyi format kazanır.

Responsive images: srcset + sizes

Tek boyut görsel 2026’da affedilemez. 360px mobile, 1920px desktop’a aynı görseli serve etmek bandwidth’i harcamak demek.

srcset + sizes kombinasyonu browser’a şunu söylüyor: “Bu görsel bu boyutlarda mevcut, viewport şu ise şunu al”.

<img
    src="product-800.jpg"
    srcset="product-400.jpg 400w, product-800.jpg 800w, product-1200.jpg 1200w, product-1600.jpg 1600w"
    sizes="(max-width: 600px) 400px, (max-width: 1200px) 800px, 1200px"
    alt="Product"
    loading="lazy"
>

sizes browser’a layout’ta görsel kaç piksel olacağını söyler. Browser viewport + DPR’e göre en uygun srcset varyantını seçer.

WordPress’te bu otomatik: wp_get_attachment_image() veya the_post_thumbnail() kullanırsanız WordPress srcset’i otomatik üretir. Manuel yazıyorsanız sizes’ı doğru ayarlamanız gerek.

Image dimensions: explicit her zaman

tag’ine width ve height yazmak CLS (Cumulative Layout Shift) için kritik. Browser boyutu bilmeden layout boşluğu ayıramıyor, görsel yüklenince layout kayıyor.

<img src="..." width="800" height="600" alt="...">

Aspect ratio önemli, gerçek pixel boyutu değil. 800×600 veya 400×300 aynı aspect ratio’yu ifade eder, browser 4:3 boşluk açar, CSS ile actual size belirlenir.

aspect-ratio CSS property de aynı işi yapıyor:

img { aspect-ratio: 16 / 9; width: 100%; height: auto; }

Birinci yöntem HTML’de native support, ikinci yöntem CSS-side control. Ben mümkünse ikisini birlikte kullanıyorum.

Lazy loading: native yetiyor

Native loading="lazy" attribute 2024’te Chrome, Firefox, Safari, Edge hepsinde destekleniyor. IntersectionObserver ile custom lazy loading JS yazmaya gerek yok.

Tek istisna: LCP elementini lazy yapmayın. Hero image, fold üstü featured image eager yüklenmeli, yoksa LCP vuruyor.

<!-- Hero (LCP) -->
<img src="hero.jpg" fetchpriority="high" loading="eager">

<!-- Below the fold -->
<img src="gallery-2.jpg" loading="lazy">

fetchpriority="high" browser’a “bu görsel öncelikli” sinyali veriyor. LCP görselinde bunu kullanın.

Blur placeholder veya skeleton

Görsel yüklenirken boş alan göstermek kötü deneyim. İki yaklaşım:

LQIP (Low Quality Image Placeholder). 20-30 piksellik blur’lu bir base64 inline görsel. Yüklenme başlar başlamaz blurry önizleme görünür, asıl görsel gelince fade-in olur. Plaiceholder, sharp kütüphaneleri bu üretiyor.

Skeleton. Gri dikdörtgen animasyonu. LQIP kadar güzel değil ama generic ve hızlı implement.

WooCommerce ürün listesi sayfasında LQIP ile hover hissi çok daha premium oluyor. İmplementation 1 gün, etkisi aylarca.

Image CDN: kendi dönüştürme altyapınızı kurmayın

Image CDN (Cloudinary, Imgix, Cloudflare Images, Bunny CDN) şunları çözüyor:

• On-the-fly format conversion (URL’ye parametre ekleyerek WebP/AVIF)
• On-the-fly resize (400w, 800w dinamik oluşuyor)
• On-the-fly quality adjustment
• Global edge cache
• Smart crop (ML tabanlı focal point detection)

Aylık 50 USD’ye daha fazla tasarruf veriyor. Kendi image processing pipeline’ını kurmak, ImageMagick server’ları yönetmek, cache invalidation düşünmek, format matris’ini koda yazmak zaman kaybı.

Performance impact: gerçek rakamlar

Bir WooCommerce projesinde image optimization öncesi/sonrası:

• Average page weight: 4.2 MB → 1.1 MB (-74%)
• LCP (mobile p75): 4.8s → 2.3s (-52%)
• TTFB etkisi: yok (CDN edge cache)
• Mobile bounce rate: -%18
• Conversion rate: +%9

Conversion rate %9 artışı, image optimization yıllık geri dönüşü altı haneli. Basit yatırım.

Audit checklist

Bir sitede image audit yaparken:

• [ ] WebP/AVIF serve ediliyor mu? (curl ile Accept header kontrol)
• [ ] srcset doğru varyantlar üretiyor mu? (DevTools network panel)
• [ ] sizes attribute layout’a uygun mu?
• [ ] width/height explicit mi?
• [ ] Below-fold görseller lazy mi?
• [ ] LCP görseli eager mi, fetchpriority=high mi?
• [ ] Image CDN kullanılıyor mu?
• [ ] Placeholder stratejisi var mı?

Bu listeyi her yeni projede çıkarıyorum. Eksik olan madde sayısı genelde sayfa hızı puanıyla doğru orantılı.