WebP ve AVIF Format Kullanımı

WebP ve AVIF, geleneksel JPEG ve PNG formatlarına kıyasla aynı görsel kalitede çok daha küçük dosya boyutu üreten yeni nesil görsel sıkıştırma formatlarıdır. 2026 verilerine göre JPEG'den WebP'ye geçiş ortalama %30, AVIF'e geçiş ise ortalama %50 dosya boyutu tasarrufu sağlamaktadır. Görsel ağırlıklı sayfalarda bu tasarruf, LCP süresini doğrudan kısaltarak Core Web Vitals performansını ölçülebilir biçimde iyileştirir.

Görsel Formatların Teknik Sıkıştırma Mekanizmaları

JPEG, 1992'de geliştirilen kayıplı (lossy) sıkıştırma formatıdır. Discrete Cosine Transform (DCT) algoritmasına dayanır ve fotoğraf görselleri için optimize edilmiştir. PNG, kayıpsız (lossless) sıkıştırma sunar ve şeffaflık (alpha channel) desteği barındırır. Bu iki format, web'in ilk 30 yılının standardı olmuştur.

WebP, VP8 video codec'inden türetilmiş bir görsel formattır ve hem kayıplı hem kayıpsız sıkıştırma sunar. AVIF ise AV1 video codec'ine dayanan ve WebP'den daha ileri sıkıştırma oranı sağlayan formattır. Her iki format da modern sıkıştırma algoritmalarının görsel veriye uygulanmasıdır. Bu algoritmalar, insan gözünün algılamadığı detayları daha agresif biçimde kaldırarak dosya boyutunu küçültürken algılanan kaliteyi korur.

WebP Formatının Avantajları ve Tarayıcı Desteği

WebP, JPEG'e kıyasla kayıplı sıkıştırmada %25-34, kayıpsız sıkıştırmada %26 daha küçük dosya boyutu üretir. Animasyon desteği (GIF alternatifi), şeffaflık desteği (PNG alternatifi) ve hem kayıplı hem kayıpsız mod (JPEG ve PNG alternatifi), WebP'yi çok yönlü bir format kılar. Tek format, dört farklı kullanım senaryosunu karşılar.

2026 itibarıyla WebP tarayıcı desteği %97'yi aşmıştır. Chrome, Firefox, Safari, Edge ve Opera'nın güncel versiyonlarının tamamı WebP'yi destekler. Internet Explorer 11 ve çok eski Safari versiyonları (14.0 öncesi) WebP'yi desteklemez ancak bu tarayıcıların toplam pazar payı %1'in altındadır. Dolayısıyla WebP, 2026'da evrensel destek düzeyine ulaşmış bir formattır ve fallback mekanizması çoğu senaryo için gereksizdir.

AVIF Formatının Sıkıştırma Üstünlüğü

AVIF, WebP'den bir nesil ilerisidir. Aynı görsel kalitede JPEG'e kıyasla %50, WebP'ye kıyasla %20 daha küçük dosya boyutu üretir. AV1 codec'inin gelişmiş sıkıştırma algoritmaları, özellikle düşük kalite ayarlarında bile yüksek görsel netlik koruması sağlar. Düşük bant genişliğindeki mobil bağlantılarda bu fark, kullanıcı deneyimini doğrudan etkiler.

AVIF'in dezavantajı, encoding (sıkıştırma) süresinin WebP ve JPEG'e kıyasla belirgin biçimde uzun olmasıdır. Bir görseli AVIF formatına dönüştürmek, JPEG'e dönüştürmekten 10-20 kat daha uzun sürebilir. Bu durum, gerçek zamanlı görsel işleme gerektiren Image CDN servislerinde ek sunucu yükü oluşturur. Build-time'da önceden sıkıştırılmış (pre-compressed) AVIF dosyaları üretmek, bu dezavantajı ortadan kaldırır.

AVIF Tarayıcı Desteği ve Güncel Uyumluluk Durumu

