WebP'ye Dönüştürme Rehberi

Bir sayfanın toplam ağırlığına baktığınızda neredeyse her zaman aynı tabloyla karşılaşırsınız: HTML birkaç kilobayt, CSS ve JavaScript birkaç yüz kilobayt, görseller ise geri kalan her şeyin toplamından fazla. WebP dönüştürme işi tam olarak bu dengesizliği düzeltmek içindir. Google'ın geliştirdiği WebP formatı, aynı görsel kaliteyi JPEG'e göre kabaca %25-35, PNG'ye göre ise şeffaflık gerektiren durumlarda çok daha büyük oranda daha küçük dosyayla verir ve bugün tüm modern tarayıcılar tarafından desteklenir.

Bu rehberde WebP'nin ne zaman kazandırıp ne zaman kazandırmadığını, cwebp ile komut satırından tek tek ve toplu dönüşümün nasıl yapıldığını, kalite değerini nasıl seçeceğinizi, WordPress tarafında hangi yolların işe yaradığını ve dönüştürdüğünüz görselleri tarayıcıya güvenle sunmanın iki farklı yöntemini anlatacağım. Ayrıca "hepsini WebP yapalım" refleksinin neden bazı durumlarda dosyayı büyüttüğünü de göstereceğim.

WebP Ne Kazandırır, Ne Kazandırmaz#

WebP iki kipte çalışır: kayıplı (lossy) ve kayıpsız (lossless). Kayıplı kip JPEG'in rakibidir ve fotoğraflarda kullanılır; kayıpsız kip PNG'nin rakibidir, keskin kenarlı grafikler, logolar ve ekran görüntüleri için uygundur. Ayrıca ikisinde de alfa kanalı, yani şeffaflık desteklenir — bu, PNG kullanmak zorunda kaldığınız şeffaf görselleri kayıplı kipte sıkıştırabilmeniz demektir ve dosya boyutunda en dramatik kazanç genelde buradan gelir.

Beklentiyi doğru kurmak için tipik kazanç aralıkları şöyle:

Son iki satır önemli. SVG bir vektör formatıdır; her boyutta keskindir ve genellikle zaten küçüktür. Onu WebP'ye çevirmek hem kaliteyi sabitler hem de çoğu zaman dosyayı büyütür. Aynı şekilde 2 KB'lık bir PNG ikonu WebP'ye çevirdiğinizde format başlığı yüzünden 2,3 KB'a çıkabilir; kazanç eşiğinin altında kalan dosyaları dönüştürmemek en doğrusudur.

Görsel formatlarının genel resmini görmek ve WebP'nin yerini bir sonraki nesille kıyaslamak isterseniz AVIF nedir, WebP'den farkı ne yazısı bu rehberin doğal devamıdır.

cwebp ile Tek Dosya Dönüştürme#

WebP'nin resmî araç seti libwebp paketiyle gelir ve içindeki cwebp komutu işin merkezindedir. Kurulum dağıtıma göre şöyledir:

# Debian / Ubuntu
sudo apt update && sudo apt install -y webp

# RHEL / AlmaLinux / Rocky
sudo dnf install -y libwebp-tools

# macOS (Homebrew)
brew install webp

# Kurulumu doğrula
cwebp -version

En temel dönüşüm tek satırdır; -q parametresi kalite değerini belirler:

# Kayıplı dönüşüm, kalite 80 (fotoğraflar için iyi bir başlangıç)
cwebp -q 80 urun-fotografi.jpg -o urun-fotografi.webp

# Kayıpsız dönüşüm (logo, ekran görüntüsü, keskin kenarlı grafik)
cwebp -lossless logo.png -o logo.webp

# Şeffaf PNG'yi kayıplı kipte sıkıştır, alfa kanalını kayıpsız tut
cwebp -q 80 -alpha_q 100 seffaf-gorsel.png -o seffaf-gorsel.webp

# Daha uzun süre harcayıp daha iyi sıkıştır (-m 6 = en yavaş/en iyi)
cwebp -q 78 -m 6 kapak.jpg -o kapak.webp

Çıktıda cwebp size dosya boyutunu ve PSNR gibi bir kalite göstergesini yazar. Kazancı doğrudan görmek için ikisini karşılaştırın:

ls -lh urun-fotografi.jpg urun-fotografi.webp
# -rw-r--r-- 1 web web 412K urun-fotografi.jpg
# -rw-r--r-- 1 web web 268K urun-fotografi.webp

Kalite değeri seçerken genel kural şudur: fotoğraflar için 75-85 aralığı gözle fark edilmeyen bir kayıpla en iyi dengeyi verir. 90'ın üzerine çıkmak dosyayı hızla büyütür ve kazancı yok eder; 65'in altına inmek ise düz renk geçişlerinde bantlanma (banding) yaratır. Ürün fotoğraflarında 80, arka plan görsellerinde 70, hero görselinde 82 gibi bağlama göre farklı değerler kullanmak profesyonel yaklaşımdır.

