Görselleri WebP'ye Dönüştürme: Site Hızını Artıran Yöntemler

PageSpeed raporunu açtığınızda listenin üst sıralarında hemen her zaman aynı satır durur: "Görselleri yeni nesil formatlarda sunun". Altında da onlarca dosya adı ve yanlarında kazanılabilecek kilobayt miktarı sıralanır. Bir sayfanın toplam ağırlığının çoğunlukla yarısından fazlasını görseller oluşturur; yani CSS'i sıkıştırmadan, JavaScript'i ertelemeden önce bakılacak yer burasıdır. WebP dönüştürme işleminin bu kadar sık önerilmesinin sebebi de basittir: aynı görüntü kalitesinde JPEG'e göre belirgin biçimde küçük dosya üretir.

Ama iş "dosyaları bir araca atıp WebP indirmek"ten ibaret değil. Toplu dönüşümden sonra eski .jpg URL'lerine ne olacağı, aynı görselin telefonda 400 piksel yerine 2000 piksel indirilmesinin dönüşüm kazancını nasıl sıfırladığı, sunucu tarafında otomatik sunum yapmanın nasıl kurulduğu ve WebP ile AVIF arasında hangi durumda hangisinin seçileceği — Türkçe kaynaklarda genellikle atlanan kısımlar bunlar. Bu yazıda dönüşüm komutlarından başlayıp srcset, .htaccess yönlendirmesi, WordPress medya kütüphanesi ve doğrulama adımlarına kadar tüm zinciri kuracağız.

WebP Nedir ve Neden JPEG'den Küçük#

WebP, hem kayıplı hem kayıpsız sıkıştırma yapabilen, saydamlık (alfa kanalı) ve animasyon destekleyen bir görsel formatıdır. Tek başına "yeni nesil format" başlığı altındaki tüm ihtiyaçları karşılar: JPEG'in yerini kayıplı modda, PNG'nin yerini kayıpsız ve saydam modda, GIF'in yerini animasyonlu modda alır.

Küçüklüğünün teknik nedeni, video kodlama tekniklerinden gelen blok tahmini kullanmasıdır. JPEG her 8×8 bloğu bağımsız işlerken WebP komşu blokların değerlerinden tahmin üretir ve sadece farkı saklar. Düz renk geçişlerinin çok olduğu fotoğraflarda ve arayüz görsellerinde bu fark dramatiktir.

Pratikte gözlemlenen kazanç oranları görsel tipine göre değişir:

Son satır önemli: SVG'yi WebP'ye çevirmeyin. Vektör dosyayı piksele çevirmek hem büyütür hem ölçeklenebilirliği yok eder. PageSpeed bazen SVG'leri de listeye dahil eder; o uyarıyı yok sayın.

Hangi Görsel Dönüştürülmeli Hangisi Kalmalı#

Dönüştürmeden önce envanter çıkarın. En ağır dosyaları bulmak için hosting hesabınıza SSH ile bağlanıp tek komut yeterlidir:

find ~/public_html -type f \( -iname '*.jpg' -o -iname '*.jpeg' -o -iname '*.png' \) \
  -printf '%s\t%p\n' | sort -rn | head -30 | awk '{printf "%.1f KB\t%s\n", $1/1024, $2}'

Bu komut en büyük 30 görseli boyutuyla listeler. Kararı şu sırayla verin:

1. 200 KB üstü her dosya dönüşüm adayıdır, istisnasız.
2. 50-200 KB arası dosyalar dönüşümden fayda görür ama önce boyut kontrolü yapın; çoğu zaman asıl sorun formatta değil, gereksiz büyük piksel ölçüsündedir.
3. 50 KB altı dosyalar için dönüşüm zahmetine değmeyebilir; toplu betiğe dahil edin ama tek tek uğraşmayın.
4. SVG ve ICO dosyalarına dokunmayın.

Görselin gerçek piksel ölçüsünü kontrol etmeyi ihmal etmeyin. Bir slider görselinin 4000×3000 piksel olarak yüklenip CSS ile 1200 piksele küçültülmesi, dünyanın en iyi formatıyla bile telafi edilemez.