AVIF tarayıcı desteği, WebP'nin gerisindedir ancak hızla genişlemektedir. 2026 itibarıyla Chrome, Firefox, Opera ve Samsung Internet AVIF'i tam destekler. Safari 16.4 ve sonrasında AVIF desteği mevcuttur. Edge, Chromium tabanlı olduğundan Chrome ile aynı desteği sunar. Toplam tarayıcı desteği %92-95 aralığındadır.

Bu destek düzeyi, AVIF'in birincil format olarak kullanılmasını mümkün kılar ancak %5-8'lik desteklenmeme oranı, fallback mekanizmasını zorunlu tutar. <picture> elementi ile AVIF birincil, WebP ikincil ve JPEG fallback olarak sunulmalıdır. Bu kademeli yapı, her tarayıcıya en iyi desteklediği formatı sunarak hem performansı hem de uyumluluğu garanti eder.

picture Elementi ile Format Kademesi Oluşturma

HTML <picture> elementi, tarayıcının desteklediği en iyi formatı otomatik olarak seçmesini sağlayan kademeli format sunumu mekanizmasıdır. Tarayıcı, ilk desteklediği <source> elemanını kullanır ve geri kalanını atlar:

    
<picture>
  <source srcset="/images/hero.avif" type="image/avif">
  <source srcset="/images/hero.webp" type="image/webp">
  <img src="/images/hero.jpg" alt="Açıklayıcı alt text" 
       width="1200" height="630" loading="lazy">
</picture>      
    

Bu yapıda AVIF destekleyen tarayıcı AVIF'i, yalnızca WebP destekleyen tarayıcı WebP'yi, her ikisini de desteklemeyen tarayıcı JPEG'i yükler. <img> etiketi, hem fallback hem de alt, width, height ve loading attribute'lerinin taşıyıcısıdır. <source> elemanlarında type attribute'ünün doğru MIME tipiyle (image/avif, image/webp) belirtilmesi zorunludur; eksik type, tarayıcının format tespitini bozar.

Responsive Görsellerde Format ve Boyut Kademesi

<picture> elementi, format kademesiyle birlikte responsive boyut kademesini de destekler. Farklı ekran boyutları için farklı görsel boyutları ve formatları tek yapıda sunulabilir:

    
<picture>
  <source srcset="/images/hero-400.avif 400w,
                  /images/hero-800.avif 800w,
                  /images/hero-1200.avif 1200w"
          sizes="(max-width: 600px) 100vw, (max-width: 1200px) 80vw, 1200px"
          type="image/avif">
  <source srcset="/images/hero-400.webp 400w,
                  /images/hero-800.webp 800w,
                  /images/hero-1200.webp 1200w"
          sizes="(max-width: 600px) 100vw, (max-width: 1200px) 80vw, 1200px"
          type="image/webp">
  <img src="/images/hero-1200.jpg" alt="Açıklayıcı alt text"
       width="1200" height="630" loading="lazy">
</picture>   
    

Bu yapıda mobil cihaz 400px genişliğindeki AVIF'i, tablet 800px'lik WebP'yi, masaüstü 1200px'lik AVIF'i yükler. Her cihaz, hem formatını hem de boyutunu kendi kapasitesine göre seçer. Bu çift kademeli yapı, bant genişliği tasarrufunu format ve boyut düzeyinde birlikte optimize eder ve her cihaza minimum transfer boyutuyla maksimum görsel kaliteyi sunar.

Komut Satırı ile Toplu Format Dönüşümü

Mevcut JPEG ve PNG görsellerini WebP ve AVIF formatlarına toplu biçimde dönüştürmek, komut satırı araçlarıyla gerçekleştirilir. Google'ın cwebp aracı WebP dönüşümü, avifenc aracı AVIF dönüşümü sağlar:

    
# Tek dosya WebP dönüşümü
cwebp -q 80 input.jpg -o output.webp

# Tek dosya AVIF dönüşümü
avifenc --min 20 --max 40 input.jpg output.avif

# Bash ile toplu WebP dönüşümü
for file in *.jpg; do
  cwebp -q 80 "$file" -o "${file%.jpg}.webp"
done

# Bash ile toplu AVIF dönüşümü
for file in *.jpg; do
  avifenc --min 20 --max 40 "$file" "${file%.jpg}.avif"
done   
    