Toplu Dönüşüm: Klasördeki Her Şeyi Çevirmek#

Tek dosya nadiren yeterlidir; genellikle yüzlerce görselli bir uploads klasörünüz vardır. Aşağıdaki betik, bir dizin ağacındaki tüm JPEG ve PNG dosyalarını yanına .webp üretecek şekilde dönüştürür, zaten dönüştürülmüş olanları atlar ve kazanç eşiğinin altında kalanları siler:

#!/usr/bin/env bash
# webp-toplu.sh — verilen dizindeki görselleri WebP'ye dönüştürür
set -euo pipefail

HEDEF="${1:-.}"
KALITE="${2:-80}"

find "$HEDEF" -type f \( -iname '*.jpg' -o -iname '*.jpeg' -o -iname '*.png' \) -print0 |
while IFS= read -r -d '' dosya; do
    cikti="${dosya%.*}.webp"

    # Zaten dönüştürülmüş ve kaynaktan yeniyse atla
    [ -f "$cikti" ] && [ "$cikti" -nt "$dosya" ] && continue

    cwebp -quiet -q "$KALITE" -m 5 "$dosya" -o "$cikti"

    eski=$(stat -c%s "$dosya")
    yeni=$(stat -c%s "$cikti")

    # Kazanç %10'un altındaysa WebP'yi tutmaya değmez
    if [ "$yeni" -gt $(( eski * 90 / 100 )) ]; then
        rm -f "$cikti"
        echo "ATLANDI (kazanç yok): $dosya"
    else
        echo "OK: $dosya  ${eski} -> ${yeni} bayt"
    fi
done

Betiği çalıştırmadan önce mutlaka bir yedek alın; dönüştürme kaynak dosyayı silmez ama yine de üretim dizininde ilk denemeyi bir kopya üzerinde yapmak iyi bir alışkanlıktır. Yedekleme alışkanlığınız yoksa yedekleme hizmetimiz bu tür toplu işlemler öncesinde geri dönüş noktası oluşturmanızı sağlar.

chmod +x webp-toplu.sh
./webp-toplu.sh /var/www/firmaniz.com/uploads 80

ImageMagick kuruluysa aynı işi tek satırda da yapabilirsiniz, ancak ImageMagick arka planda yine libwebp kullanır ve cwebpin ince parametrelerine (örneğin -alpha_q, -m) erişemezsiniz:

# ImageMagick ile hızlı dönüşüm
magick mogrify -format webp -quality 80 -path ./webp ./*.jpg

Dönüştürdüğünüz WebP'yi Tarayıcıya Sunmak#

Dosyaları üretmek işin yarısı; asıl mesele hangi ziyaretçiye hangi formatı göndereceğinizdir. İki yaklaşım var ve ikisinin de yeri farklıdır.

Birinci yöntem: HTML tarafında picture elementi. Tarayıcı listeyi yukarıdan aşağı okur, desteklediği ilk kaynağı alır ve desteklemediğini atlar. Sunucu tarafında hiçbir yapılandırma gerektirmez, önbellek katmanlarıyla sorunsuz çalışır ve neyin gönderildiği tamamen öngörülebilirdir:

<picture>
  <source srcset="/img/urun.webp" type="image/webp">
  <img src="/img/urun.jpg" alt="Ürün fotoğrafı" width="1200" height="800">
</picture>

Buradaki img etiketi hem geri dönüş (fallback) hem de zorunlu bir parçadır; picture tek başına bir şey göstermez. width ve height özniteliklerini yazmayı da ihmal etmeyin, aksi halde görsel yüklenirken sayfa zıplar. Bu davranışın nedenini ve çözümünü CLS düzen kayması nasıl düzeltilir yazısında bulabilirsiniz. Aynı görselin farklı çözünürlüklerini de sunmak istiyorsanız responsive görseller: srcset ve sizes rehberi bir sonraki adımınız olsun.

İkinci yöntem: sunucu tarafında Accept başlığına göre otomatik değiştirme. Tarayıcı her istekte hangi formatları desteklediğini Accept başlığında bildirir. Nginx bu bilgiye bakıp aynı isimli .webp dosyası varsa onu servis edebilir; HTML'inize hiç dokunmanız gerekmez:

# http bloğunda: tarayıcı WebP destekliyor mu
map $http_accept $webp_uzanti {
    default        "";
    "~*image/webp" ".webp";
}

server {
    location ~* ^(/.+)\.(jpe?g|png)$ {
        # Önce aynı isimli .webp dosyasını dene, yoksa orijinali ver
        try_files $1$webp_uzanti $uri =404;

        # Ara önbellekler formatı karıştırmasın
        add_header Vary Accept;
        expires 30d;
    }
}

Bu yöntemde Vary: Accept başlığı kesinlikle atlanmamalıdır. Bu başlık olmadan bir CDN ya da vekil sunucu, WebP destekleyen bir tarayıcıya gönderdiği yanıtı önbelleğe alır ve aynı yanıtı desteklemeyen bir istemciye de verir; sonuç bozuk görüntülenen görsellerdir. Apache kullanıyorsanız aynı mantık .htaccess içinde RewriteCond %{HTTP_ACCEPT} image/webp ile kurulur; genel .htaccess performans yönergelerini htaccess önbellek ve sıkıştırma yazısında toplu halde bulabilirsiniz.

WordPress Tarafında WebP#

WordPress 5.8'den itibaren WebP dosyalarını medya kütüphanesine yükleyebilirsiniz; yani hiçbir eklenti olmadan elle dönüştürüp yükleyerek başlayabilirsiniz. Ancak yüzlerce mevcut görselin dönüştürülmesi ve doğru formatın sunulması için pratikte üç yol vardır.

Birincisi, sunucu tarafı otomatik dönüşümdür: yukarıdaki Nginx map yöntemini kurar, ayrı bir betikle wp-content/uploads altındaki görselleri toplu dönüştürürsünüz. Bu yaklaşımın avantajı eklenti bağımlılığı yaratmaması ve tema güncellemelerinden etkilenmemesidir. Dezavantajı, yeni yüklenen görsellerin dönüştürülmesi için zamanlanmış bir görev (cron) kurmanız gerekmesidir.

İkincisi, önbellekleme eklentinizin görsel optimizasyon modülünü kullanmaktır. LiteSpeed sunucusundaysanız bu iş zaten LiteSpeed Cache'in içinde gelir; kurulum ve yapılandırmasını LiteSpeed Cache WordPress yazısında bulabilirsiniz.

Üçüncüsü, işi tamamen bir görsel CDN'ine devretmektir; bu durumda dönüşüm de sunum da sizin altyapınızın dışında yapılır. Bu modelin nasıl işlediğini resim CDN'i ile otomatik görsel optimizasyonu yazısında ayrıntılandırıyorum.

Hangi yolu seçerseniz seçin, dönüştürme sonrası mutlaka bir hız testi ile önce-sonra karşılaştırması yapın; GTmetrix ile WordPress hız testi yazısındaki okuma yöntemi bu karşılaştırmayı doğru yorumlamanıza yardım eder.

Sık Yapılan Hatalar#

Kaynak dosyayı silmek. WebP'ye dönüştürdükten sonra orijinal JPEG'i silerseniz geri dönüşünüz kalmaz; kalite değerini yanlış seçtiğinizi altı ay sonra fark ettiğinizde elinizde yalnızca sıkıştırılmış dosya olur. Orijinalleri her zaman saklayın, tercihen üretim sunucusunun dışında.

Zaten sıkıştırılmış bir JPEG'i yüksek kaliteyle WebP'ye çevirmek. Kalite 90 ile dönüştürülmüş bir JPEG'i -q 95 ile WebP'ye çevirirseniz, kaynaktaki sıkıştırma artefaktlarını da kodlamış olursunuz ve dosya orijinalden büyük çıkabilir. Mümkünse dönüşümü mümkün olan en yüksek kaliteli kaynaktan yapın.

SVG ve küçük ikonları dönüştürmek. Vektör dosyaları dönüştürmeyin. 5 KB'ın altındaki PNG'lerde kazanç genelde yoktur; toplu betiğinizde bir boyut eşiği kullanın.

Vary: Accept başlığını unutmak. Sunucu tarafı otomatik değiştirme kullanıyorsanız bu başlık olmadan önbellek zehirlenmesi kaçınılmazdır. Belirti tipik olarak "bazı kullanıcılarda görseller bozuk çıkıyor" şeklinde gelir ve tekrar üretmesi zordur.

Yeni yüklenen görselleri dönüştürmeyi unutmak. Bir kerelik toplu dönüşüm yaptınız, üç ay sonra sitedeki yeni görsellerin hiçbiri WebP değil. Dönüşümü ya yükleme akışının parçası yapın ya da günlük bir cron görevine bağlayın.

Dönüşümü doğrulamamak. Görsellerin gerçekten WebP olarak gittiğini tarayıcı geliştirici araçlarının Network sekmesinden kontrol edin; Type sütununda webp görmelisiniz. Komut satırından da doğrulayabilirsiniz:

# Tarayıcı gibi davranıp hangi formatın döndüğünü gör
curl -sI -H "Accept: image/webp,image/*,*/*" https://firmaniz.com/img/urun.jpg \
  | grep -iE "content-type|content-length|vary"