#Kurulu ise ImageMagick ile ölçü ve boyut listesi
identify -format "%f %wx%h %b\n" ~/public_html/wp-content/uploads/2026/*/*.jpg | head -20

Tek Tek ve Toplu Dönüştürme Komutları#

WebP dönüşümünün referans aracı cwebp'tir. Ubuntu/Debian sunucuda kurulumu:

sudo apt update && sudo apt install -y webp
cwebp -version

AlmaLinux/Rocky tarafında:

sudo dnf install -y libwebp-tools

Tek dosya dönüşümü:

#Fotoğraf için kayıplı, kalite 80
cwebp -q 80 urun.jpg -o urun.webp

#Saydam PNG için kayıpsız, alfa kanalını koru
cwebp -lossless -alpha_q 100 logo.png -o logo.webp

#Metin içeren ekran görüntüsü: keskinliği koruyan ön işlem
cwebp -q 90 -sharp_yuv ekran.png -o ekran.webp

-q değeri için pratik aralık 75-85'tir. 90 üstünde kazanç hızla azalır, 70 altında fotoğraflarda blok izleri görünmeye başlar. Ürün fotoğrafı satan bir sitede 82, blog görselinde 78 iyi bir denge kurar.

Bir dizindeki tüm görselleri özgün klasör yapısını bozmadan dönüştürmek için:

#!/bin/bash
#tum-gorselleri-webp-yap.sh — orijinalleri SİLMEZ, yanına .webp üretir
HEDEF="${1:-$HOME/public_html/wp-content/uploads}"
find "$HEDEF" -type f \( -iname '*.jpg' -o -iname '*.jpeg' \) -print0 |
while IFS= read -r -d '' dosya; do
  cikti="${dosya%.*}.webp"
  [ -f "$cikti" ] && continue
  cwebp -quiet -q 80 "$dosya" -o "$cikti"
done
find "$HEDEF" -type f -iname '*.png' -print0 |
while IFS= read -r -d '' dosya; do
  cikti="${dosya%.*}.webp"
  [ -f "$cikti" ] && continue
  cwebp -quiet -lossless "$dosya" -o "$cikti"
done
echo "Dönüşüm bitti."

Betiği çalıştırmadan önce yedek alın. Orijinalleri silmemesi bilinçlidir: sunucu tarafı otomatik sunum kurulumu (aşağıda) eski dosyaların yerinde durmasına dayanır.

Sunucuya erişiminiz yoksa aynı işi yerel makinenizde yapıp dosyaları FTP ile yükleyebilirsiniz. Bu durumda klasör yapısını birebir korumaya dikkat edin: .webp dosyası, karşılığı olan .jpg ile aynı dizinde olmak zorundadır, aksi hâlde aşağıdaki sunucu kuralı dosyayı bulamaz.

Doğru Boyutta Sunmak: srcset ve picture#

Format değiştirmenin tek başına yetmediği yer burasıdır. Telefon ekranında 390 piksel genişliğinde görünen bir görsel için 1920 piksellik dosya indiriliyorsa, WebP kazancınızın çoğunu zaten kaybetmişsiniz demektir.

srcset ile tarayıcıya aynı görselin farklı genişliklerini sunar, seçimi ona bırakırsınız:

<img
  src="/gorseller/urun-800.webp"
  srcset="/gorseller/urun-400.webp 400w,
          /gorseller/urun-800.webp 800w,
          /gorseller/urun-1600.webp 1600w"
  sizes="(max-width: 768px) 100vw, 800px"
  width="800" height="600"
  alt="Kablosuz kulaklık ürün görseli"
  loading="lazy" decoding="async">

Üç ayrıntı kritik:

• sizes doğru yazılmalı. Tarayıcı, CSS'i indirmeden önce görsel seçimini yapar; gerçek görüntüleme genişliğini ona siz söylersiniz. Yanlış sizes, en büyük dosyanın indirilmesine yol açar.
• width ve height mutlaka olmalı. Bunlar olmadan tarayıcı yer ayıramaz ve görsel yüklendiğinde sayfa zıplar; bu doğrudan düzen kayması üretir. Konunun ayrıntısı için cls düzen kayması nasıl düzeltilir yazısına bakın.
• loading="lazy" her görselde olmamalı. Ekranın üst kısmındaki büyük görsele lazy vermek en büyük içerikli boyamayı geciktirir; bu tuzağın ayrıntısı lcp nasıl iyileştirilir yazısında anlatılıyor. İlk ekranda görünen kahraman görselde loading="eager" kullanın, gerisine lazy verin.

Eski tarayıcı desteği gerekiyorsa <picture> etiketiyle yedek format sunulur:

<picture>
  <source srcset="/gorseller/urun.avif" type="image/avif">
  <source srcset="/gorseller/urun.webp" type="image/webp">
  <img src="/gorseller/urun.jpg" width="800" height="600" alt="Kablosuz kulaklık">
</picture>

Tarayıcı listeyi yukarıdan aşağı okur, desteklediği ilk formatı alır ve diğerlerini indirmez. Sıralamayı AVIF → WebP → JPEG olarak tutmak doğru davranıştır.

Sunucu Tarafında Otomatik WebP Sunma#

<picture> etiketini binlerce eski yazıya elle eklemek gerçekçi değildir. Alternatif, HTML'e hiç dokunmadan sunucunun kararı vermesidir: tarayıcı Accept başlığında image/webp diyorsa ve dosyanın .webp sürümü diskte varsa, sunucu .jpg isteğine .webp içeriğini döner.

Apache (paylaşımlı hosting) için public_html/.htaccess içine:

<IfModule mod_rewrite.c>
  RewriteEngine On

  # Tarayıcı WebP kabul ediyor mu
  RewriteCond %{HTTP_ACCEPT} image/webp
  # İstenen dosyanın .webp karşılığı diskte var mı
  RewriteCond %{DOCUMENT_ROOT}/$1.webp -f
  # Varsa onu sun (adres çubuğu değişmez)
  RewriteRule ^(.+)\.(jpe?g|png)$ /$1.webp [T=image/webp,E=WEBP_SUNULDU:1,L]
</IfModule>

<IfModule mod_headers.c>
  # Ara önbelleklerin yanlış sürümü saklamaması için
  Header append Vary Accept env=WEBP_SUNULDU
</IfModule>

AddType image/webp .webp

nginx kullanan bir VDS'te aynı davranış map ile kurulur:

map $http_accept $webp_uzanti {
    default        "";
    "~*image/webp" ".webp";
}

server {
    # ...
    location ~* ^(?<govde>.+)\.(jpe?g|png)$ {
        add_header Vary Accept;
        try_files $govde$webp_uzanti $uri =404;
        expires 1y;
        add_header Cache-Control "public, immutable";
    }
}

Vary: Accept başlığı ihmal edilmemesi gereken kısımdır. Bu başlık olmadan araya giren bir CDN veya önbellek katmanı, WebP destekleyen bir ziyaretçiye ürettiği yanıtı desteklemeyen ziyaretçiye de verebilir; sonuç bozuk görsellerdir. Aynı şekilde bu yöntemde adres çubuğunda ve HTML'de URL .jpg olarak kalır — yani eski bağlantılar, sosyal medya paylaşımları ve arama motoru indeksi bozulmaz. Zaten bu yöntemin en büyük avantajı budur.

Sıkıştırma katmanıyla karıştırmayın: WebP dosyaları zaten sıkıştırılmıştır, gzip veya brotli onlara ek kazanç sağlamaz — hatta boşuna CPU harcar. Sunucunuzun sıkıştırma yapılandırmasında MIME tür listesini kontrol edin ve image/webp ile diğer görsel türlerini o listeden çıkarın; sıkıştırma yalnızca HTML, CSS, JS ve JSON gibi metin türlerine uygulanmalıdır.

WordPress'te WebP ve Eski URL'lerin Durumu#

WordPress, medya kütüphanesine WebP yüklemeyi ve WebP dosyalarından küçük boyutlar üretmeyi destekler. Yani yeni yüklenen görseller doğrudan WebP olabilir. Sorun eski arşivdedir.

Üç strateji var, her birinin bedeli farklı:

1. Sunucu tarafı otomatik sunum (önerilen). Yukarıdaki .htaccess kuralını kurup toplu dönüşüm betiğini wp-content/uploads üzerinde çalıştırırsınız. Veritabanına dokunulmaz, hiçbir URL değişmez, eklenti bağımlılığı olmaz. Geri almak istediğinizde .htaccess'ten üç satır silmeniz yeterlidir.

2. Eklenti ile dönüşüm. Görsel optimizasyon eklentileri hem dönüşümü hem sunumu üstlenir; genellikle <picture> etiketi üreterek çalışır. Kurulum kolaydır ama her sayfa üretiminde ek iş yapar ve eklentiyi kaldırdığınızda sunum durur. Genel eklenti ve medya yönetimi tarafı için wordpress görsel optimizasyonu yazısında ayrıntılı karşılaştırma var.

3. Veritabanında URL değiştirme (dikkat). wp_posts tablosundaki .jpg referanslarını .webp ile değiştirmek. En kırılgan yöntem budur ve şu risklerle gelir:

-- ÖNCE YEDEK ALIN. Bu sorgu geri alınamaz.
-- Yalnızca .webp karşılığı gerçekten üretilmiş dosyalar için çalıştırın.
UPDATE wp_posts
SET post_content = REPLACE(post_content, '.jpg', '.webp')
WHERE post_content LIKE '%wp-content/uploads%';

Bu sorgunun neden tehlikeli olduğunu görmek zor değil: .jpg geçen her metni, dosya adı olmasa bile değiştirir; serileştirilmiş verilerde (wp_postmeta içindeki _wp_attachment_metadata gibi) uzunluk bilgisini bozar ve alanın tamamını okunamaz hâle getirir. Serileştirilmiş veriyle uğraşmanız gerekiyorsa wp search-replace kullanın:

wp search-replace '.jpg' '.webp' --dry-run --precise --recurse-objects

--dry-run ile önce kaç satırın etkileneceğini görün; --precise serileştirilmiş veriyi doğru uzunlukla yeniden yazar, --recurse-objects ise iç içe geçmiş dizileri de dolaşır. Bu üç bayrak olmadan komutu çalıştırmayın.

Toplu Dönüşüm Sonrası Site Bozulmasını Önleme#

Dönüşüm sonrası en sık karşılaşılan iki arıza vardır ve ikisi de önlenebilir.

Arıza 1: Görseller kırık ikon olarak görünüyor. Sebebi neredeyse her zaman aynıdır — orijinal dosyalar silinmiş ama HTML hâlâ .jpg istiyor, sunucu tarafı kural ise ya yok ya çalışmıyor. Kontrol:

curl -sI -H 'Accept: image/webp,*/*' https://ornek.com/wp-content/uploads/2026/05/urun.jpg \
  | grep -Ei 'HTTP/|content-type|vary'