-q 80 parametresi WebP'de kalite seviyesini belirler; 80, dosya boyutu ve kalite dengesi için optimal değerdir. AVIF'te --min 20 --max 40 parametreleri, kalite aralığını tanımlar. Düşük değer daha yüksek sıkıştırma (küçük dosya, düşük kalite), yüksek değer daha düşük sıkıştırma (büyük dosya, yüksek kalite) üretir.

Build Sürecinde Otomatik Format Üretimi

Modern frontend build araçları, görsel dönüşümünü otomatize eder. Webpack, Vite ve Next.js, build sürecinde görselleri otomatik olarak WebP ve AVIF formatlarına dönüştürür. Bu otomasyon, her yeni görsel eklendiğinde manuel dönüşüm ihtiyacını ortadan kaldırır.

Next.js'in next/image bileşeni, görselleri istek anında (on-demand) otomatik olarak optimize eder ve tarayıcı desteğine göre AVIF veya WebP formatında sunar:

    
import Image from 'next/image';

export default function HeroSection() {
  return (
    <Image
      src="/images/hero.jpg"
      alt="Açıklayıcı alt text"
      width={1200}
      height={630}
      priority
      sizes="(max-width: 768px) 100vw, 80vw"
    />
  );
}   
    

next/image, kaynak görseli JPEG olarak yükler ancak tarayıcıya AVIF veya WebP formatında sunar. Accept header'ına göre en iyi formatı otomatik seçer. priority prop'u, above-the-fold görsellerde preload ve eager loading uygular. Bu otomasyon, <picture> elementi ile manuel format kademesi oluşturma ihtiyacını tamamen ortadan kaldırır.

WordPress'te WebP ve AVIF Entegrasyonu

WordPress 5.8 sürümünden itibaren WebP formatını, 6.5 sürümünden itibaren AVIF formatını native olarak destekler. Medya kütüphanesine WebP ve AVIF dosyaları doğrudan yüklenebilir. Ancak WordPress, yüklenen görselleri otomatik olarak WebP veya AVIF'e dönüştürmez. Mevcut JPEG/PNG görsellerin yeni formatlara dönüştürülmesi için eklenti desteği gerekir.

ShortPixel, Imagify ve EWWW Image Optimizer eklentileri, mevcut görselleri otomatik olarak WebP ve AVIF formatlarına dönüştürür. Bu eklentiler, orijinal JPEG dosyasını korurken yanına WebP ve AVIF versiyonlarını üretir. Sunucu yapılandırması veya eklenti ayarı ile tarayıcının Accept header'ına göre doğru format sunulur. ShortPixel'in yapılandırmasında "WebP/AVIF oluştur" seçeneğini aktifleştirin ve "Sunucu tarafı teslim" yöntemini seçin. Bu yapılandırma, .htaccess dosyasına gerekli rewrite kurallarını otomatik ekler.

Nginx ve Apache Sunucu Yapılandırması

Sunucu düzeyinde content negotiation (içerik müzakeresi), tarayıcının Accept header'ına göre otomatik format seçimi sağlar. Bu yapılandırma, HTML kodunu değiştirmeden mevcut <img> etiketlerinin WebP veya AVIF versiyonlarını sunmayı mümkün kılar.

Nginx yapılandırması:

    
map $http_accept $webp_suffix {
  default "";
  "~*avif" ".avif";
  "~*webp" ".webp";
}

server {
  location ~* \.(jpg|jpeg|png)$ {
    add_header Vary Accept;
    try_files $uri$webp_suffix $uri =404;
  }
}  
    

Apache .htaccess yapılandırması:

    
<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteCond %{HTTP_ACCEPT} image/avif
  RewriteCond %{REQUEST_FILENAME}.avif -f
  RewriteRule ^(.+)\.(jpe?g|png)$ $1.$2.avif [T=image/avif,E=REQUEST_image,L]
  
  RewriteCond %{HTTP_ACCEPT} image/webp
  RewriteCond %{REQUEST_FILENAME}.webp -f
  RewriteRule ^(.+)\.(jpe?g|png)$ $1.$2.webp [T=image/webp,E=REQUEST_image,L]
</IfModule>