Sıkça Sorulan Sorular#

WebP tüm tarayıcılarda çalışır mı#

Bugün için pratik cevap evet. Chrome, Edge, Firefox, Safari ve mobil tarayıcıların güncel sürümlerinin tamamı WebP'yi destekler; Safari desteği de birkaç yıldır mevcut. Yine de çok eski cihazlardan gelen ziyaretçileriniz olabileceği için picture elementiyle JPEG geri dönüşü bırakmak ya da sunucu tarafında Accept başlığına bakmak en güvenli yaklaşımdır. Bu iki yöntemden biriyle desteklemeyen istemci otomatik olarak orijinal formatı alır.

WebP kalite değerini kaç yapmalıyım#

Fotoğraflar için 75-85 aralığı en iyi dengeyi verir ve 80 iyi bir varsayılandır. 90'ın üzerine çıkmak dosya boyutunu hızla büyütür ve gözle görülür bir kazanç sağlamaz; 65'in altı ise düz renk geçişlerinde bantlanma yaratır. Logo, ekran görüntüsü ve keskin kenarlı grafiklerde ise kalite değeri yerine -lossless kipini kullanmak daha doğru sonuç verir.

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

Kayıplı kipte teknik olarak evet, veri kaybı olur; ancak 80 civarındaki bir kalite değerinde bu kayıp normal ekran boyutlarında gözle ayırt edilemez. Kritik olan nokta, aynı görseli defalarca kayıplı sıkıştırmadan geçirmemektir. Baskı kalitesi, fotoğrafçılık portfolyosu gibi kaybın kabul edilemez olduğu durumlarda -lossless kipini kullanın; dosya büyür ama hiçbir piksel değişmez.

Toplu dönüşüm ne kadar sürer#

Süre görsel sayısına, çözünürlüğüne ve seçtiğiniz sıkıştırma çabasına (-m parametresi) bağlıdır. Kaba bir tahmin olarak orta seviye bir sunucuda 2000 piksel genişliğindeki bir fotoğraf -m 5 ile saniyenin küçük bir bölümünde dönüşür; birkaç bin görsellik bir kütüphane dakikalar sürer. İşlemi üretim trafiğinin düşük olduğu saatlerde çalıştırın ve nice ile önceliğini düşürerek sitenin yanıt süresini etkilemesini önleyin.

Orijinal JPEG dosyalarını silebilir miyim#

Sunucuda tutmanız gerekip gerekmediği kullandığınız sunum yöntemine bağlıdır. picture elementi ya da sunucu tarafı try_files yöntemi kullanıyorsanız orijinaller geri dönüş olarak sunucuda kalmalıdır. Bunun ötesinde, kalite ayarını değiştirmek ya da ileride AVIF gibi başka bir formata geçmek istediğinizde kaynağa ihtiyacınız olur. En sağlıklısı orijinalleri ayrı bir yedek alanında saklamaktır.

WebP mi AVIF mi kullanmalıyım#

İkisini birlikte kullanmak en iyisidir. AVIF genellikle WebP'den daha küçük dosya üretir ama kodlaması belirgin biçimde daha yavaştır ve tarayıcı desteği bir adım geridedir. Pratik yaklaşım picture elementinde önce AVIF, sonra WebP, en sonda JPEG sıralamasını kurmaktır; her tarayıcı desteklediği ilk formatı alır. Yalnızca birini seçecekseniz ve iş gücünüz sınırlıysa WebP daha az sürprizle sonuç verir.

Kapanış#

WebP, görsel ağırlığını düşürmek için elinizdeki en düşük riskli araç: kurulumu tek paket, dönüşümü tek komut, geri dönüşü picture elementiyle bir satır. Aklınızda kalması gereken dört alışkanlık şunlar: fotoğraflarda 75-85 arası kalite kullanın, kazancı %10'un altında kalan dosyaları dönüştürmeyin, orijinalleri asla silmeyin ve sunucu tarafı otomatik değiştirme yapıyorsanız Vary: Accept başlığını mutlaka gönderin. Dönüşümü bir kerelik iş olarak değil, yükleme akışınızın kalıcı bir parçası olarak kurun.

Görsel ağırlığı düşürme işini altyapı tarafından desteklemek isterseniz, LiteSpeed ve sunucu tarafı önbellekleme ile gelen WordPress hosting ve web hosting paketlerimiz dönüştürülmüş görselleri hızlı biçimde servis eder. Toplu dönüşüm betiklerini kendi zamanlanmış görevlerinizle çalıştırmak isterseniz tam root erişimli VDS sunucularımız uygundur; işin tamamını bize bırakmak isterseniz sunucu yönetimi hizmetimiz bu kurulumu sizin yerinize yapar.