Beklenen çıktı content-type: image/webp olmalıdır. image/jpeg görüyorsanız kural devreye girmiyor; 404 görüyorsanız orijinal dosyayı silmişsiniz demektir. Genel olarak taşıma ve toplu değişiklik sonrası bozulan görünümün teşhis sırası taşıma sonrası site bozuk görünüyor yazısında adım adım verilmiştir.

Arıza 2: Bazı görseller açılıyor bazıları açılmıyor. Genellikle dönüşüm betiği çalışırken disk dolmuştur veya bazı dosyalarda izin sorunu vardır. Eksikleri bulmak için:

#.webp karşılığı üretilmemiş jpg dosyalarını listele
cd ~/public_html/wp-content/uploads
find . -type f -iname '*.jpg' | while read f; do
  [ -f "${f%.*}.webp" ] || echo "EKSİK: $f"
done

Bir de üretilen dosyanın gerçekten küçüldüğünü doğrulayın. Zaten çok sıkıştırılmış bir JPEG'i WebP'ye çevirdiğinizde bazen dosya büyür. Bunu yakalamak için:

find . -iname '*.webp' | while read w; do
  j="${w%.*}.jpg"; [ -f "$j" ] || continue
  bw=$(stat -c%s "$w"); bj=$(stat -c%s "$j")
  [ "$bw" -ge "$bj" ] && echo "BÜYÜMÜŞ: $w ($bw >= $bj)"