<IfModule mod_headers.c>
  Header append Vary Accept env=REQUEST_image
</IfModule>
    

Vary: Accept header'ı, CDN'in aynı URL için farklı formatlarda ayrı cache versiyonları tutmasını sağlar. Bu header olmadan CDN, ilk isteğin formatını tüm kullanıcılara sunabilir ve WebP desteklemeyen tarayıcıya WebP gönderebilir.

Image CDN Servisleri ile Otomatik Format Optimizasyonu

Cloudflare Image Resizing, Cloudinary, imgix ve BunnyCDN gibi Image CDN servisleri, görselleri istek anında otomatik olarak optimize eder. Tarayıcının Accept header'ına göre en uygun formatı seçer, URL parametresiyle boyutlandırır ve kalite ayarını uygular:

    
<!-- Cloudflare Image Resizing -->
<img src="/cdn-cgi/image/format=auto,quality=80,width=800/images/hero.jpg"
     alt="Açıklayıcı alt text" width="800" height="450">

<!-- Cloudinary -->
<img src="https://res.cloudinary.com/demo/image/upload/f_auto,q_80,w_800/hero.jpg"
     alt="Açıklayıcı alt text" width="800" height="450">
    

format=auto veya f_auto parametresi, tarayıcı desteğine göre AVIF, WebP veya JPEG formatını otomatik seçer. Bu otomasyon, sunucu yapılandırması ve <picture> elementi ihtiyacını tamamen ortadan kaldırır. Sahadaki gerçek tecrübemiz gösteriyor ki, Image CDN'e geçiş yapan sitelerin görsel kaynaklı LCP süresi ortalama %35-45 kısalıyor ve bu iyileşme herhangi bir HTML değişikliği gerektirmeden gerçekleşiyor.

Kalite Ayarı ve Dosya Boyutu Dengesi

Sıkıştırma kalite seviyesi, dosya boyutu ile görsel kalite arasındaki dengeyi belirler. Çok düşük kalite (q=30) küçük dosya üretir ancak görsel artefaktlar oluşturur. Çok yüksek kalite (q=100) ise orijinale yakın kalite sunar ancak dosya boyutu tasarrufunu minimize eder.

WebP için optimal kalite aralığı q=75-85'tir. Bu aralıkta insan gözünün algılayamadığı detaylar kaldırılır ancak görsel netlik korunur. AVIF için optimal aralık q=30-50'dir; çünkü AVIF'in sıkıştırma algoritması aynı kalite seviyesinde WebP'den daha iyi sonuç üretir. Fotoğraf görselleri (ürün fotoğrafları, hero görseller) yüksek kalite gerektirir. Dekoratif görseller ve ikon benzeri grafikler daha düşük kaliteyle sunulabilir. Kalite ayarını görsel tipine göre farklılaştırmak, toplamda en yüksek tasarrufu sağlar.

LCP Elemanı Görsellerde Format Stratejisi

LCP elemanı bir görsel olduğunda, o görselin format ve boyut optimizasyonu doğrudan sıralama metriğini etkiler. LCP görseli için AVIF formatı, en küçük dosya boyutunu sunarak indirme süresini minimize eder. Ancak AVIF'in decode (çözümleme) süresi, WebP ve JPEG'e kıyasla daha uzundur. Düşük güçlü mobil cihazlarda AVIF decode süresi, dosya boyutu avantajını kısmen dengeleyebilir.

LCP görseli için optimal strateji: AVIF formatında sunun, fetchpriority="high" ile indirme önceliğini artırın ve <link rel="preload"> ile erken keşfi sağlayın. Decode süresini izlemek için Chrome DevTools Performance sekmesinde "Decode Image" görevinin süresini kontrol edin. Decode süresi 50 ms'yi aşıyorsa ve bu süre LCP'yi olumsuz etkiliyorsa, WebP'ye geri dönmek pragmatik bir karardır.

Şeffaflık Desteği ve PNG Alternatifi Olarak WebP/AVIF

PNG'nin birincil kullanım gerekçesi, alfa kanalı (şeffaflık) desteğidir. Logo, ikon ve şeffaf arka planlı görseller için PNG zorunlu format olarak görülür. Ancak hem WebP hem de AVIF, alfa kanalı desteği sunar ve PNG'den çok daha küçük dosya boyutu üretir.

