Rehber 09 Ekim 2026 · 7 dakika okuma

Sunucuda otomatik Image Optimization nasıl yapılır? (Net rehber)

Sunucuda otomatik image optimization için doğru pipeline: görsel dönüştürme, kalite ayarı, cache ve düşen TTFB/TTFB etkisi net adımlarla.

Görseller, web sitelerinde bant genişimi ve yükleme süresinin en büyük kalemlerinden biridir. Sunucuda otomatik image optimization (dönüştürme/kompresyon) kurduğunuzda, kullanıcı tarafına “bozuk boyutlu görselleri” bırakmadan trafiği düşürürsünüz. Bu rehberde; hangi formatları hedefleyeceğinizi, kalite/ölçü parametrelerini, otomasyon akışını ve pratik kontrol noktalarını net şekilde öğreneceksiniz.

Image optimization için önce hedefi netleştirin

Otomatik dönüşüm kurmadan önce “neye göre optimize edeceğiz?” sorusunun cevabı gerekir. Aksi halde gereksiz kalite kaybı veya CPU yükü gibi sorunlar oluşur.

Hangi formatlar hedeflenmeli?

Kural basit: - Chrome/Edge/Safari modern tarayıcılar için AVIF ve WebP kullanın. - Geriye dönük tarayıcılar için JPEG/PNG kalsın. - İmza (logo/şeffaf arka plan) gibi durumlarda PNG korunsun; ama PNG yerine şeffaflık gerekmiyorsa WebP/AVIF tercih edin.

Net hedef eşleşmesi: - Fotoğraf (jpg): JPEG + WebP + AVIF - Şeffaf grafik (png): PNG + WebP/AVIF (şeffaflık varsa) - SVG: Genelde raster dönüşüm şart değildir; ama boyut büyüyorsa SVGO ile optimizasyon yapılır.

Kalite ayarı: “tek sayı” değil, içerik türü

Aşağıdaki değerler otomasyon için başlangıçta güvenilir aralıktır: - JPEG: kalite 75-85 (genelde 80) - WebP: kalite 70-90 (genelde 80) - AVIF: kalite 35-60 (genelde 45-50). AVIF aynı kaliteyi daha küçük boyutta verebilir.

Aşırı düşük kalite “post” aşırı banting üretir; bu yüzden otomasyonu devreye almadan önce sitenizden 20-50 örnek görsel ile test yapın.

Otomatik image optimization mimarisi: dönüşüm nerede yapılır?

Sunucuda otomatik optimize etmenin iki ana yaklaşımı vardır. Kararı trafiğin dalga yapısına ve CPU bütçenize göre verin.

Yaklaşım A: Yükleme anında (upload-time) dönüştürme

Görsel, CMS’e/medya kütüphanesine girer girmez dönüştürülür. - Artı: İlk erişimde kullanıcı beklemez. - Eksi: Upload anında gecikme ve CPU pikleri oluşur.

WordPress/Panel senaryolarında genellikle en kontrollü yaklaşımdır.

Yaklaşım B: İlk istek anında (request-time) dönüştürme

Tarayıcı bir görsel istediğinde sunucu “yoksa üret” yaklaşımıyla üretir. - Artı: Dönüştürme sadece gerçekten kullanılan dosyalara yapılır. - Eksi: İlk istek gecikmesi olur; aynı anda çok istek gelirse CPU yükü patlayabilir.

Request-time kullanacaksanız “tek sefer üretme” kilidi (mutex) ve sık üretimi engelleyen cache gerekir.

Net öneri

  • Trafik kararlılığı yüksek (kurumsal site, içerik sık girmeyen): upload-time
  • Görsel sayısı çok, tarama/erişim dalgalı: request-time + sağlam cache

Auto pipeline için pratik araç seçimi

Sunucuda otomasyon kurmak için yaygın ve net bir çekirdek araç seti şudur: - ImageMagick (convert, kalite/format) - libvips / vips (sıklıkla daha verimli) - cwebp (WebP) - avifenc (AVIF)

Ek olarak: - Dosya iş akışı için queue: systemd timers, cron, iş kuyruğu (varsa) - Cache ve isimlendirme: içerik adına hash’li çıktı dosyaları - Servis tarafı: Nginx/Apache ile doğru header yönetimi

Aşağıdaki bölümlerde “format hedefle + kalite ayarla + farklı boyut üret + cachele” mantığını kuracağız.