done

Büyümüş dosyaların .webp sürümünü silin; sunucu kuralı otomatik olarak orijinali sunmaya devam eder.

WebP mi AVIF mi#

AVIF, WebP'den daha yüksek sıkıştırma oranı sunar; özellikle düşük kalite ayarlarında fark belirgindir. Ancak seçim sadece dosya boyutuna bakarak yapılmaz.

Pratik öneri: WebP'yi temel, AVIF'i üst katman yapın. <picture> etiketiyle önce AVIF, sonra WebP, en son JPEG sırasını kurarsanız destekleyen tarayıcı en küçüğünü alır, desteklemeyen sorunsuz geriye düşer. Sunucu tarafı otomatik sunum kullanıyorsanız AVIF eklemek Accept başlığına bir kontrol daha koymak demektir; ama binlerce görseli AVIF'e çevirmenin CPU maliyetini paylaşımlı hostingde ödemek zordur. Toplu AVIF üretimi genelde kendi sunucunuzda, gece çalışan bir zamanlanmış görevle yapılır.

Dönüşüm Sonrası Doğrulama#

Değişikliğin işe yaradığını hissiyatla değil, ölçerek doğrulayın.

1. Ham boyut karşılaştırması. Dönüşüm öncesi ve sonrası sayfa ağırlığını tarayıcı ağ panelinden alın. Filtreyi "Img" yapıp toplam transferi not edin.
2. Sunulan formatı doğrulayın. Ağ panelinde bir görsele tıklayıp yanıt başlıklarında content-type: image/webp olduğunu görün. Bazı önbellek katmanları eski yanıtı saklıyor olabilir; sert yenileme yapın.
3. Farklı Accept başlığıyla test edin. WebP desteklemeyen bir istemci taklidi:

curl -sI -H 'Accept: image/jpeg,*/*' https://ornek.com/gorsel.jpg | grep -i content-type
#Beklenen: image/jpeg

4. Görsel kalitesini gözle kontrol edin. Özellikle metin içeren görsellerde ve düz zeminli grafiklerde -q 80 bazen bulanıklık üretir; bu tür dosyaları kayıpsız moda alın.
5. PageSpeed raporunu tekrar alın. "Yeni nesil formatlarda sunun" uyarısının kaybolduğunu, "Uygun boyutta görseller" uyarısının ise varsa hâlâ durduğunu göreceksiniz — ikincisi format değil ölçü sorunudur ve srcset ile çözülür.

Ek alan adları veya park edilmiş alan adları üzerinden servis edilen görselleriniz varsa, kuralların o kök dizinlerde de geçerli olduğundan emin olun; ek alan adı yapısının nasıl kurulduğu addon ve parked domain cPanel yazısında anlatılıyor.

Sıkça Sorulan Sorular#

WebP dönüşümü görsel kalitesini bozar mı#

Doğru kalite ayarıyla gözle fark edilir bir kayıp olmaz. Fotoğraflarda -q 80 civarı ayar, aynı görünen ama belirgin biçimde küçük dosya üretir; kayıp ancak yan yana büyütülmüş karşılaştırmada seçilir. Saydam logo, ikon ve metin içeren ekran görüntülerinde ise kayıplı mod kullanmayın, -lossless seçeneğiyle dönüştürün — orada bile PNG'ye göre kazanç sağlarsınız. Kaliteyi 90'ın üstüne çıkarmak kazancı hızla azaltır, 70'in altına inmek fotoğraflarda blok izleri üretir.

Orijinal JPEG dosyalarını silmeli miyim#

Sunucu tarafı otomatik sunum kullanıyorsanız kesinlikle silmeyin. O yöntemde HTML hâlâ .jpg ister ve sunucu, tarayıcı WebP desteklemiyorsa orijinali sunar; dosyayı silerseniz o ziyaretçiler kırık görsel görür. Ayrıca sosyal medya paylaşım önizlemeleri ve bazı botlar WebP kabul etmeyen Accept başlıklarıyla gelir. Disk alanı sıkıntısı yaşamıyorsanız her iki sürümü de tutmak en güvenli düzendir; sıkıntı varsa önce büyük ölçülü ama kullanılmayan ara boyutları temizleyin.

WebP dönüşümü SEO'yu olumsuz etkiler mi#

Doğru kurulduğunda etkilemez, aksine sayfa hızı iyileştiği için olumlu katkı yapar. Kritik nokta URL'leri değiştirmemektir: sunucu tarafı sunum yönteminde adres .jpg olarak kalır, dolayısıyla görsel aramada birikmiş sinyaller ve dış bağlantılar bozulmaz. URL'leri toplu olarak .webp yapmayı seçerseniz eski adreslerden yenilerine kalıcı yönlendirme kurmanız gerekir, aksi hâlde görsel arama trafiği kaybolur. alt metinlerini ve dosya adlarını dönüşüm sırasında koruyun.

PageSpeed hâlâ yeni nesil format uyarısı veriyor ne yapmalı#

Uyarı devam ediyorsa büyük olasılıkla sunucu kuralı devreye girmiyordur. Doğrulamak için curl -sI -H 'Accept: image/webp,*/*' ile bir görsel isteyin ve dönen content-type başlığına bakın; image/jpeg görüyorsanız .htaccess kuralı ya yanlış dizinde ya mod_rewrite kapalı ya da WordPress bloğunun altında kaldığı için hiç çalışmıyordur. İkinci ihtimal, uyarının aslında sizin görselleriniz için değil üçüncü taraf betiklerin yüklediği görseller için verilmesidir; rapordaki dosya yollarını tek tek okuyun. Üçüncü ihtimal ise önbellek: hem sunucu hem tarayıcı önbelleğini temizleyip raporu tekrar alın.