Şeffaf arka planlı bir logo görseli: PNG formatında 150 KB, WebP formatında 45 KB, AVIF formatında 30 KB olabilir. Bu fark, özellikle site genelinde tekrarlanan görsellerde (header logo, footer ikon setleri) kümülatif tasarruf sağlar. PNG'den WebP/AVIF'e geçiş, şeffaflık ihtiyacı olan görsellerde de uygulanabilir ve dosya boyutunu %60-80 azaltır.

Animasyonlu Görsellerde WebP ve AVIF Alternatifi

GIF formatı, web'deki animasyonlu görsellerin geleneksel standardıdır. Ancak GIF, sınırlı renk paleti (256 renk) ve verimsiz sıkıştırma algoritmasıyla büyük dosya boyutları üretir. 5 saniyelik bir animasyonlu GIF, 2-5 MB boyutuna ulaşabilir. Bu boyut, sayfa yükleme süresini dramatik biçimde uzatır.

WebP animasyon desteği, GIF'e kıyasla %60-80 daha küçük dosya boyutu ve sınırsız renk paleti sunar. AVIF animasyon desteği ise WebP'den de küçük dosya boyutu üretir. Animasyonlu görsellerde GIF'ten WebP'ye geçiş, tek başına yüzlerce kilobayt tasarruf sağlar. <img src="animation.webp"> formatında animasyonlu WebP, GIF ile aynı biçimde kullanılır ve ek JavaScript gerektirmez.

CMS Medya Kütüphanesinde Format Yönetimi

CMS'lere yüklenen görsellerin otomatik biçimde yeni formatlara dönüştürülmesi, operasyonel sürekliliğin ön koşuludur. Manuel dönüşüm, her görselin ayrı ayrı işlenmesini gerektirir ve büyük içerik envanterlerinde sürdürülebilir değildir.

WordPress'te ShortPixel eklentisinin yapılandırması: Ayarlar > ShortPixel > Gelişmiş menüsünde "WebP Görseller Oluştur" ve "AVIF Görseller Oluştur" seçeneklerini aktifleştirin. "Teslim Yöntemi" olarak "CDN aracılığıyla" veya ".htaccess ile" seçin. "Mevcut Görselleri Optimize Et" butonuyla mevcut medya kütüphanesindeki tüm görselleri toplu biçimde dönüştürün. Bu yapılandırma, hem yeni yüklenen hem de mevcut görsellerin otomatik olarak WebP ve AVIF versiyonlarının üretilmesini garanti eder.

CDN Cache ve Vary Header ile Format Yönetimi

Content negotiation ile farklı formatlarda sunulan görseller, CDN cache yönetiminde özel dikkat gerektirir. Aynı URL, farklı tarayıcılara farklı formatta yanıt döndürdüğünde, CDN'in her format için ayrı cache versiyonu tutması zorunludur. Vary: Accept header'ı bu ayrımı sağlar.

Vary: Accept header'ı olmadan CDN, ilk isteğin formatını cache'ler ve sonraki tüm isteklere bu formatı sunar. Chrome kullanıcısı AVIF alırken, Safari kullanıcısı da (AVIF desteklemese bile) cache'teki AVIF'i alır ve görsel gösterilmez. Bu kritik hata, Vary: Accept header'ının sunucu yapılandırmasında doğru biçimde tanımlanmasıyla önlenir. Cloudflare, bu davranışı varsayılan olarak yönetir; ancak özel CDN yapılandırmalarında Vary header'ının açıkça tanımlanması gerekir.

Görsel SEO ve Format Değişikliğinin İndeksleme Etkisi

JPEG'den WebP veya AVIF'e geçiş, görsel arama sonuçlarındaki indekslemeyi etkileyebilir. Content negotiation ile aynı URL'den farklı formatlar sunulduğunda, Google görseli hangi formatta indeksleyeceğini kendi seçer. Google, WebP ve AVIF'i indeksleme kapasitesine sahiptir ve format değişikliği indeksleme kaybına neden olmaz.