Önerilen sunucu otomasyon adımları (upload-time)

Bu bölümde, statik medya akışına benzer bir senaryoyu temel alıyoruz: görsel yüklendiğinde otomatik dönüştürme, çıktıların sürümlenmesi ve güvenli dosya yolu.

1) Dönüştürme kurulumunu doğrulayın

Sunucunuzda komutların çalıştığını test edin. - ImageMagick: magick -version - WebP: cwebp -version - AVIF: avifenc -version

Eksik araç varsa otomasyon akışı yarıda kalır.

2) Dosya isimlendirmesini standartlaştırın

Aynı görselin birden fazla sürümü olacak: - orjinal.jpg - orjinal_webp_q80.jpg (sadece isim örneği) - orjinal_avif_q45.avif - farklı genişlikler: orjinal_w800.webp, orjinal_w1200.webp

Net kural: “Hangi parametrelerle üretildiği” isme veya metadata’ya yansısın. Yoksa aynı dosyanın farklı kalite sürümleri karışır.

3) “Boyut varyantı” üretimini ekleyin

Sadece tek boyut üretmek çoğu cihaz için verimsizdir. Örnek varyant seti: - 320px (mobil küçük ekran) - 768px (tablet) - 1024px (dikey/orta) - 1600px (masaüstü)

İpucu: Maksimum genişliği orijinalden büyük üretmeyin. Aksi halde boyut artar.

4) CPU piklerini kontrol etmek için kuyruklayın

Özellikle tek seferde çok görsel yüklendiğinde CPU yükü yükselir. - Bir kerede işleyen worker sayısını sınırlayın. - İşleri batch yapın.

Basit kontrol: saniyede kaç görsel dönüşüyor? Bu sayıyı izleyin.

5) Çıktıları cache stratejisiyle servis edin

Dönüştürülmüş görselleri statik dosya olarak servis edin. Önerilen header hedefleri: - Cache-Control: sürümlenmiş dosyalarda uzun TTL (örn. 30-365 gün) - Güncellenen içeriklerde dosya adını değiştirin (hash/versiyon)

Net hedef: “Aynı dosya tekrar üretmesin, tarayıcı doğrudan cache’ten alsın.”

Request-time otomasyon (ilk istek anında dönüştürme) için net şartlar

Request-time yaklaşımında en kritik nokta; “aynı dosya için eşzamanlı üretim” ve “üretim kilidi”dir.

Tek sefer üretme (lock) zorunlu

Aksi halde 50 kullanıcı aynı anda görsel ister ve 50 kez dönüştürme başlar. - Üretim başlangıcında dosya bazlı kilit - Dönüşüm bitince atomik rename - Başarı/başarısız sonucu logla

Yanlış kalite/format döngüsünü engelleyin

  • Aynı parametrelerle tekrar tekrar dönüştürme yapmayın.
  • Hedef format/yeni sürüm kontrolü: “varsa üretme”.

Net test protokolü

1) Aynı görseli 20 kez paralel isteyin. 2) CPU kullanımı ve dönüşüm sayısını kontrol edin. 3) Loglarda tek üretim görünmüyorsa lock yoktur.

Kaliteyi ve tasarrufu ölçmek için somut kontrol listesi

Otomasyon çalışıyor gibi görünse bile kalite kaybı veya beklenmeyen boyut artışı olabilir.

1) Boyut oranlarını kıyaslayın

Orijinal görsel ile AVIF/WebP varyantlarını karşılaştırın. Örnek hedef (genelleme): - Fotoğraflarda WebP genelde %25-60 daha küçük olur - AVIF genelde WebP’ye göre ek %10-30 daha küçülür

Bu aralıklar görsel türüne göre değişir; hedefi mutlak değer olarak değil, kendi örnek setinizle belirleyin.

2) PSNR/SSIM şart değil; görsel örnek testi şart

En az 30 örnek seçin: - İnsan yüzleri (portre) - Düz renk arka planlı görseller - Yazı barındıran görseller - Şeffaf PNG’ler

3) TTFB etkisini ölçün

Request-time kullanıyorsanız ilk istek TTFB artabilir. Yüklemeye değil sunucuya ait ölçüm yapın: - İlk istek sonrası cache oluştuğunda TTFB’nin düşüp düşmediğini izleyin.

Nginx/Apache tarafında doğru servis: optimizasyonun görünmez parçası