Aynı görselin farklı boyutlarını üretmek zorunda mıyım#

Zorunda değilsiniz ama kazancınızın önemli bir kısmını orada bırakırsınız. Telefonda 390 piksel genişliğinde görünen bir alana 1600 piksellik dosya indirmek, formatın sağladığı avantajı büyük ölçüde silen bir israftır. WordPress zaten yükleme sırasında birkaç ara boyut üretir ve srcset niteliğini otomatik ekler; elle yazdığınız statik sayfalarda bu işi kendiniz yapmanız gerekir. En azından bir mobil (400w) ve bir masaüstü (800-1200w) sürüm üretin.

Animasyonlu GIF dosyalarını WebP'ye çevirmeli miyim#

Kısa döngüsel animasyonlar için evet, uzun olanlar için hayır. WebP animasyon destekler ve tipik bir GIF'e göre çok daha küçük dosya üretir, üstelik renk paleti sınırlaması yoktur. Ancak birkaç saniyeyi aşan animasyonlarda doğru çözüm görsel formatı değil, sessiz ve döngüye alınmış bir video dosyasıdır; video kodekleri bu iş için tasarlanmıştır ve aradaki fark katlarca olur. Karar ölçütünüz süre ve dosya boyutu olsun, format inadı olmasın.

Sunucumda cwebp kurulu değil ne yapabilirim#

Paylaşımlı hostingde SSH erişiminiz varsa çoğu zaman cwebp zaten kuruludur, which cwebp ile kontrol edin. Kurulu değilse ve paket kuramıyorsanız iki yolunuz var: dönüşümü kendi bilgisayarınızda yapıp dosyaları yüklemek, ya da PHP tarafında GD veya ImageMagick kütüphanesini kullanmak. PHP'nin GD eklentisi genellikle WebP desteğiyle derlenmiş olur; php -r 'var_dump(function_exists("imagewebp"));' komutu true dönüyorsa sunucuda dönüşüm yapabilirsiniz. Kendi sunucunuz varsa paket yöneticisiyle kurmak birkaç saniyelik iştir.

WebP dosyaları için önbellek ayarı nasıl olmalı#

Görseller içerik değişmediği sürece uzun süreli önbelleklenmelidir; bir yıllık Cache-Control: public, immutable uygun bir varsayılandır. Ancak sunucu tarafı otomatik sunum kullanıyorsanız yanıta mutlaka Vary: Accept başlığı ekleyin, aksi hâlde araya giren bir önbellek katmanı WebP yanıtını desteklemeyen bir istemciye verebilir. Görseli güncellediğinizde dosya adını değiştirmek (örneğin sonuna sürüm eki koymak) en temiz yöntemdir; aynı adla üzerine yazmak ziyaretçilerin eski sürümü görmesine yol açar.

Kapanış#

WebP dönüşümü, sayfa ağırlığını düşürmenin en yüksek getirili tek adımıdır ama tek adım değildir. Zincirin tamamı şudur: envanteri çıkarın, 200 KB üstü dosyaları dönüştürün, orijinalleri silmeyin, sunucuya Accept başlığına bakan bir kural kurun, Vary: Accept eklemeyi unutmayın, srcset ile doğru ölçüyü sunun, ekranın üstündeki büyük görsele lazy load vermeyin ve sonucu curl ile ölçerek doğrulayın. Bu sırayla yapıldığında ne eski URL'ler bozulur, ne arama motoru sinyalleri kaybolur, ne de WebP desteklemeyen ziyaretçiler kırık görsel görür. AVIF'i ise bunun üstüne, <picture> etiketiyle isteğe bağlı bir katman olarak ekleyin.

Toplu dönüşüm, .htaccess kuralları ve srcset düzenlemesiyle tek başınıza uğraşmak istemiyorsanız bu iş devredilebilir bir iştir. Clou.TR'nin WordPress hosting paketleri görsel sunumu ve önbellek katmanını hazır yapılandırmayla verir; mevcut sitenizin performans denetimi ve düzenli bakımı için WordPress bakım hizmeti dönüşüm sonrası kontrolleri de üstlenir. Görsel yoğun bir katalog işletiyor ve dönüşümü kendi zamanlanmış görevlerinizle yönetmek istiyorsanız VDS sunucu paketleriyle cwebp ve avifenc araçlarını istediğiniz gibi kurabilir, tüm sıkıştırma politikasını kendiniz belirleyebilirsiniz.