Ancak URL değişikliği (eski: /gorsel.jpg, yeni: /gorsel.webp) farklı bir senaryodur. URL değişikliğinde eski URL'den yeni URL'ye 301 yönlendirmesi uygulanmalıdır. Yönlendirme olmadan eski URL 404 döndürür ve o görselin indeksi kaybolur. Content negotiation yaklaşımı (aynı URL, farklı format), URL değişikliği gerektirmediğinden indeksleme riski sıfırdır ve mevcut görsel sıralamalarını korur. Bu nedenle content negotiation, format geçişinin en güvenli yöntemidir.

Lazy Loading ve Format Optimizasyonunun Birlikte Çalışması

Lazy loading ve format optimizasyonu, farklı performans katmanlarını optimize eden tamamlayıcı tekniklerdir. Lazy loading, görselin yükleme zamanlamasını kontrol eder. Format optimizasyonu, görselin dosya boyutunu kontrol eder. İkisi birlikte uygulandığında, hem gereksiz transfer önlenir hem de gerekli transferin boyutu minimize edilir.

Above-the-fold görselde: AVIF/WebP formatı + loading="eager" + fetchpriority="high" + preload. Below-the-fold görselde: AVIF/WebP formatı + loading="lazy". Bu kombinasyon, her görselin hem doğru zamanda hem de en küçük boyutta yüklenmesini garanti eder. İki tekniğin birlikte uygulanması, ayrı ayrı uygulanmasına kıyasla kümülatif performans kazancı üretir.

Retina Ekranlar ve Çoklu Çözünürlük Yönetimi

Retina ekranlar (2x, 3x piksel yoğunluğu), standart ekranlara kıyasla iki veya üç kat daha fazla piksel barındırır. Bu ekranlarda standart çözünürlükteki görseller bulanık görünür. Retina uyumu için görselin 2x boyutunda sunulması gerekir; ancak bu durum dosya boyutunu 4 kata çıkarır.

WebP ve AVIF formatları, bu sorunu hafifletir. 2x boyutundaki AVIF dosyası, 1x boyutundaki JPEG dosyasından küçük olabilir. srcset attribute'ü ile piksel yoğunluğuna göre farklı boyutlar sunulabilir:

    
<img srcset="/images/hero-600.avif 1x,
             /images/hero-1200.avif 2x,
             /images/hero-1800.avif 3x"
     src="/images/hero-1200.avif"
     alt="Açıklayıcı alt text" width="600" height="315">
    

Bu yapıda standart ekran 600px'lik, retina ekran 1200px'lik, 3x ekran 1800px'lik AVIF dosyasını yükler. AVIF'in sıkıştırma üstünlüğü, retina boyutlarında bile dosya boyutunu kontrol altında tutar.

Görsellerde width ve height Tanımının CLS Önleme Etkisi

Format değişikliği sırasında width ve height attribute'lerinin korunması, CLS (Cumulative Layout Shift) önlemenin ön koşuludur. Tarayıcı, width ve height değerlerinden görselin aspect ratio'sunu hesaplar ve görsel yüklenmeden önce alan rezervasyonu yapar. Bu rezervasyon, görselin yüklenmesiyle oluşan layout shift'i tamamen ortadan kaldırır.

Format değişikliğinde boyut bilgisinin kaybolması yaygın bir hatadır. JPEG'den WebP'ye dönüşüm sırasında <img> etiketindeki width ve height attribute'lerinin korunduğundan emin olun. CSS aspect-ratio özelliği, attribute alternatifi olarak kullanılabilir: aspect-ratio: 16/9 tanımı, görselin oranını CSS düzeyinde bildirir ve alan rezervasyonunu garanti eder.

Mevcut Görsel Envanterinin Toplu Dönüşüm Stratejisi

Büyük içerik envanterlerinde binlerce JPEG ve PNG görseli WebP/AVIF formatına dönüştürmek, sistematik bir migrasyon projesidir. Bu proje üç aşamada yürütülür.