Dönüştürme yapmanız tek başına yetmez. Tarayıcı doğru dosyayı almalı ve cache doğru çalışmalı.

Variant seçimi nasıl yapılmalı?

Net yaklaşım: - Tarayıcı Accept başlığını kullanarak (WebP/AVIF var mı?) doğru varyantı gönderin. - Bunu uygulama seviyesinde yapmak yerine sunucu seviyesinde yapabiliyorsanız daha stabildir.

Pratikte bu işlem için: - Nginx modülleri / map kuralları (kullanılan altyapıya göre) - Ya da uygulama tarafı (CDN/uygulama) varyant seçimi

Cache header doğruluğu

  • Sürümlenmeyen dosya adı (ör. image.jpg) ile uzun TTL verirseniz güncelleme gecikir.
  • Sürümlenmiş dosya adı (hash’li) ile uzun TTL verin.

Karar tablosu: Upload-time mi Request-time mı?

Aşağıdaki tablo, hangi senaryoda hangi yöntemin daha net sonuç vereceğini özetler.

Kriter Upload-time dönüşüm Request-time dönüşüm
İlk ziyaret gecikmesi Düşük (hazır olur) Yüksek olabilir (ilk istek)
CPU yükü Upload anında pik Üstünden gelen trafiğe göre yayılır/pikleşir
Cache gereksinimi Orta (dosya bazlı statik) Yüksek (lock + varyant kontrol)
Uygulama entegrasyonu CMS/panel ile uyum ister Daha çok sunucu/uygulama mantığı ister
En net kullanım İçerik düzenli giriyorsa Görsel erişimi dalgalıysa

Net uygulama örneği mantığı (kod değil, akış)

Otomasyon için izlemeniz gereken adımları sırayla yazalım: 1) Yeni görsel yüklenince olay yakala (hook) veya dosya giriş klasörünü izle. 2) Orijinal dosya türünü tespit et (jpg/png). 3) Hedef genişlik varyantlarını hesapla (ör. 320/768/1024/1600) ve orijinalden büyük üretme. 4) Hedef formatları üret: WebP ve AVIF (şeffaflık varsa PNG/şeffaf WebP). 5) Dosya adını versiyonla (hash/kalite/format + genişlik). 6) Sonuçları çıktı klasörüne atomik taşı. 7) Son olarak Nginx/Apache tarafında doğru cache header ve varyant servisini sağla. 8) Loglardan ölç: dönüşüm süresi, hata oranı, ortalama dosya boyutu azaltımı.

Operasyon: izleme ve hata yönetimi

Otomasyon “çalışıyor” kabul edilmez; şu metrikler doğrulanır: - Dönüşüm başarı oranı (örn. %99+ hedef) - Ortalama dönüşüm süresi (ms/saniye) - Aynı görsel için tekrar üretim var mı? (lock sorunu) - Ortalama dosya boyutu düşüşü (WebP/AVIF oranı) - Hata logları (bozuk dosya, eksik encoder, yetki problemi)

Net öneri: Her dönüşüm işinde şu bilgiler loglansın: - kaynak dosya yolu - hedef formatler - kalite/boyut parametreleri - üretim süresi - çıktı boyutu - hata mesajı

Sonuç: 1 haftada net kurulum planı

Image optimization’ı sunucuda otomatik yapmak için en sağlıklı yol, önce hedef format/kaliteyi örnek görsellerle doğrulamak, sonra upload-time dönüşümle başlayıp cache/servis tarafını doğru kurmaktır. Trafik dalgalıysa request-time’a geçmeden önce lock ve cache kurallarını eksiksiz test edin. Bu rehberi uygulamak için ilk adım olarak 30 örnek görsel seçin, WebP ve AVIF varyantlarını hedef parametrelerle üretin ve elde ettiğiniz dosya boyutu düşüşünü ölçün; sonuçlar netse otomasyonu sunucuya bağlayın.

Etiketler: #image optimization #vps #vds #sunucu #webp #avif #nginx #apache

Hosting karşılaştırması yapmaya hazır mısın?

100+ firmanın fiyatlarını tek tıkla karşılaştır, en uygun paketi bul.

Hosting Karşılaştır →

İlgili Yazılar

0 ürün seçildi
NetKıyas AI
Hosting danışmanınız
Merhaba! Ben NetKıyas yapay zekâ asistanı. Hosting, VDS, VPS veya sunucu seçiminde size yardımcı olabilirim. Ne arıyorsunuz?