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.
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
GDPR ve KVKK için hosting: Sunucu tarafında net önlemler
GDPR ve KVKK uyumu için hostingte veri konumu, şifreleme, log yönetimi, yedekleme, erişim kontrolü ve DPA adımları için net kontrol listesi.
Object cache (APCu, Redis) ne zaman gerekir? Net karar rehberi
APCu ve Redis object cache ne zaman kullanılmalı? WordPress/PHP uygulamalarında ölçülebilir eşiklerle performans planlayın.
İlk Web Siteni Yayınla: Adım Adım Net Yayın Rehberi
İlk web siteni yayınlamak için domain, DNS, hosting, dosya yükleme, HTTPS ve test adımlarını net sırayla öğren. Yayın kontrol listesi burada.
Discord Botu İçin Minimum VDS: Net CPU/RAM/Disk Rehberi (2026)
Discord botu için minimum VDS şartlarını net örneklerle öğrenin: CPU/RAM/IOPS, disk, ağ ve Docker/Node.js ayarlarıyla doğru kapasiteyi belirleyin.