Birinci aşama, envanter analizi: Screaming Frog ile site genelindeki tüm görselleri tarayarak format, boyut ve dosya boyutu verilerini çıkarın. JPEG ve PNG görsellerin toplam sayısını ve dosya boyutunu hesaplayın. İkinci aşama, toplu dönüşüm: komut satırı araçları veya CMS eklentileri ile tüm görselleri WebP ve AVIF formatlarına toplu biçimde dönüştürün. Üçüncü aşama, sunucu yapılandırması: content negotiation veya <picture> elementi ile yeni formatların sunumunu aktifleştirin. Çoğu uzman aksini iddia etse de, content negotiation yaklaşımı HTML değişikliği gerektirmediğinden en düşük riskli ve en hızlı uygulanan yöntemdir.

Performans İzleme ve Format Optimizasyonu Etkisinin Ölçümü

Format dönüşümünün etkisini ölçmek, optimizasyonun getirisini doğrulamanın ön koşuludur. Chrome DevTools Network sekmesinde "Img" filtresi uyguladığınızda, görsellerin format, boyut ve transfer süresi bilgilerini görebilirsiniz. Dönüşüm öncesi ve sonrası toplam görsel transfer boyutunu karşılaştırarak tasarrufu hesaplayın.

Search Console'daki Core Web Vitals raporunda, format optimizasyonu sonrasında LCP metriğinin iyileşip iyileşmediğini izleyin. PageSpeed Insights ile bireysel sayfa düzeyinde AVIF/WebP etkisini ölçün. LinkedIn üzerindeki web performans topluluklarında paylaşılan optimizasyon raporları gösteriyor ki, JPEG'den AVIF'e tam geçiş yapan sitelerin LCP süresinde medyan %30-40 iyileşme gözlemleniyor.

Görsel Format Kontrol Listesi ve Operasyonel Standartlar

Her teknik denetimde uygulanması gereken görsel format kontrol noktaları şunlardır:

• Site genelindeki görsellerin format dağılımını kontrol edin: JPEG ve PNG oranı %20'nin üzerindeyse, WebP/AVIF dönüşüm projesi başlatın.
• picture elementi veya content negotiation yapılandırmasını doğrulayın: AVIF birincil, WebP ikincil ve JPEG fallback kademesinin doğru çalıştığını test edin.
• Vary: Accept header'ının tanımlı olduğunu kontrol edin: CDN'in farklı formatlar için ayrı cache versiyonları tuttuğunu doğrulayın.
• LCP görselinin AVIF veya WebP formatında sunulduğunu teyit edin: Above-the-fold birincil görselin optimize formatta sunulduğunu Chrome DevTools ile kontrol edin.
• width ve height attribute'lerinin korunduğunu doğrulayın: Format dönüşümü sonrasında boyut bilgisinin kaybolmadığını ve CLS riski oluşmadığını teyit edin.
• CMS eklenti yapılandırmasının aktif olduğunu kontrol edin: Yeni yüklenen görsellerin otomatik olarak WebP/AVIF versiyonlarının üretildiğini doğrulayın.

Format Optimizasyonunun Uzun Vadeli Yönetimi

İşin mutfağında durum farklıdır: WebP ve AVIF dönüşümü tek seferlik bir proje olarak düşünülür ancak sürekli bakım gerektiren bir süreçtir. Yeni yüklenen görsellerin otomatik dönüşümü, CMS eklenti yapılandırmasına bağlıdır. Eklenti devre dışı kalırsa veya güncellenirse, yeni görseller JPEG olarak kalır ve optimizasyon zinciri kırılır.

Teoride doğru görünen ama pratikte patlayan nokta şudur: "eklentiyi kurduk, otomatik dönüşüm aktif" varsayımı, eklenti güncellemesi veya sunucu değişikliği sonrasında sessizce bozulabilir. Aylık periyotlarla Screaming Frog ile site genelindeki görsel formatlarını tarayarak, optimize edilmemiş JPEG/PNG dosyalarını tespit edin. Yeni yüklenen görsellerin WebP/AVIF versiyonlarının üretildiğini doğrulayın. Content negotiation veya <picture> kademesinin doğru çalıştığını farklı tarayıcılarla test edin. Bu periyodik kontrol, görsel optimizasyonunun sürekli çalışır durumda kalmasını garanti eden tek sürdürülebilir yaklaşımdır.