Sıkıştırma araçlarının en yaygın tanıtım söylemi, “boyut %70 azaldı” gibi doğrulanamayan rakamlardır. Bu yazı hiçbir sektör istatistiğine atıfta bulunmaz; yalnızca gerçek bir test sonucunu ve herkesin kendisinin tekrarlayabileceği eksiksiz bir karşılaştırma yöntemini sunar.
1. Test Nesnesi: Orijinal Değil, Başkalarının Daha Önce Sıkıştırdığı Görseller
Çoğu sıkıştırma testi, kameradan doğrudan çıkan orijinal görselleri kullanır; bu koşullar fazla idealdir. Bu test, gerçek iş senaryosunu hedefleyerek bilinçli şekilde kurgulandı: kullanıcıların görsel yüklemesine izin veren ve yükleme sırasında kendi rutin sıkıştırmasını zaten uygulayan bir web sitesi. Yani test nesnesi, işlenmemiş ham görseller değil; daha önce “bir kez sıkıştırılmış” olan nihai görsellerdir.
Örneklem büyüklüğü: 78 klasörde toplam 4624 görsel (çoğunlukla JPG). Dizin yapısı “her albüm için bir klasör” şeklinde tipik bir arşivleme düzenidir; herhangi bir filtreleme veya temizlik yapılmadı.
Bu dosyaların sunucudaki toplam boyutu: 1,41 GB.
Temel soru şu: Bir sıkıştırma aracıyla işlenmiş bir görsel, başka bir sıkıştırma aracına verildiğinde daha ne kadar yer kazandırabilir? Çoğu kullanıcı, “bir kez sıkıştırıldıysa tekrar sıkıştırmanın da bir anlamı yok” diye düşünür.
2. Kontrol Grubu: zip Olarak Paketlemek Ne Kadar Kazandırır?
ImgZilla’yı çalıştırmadan önce aynı dosyaları olduğu gibi zip olarak paketleyip genel amaçlı sıkıştırma algoritmasının etkisini gözlemledik:
| Boyut | Orijinale Göre | |
|---|---|---|
| Sitenin sıkıştırdığı orijinal dosyalar | 1,41 GB | — |
| zip olarak paketlenmiş | 1,41 GB | -%0,2 |
Neredeyse hiç değişiklik olmadı. Nedeni basit: JPEG zaten sıkıştırılmış bir biçimdir; görüntü verisi entropi kodlamasından geçmiştir ve genel amaçlı algoritmalar (zip, DEFLATE kullanır) zaten sıkıştırılmış veriyi daha fazla sıkıştıramaz. İster orijinal görseller web sitesinden geçmiş olsun ister olmasın, zip burada çaresizdir.
3. ImgZilla ile Yeniden Sıkıştırma Testi
Yukarıdaki dosyaları ImgZilla’ya sürükleyip yerinde sıkıştırdık. 78 klasör ve 4624 görselde dosya adları ve dizin yapısı aynen korundu:
| Boyut | Orijinale Göre | |
|---|---|---|
| Sitenin sıkıştırdığı orijinal dosyalar | 1,41 GB | — |
| zip olarak paketlenmiş | 1,41 GB | -%0,2 |
| ImgZilla ile yeniden sıkıştırılmış | 0,75 GB | -%46,8 |
Sitenin kendi sıkıştırmasına ek olarak ImgZilla yaklaşık 662 MB daha kazandırdı; boyut neredeyse yarıya indi. Tüm klasör yolları, dosya adları ve hiyerarşi öncesiyle birebir aynıdır — doğrulanabilir gerçek veridir, pazarlama söylemi değil.
Bu, önemli bir gerçeği ortaya koyuyor: “Site yüklerken sıkıştırdı” ile “biçime özgü parametrelerle ince ayar yapılmış kodlama sıkıştırması” farklı şeylerdir. Çoğu web sitesi, içeri alırken tek seferlik ve temkinli bir sıkıştırma uygular (genellikle yalnızca kalite parametresini veya boyutu sınırlar); bu, her biçimin kodlama alanını sonuna kadar kullanmaz. ImgZilla her biçim için parametreleri ayrı ayrı ayarlar ve JPEG üzerinde görsel olarak kayıpsız yeniden kodlama yapar — piksel düzeyinde gerçekten değişiklik vardır, ancak parametreler çıplak gözle ayırt edilemeyecek bir aralıkta tutulur. Böylece “zaten sıkıştırılmış” veriden daha fazla alan kazandırır.
Karıştırılabilecek bir kavramı netleştirelim: “Görsel kayıpsız”, “kayıpsız” anlamına gelmez. Gerçek anlamda kayıpsız (piksel birebir değişmez) yalnızca PNG (oxipng) ve SVG için geçerlidir; JPEG, WebP, AVIF, HEIC ve GIF prensipte kayıplı yeniden kodlamadır; yalnızca sıkıştırma parametreleri görsel kayıpsızlık eşiğinin içinde tutulur. ImgZilla’da sıkıştırma öncesini ve sonrasını yan yana karşılaştırabileceğiniz, gerçek boyutuna yakınlaştırıp piksel piksel inceleyebileceğiniz yerleşik bir karşılaştırma penceresi vardır.
4. Ayrıntılı Analiz: Dosya Bazında Sıkıştırma Oranı, Piksel Boyutu ve Görev Süresi
Yukarıdaki %46,8’lik toplam sıkıştırma oranı, 4624 görselin toplu sonucudur. Tek tek dosya düzeyinde incelendiğinde daha fazla ayrıntı ortaya çıkar.
Görsel Başına Sıkıştırma Oranı Eşit Dağılmıyor
Her görselin sıkıştırma oranı (sıkıştırma sonrası bayt / sıkıştırma öncesi bayt) tek tek hesaplandığında %32,3 ile %85,8 arasında değişir:
- En yüksek sıkıştırma oranlı grup: yaklaşık 765 KB, 109 KB’ye indi; oran %85,8. Bu tür görseller genellikle ilk sıkıştırmada yetersizdir ve hâlâ kayda değer bir yeniden kodlama alanı barındırır.
- En düşük sıkıştırma oranlı grup: yaklaşık 572 KB, 387 KB’ye indi; oran %32,3. Bu görseller daha önce sıkı şekilde sıkıştırılmıştır; kazılabilecek alan sınırlıdır.
- 4624 görselin sıkıştırma oranlarının aritmetik ortalaması %46,44’tür. Toplam boyut üzerinden hesaplanan %46,8’e yakındır ama birebir aynı değildir. İlki, dosya bazındaki oranların basit ortalamasıdır; ikincisi “toplam kazanılan bayt ÷ toplam orijinal bayt”tır. Bu fark, yüksek ve düşük oranlı dosyaların toplam boyut üzerindeki ağırlığının simetrik olmadığını; az sayıdaki büyük dosyanın toplamı daha çok etkilediğini gösterir.
Dikkat çekici nokta, tüm görsellerin sıkıştırma oranının pozitif olması ve hiçbirinde “en küçük boyutta, atlandı” durumunun görülmemesidir. Yani “web sitesi tarafından sıkıştırılmış” bu görsellerin her biri, ImgZilla ile gerçek bir boyut kazancı sağlayacak şekilde yeniden sıkıştırılabilmektedir.
Piksel Boyutları: Birebir Aynı
Tüm 4624 görselin piksel boyutlarına bakıldığında en yaygın boyutun 1600×2400 (1756 görsel) ve yatay biçimi 2400×1600 (500 görsel) olduğu görülür. Boyut aralığı en küçük 450×675 (yaklaşık 300 bin piksel) ile en büyük 3000×2000 / 2000×3000 (yaklaşık 6 milyon piksel) arasındadır.
Sıkıştırma öncesi ve sonrası piksel boyutları örneklemle karşılaştırıldığında tamamen aynı, hiçbir değişiklik yok:
| Dosya (örnek) | Orijinal Boyut | Sıkıştırma Sonrası Boyut |
|---|---|---|
| Örnek 1 | 1600×1066 | 1600×1066 |
| Örnek 2 | 2000×3000 | 2000×3000 |
| Örnek 3 | 1416×2128 | 1416×2128 |
Bu, “yerinde sıkıştırma” tanımının gözden kaçabilen diğer yarısıdır: Yalnızca dosya adı ve yolu değil, çözünürlük de sabit kalır. ImgZilla ölçekleme yapmaz, kırpma yapmaz; boyuttaki tüm azalma, piksellerden ödün vermeden tamamen yeniden kodlamadan gelir.
Görev Süresi: 4624 Görsel 51 Dakika 32 Saniyede Tamamlandı, Ortalama 0,669 Saniye
Test ortamı: Mac mini, Apple M1 çip, 8 GB birleşik bellek; görseller 2,5G kablolu ağ ile bağlı NAS’taki mekanik diskte duruyordu.
Görev ilerlemesi, her görselin son yazılma zamanına (ImgZilla’nın sıkıştırmayı bitirip diske yazdığı ana) göre izlendi: İlk yazım 16:06:09, son yazım 16:57:41. Tüm toplu işlem 51 dakika 32 saniye sürdü; ortalama görsel başına 0,669 saniye.
Bu veri, ürünün “seri işleme” tasarımıyla uyumludur — paralel ve karışık sırada yazmak yerine görseller tek tek sırayla sıkıştırılır. Bu, dakikada yaklaşık 90 görsel işlendiği anlamına gelir. Gerçek hız, görsel boyutuna ve makine performansına bağlıdır; burada yalnızca bu gruptaki (ortalama ~305 KB) görsellerin bu ortamdaki gerçek süresi verilmiştir, genel bir kıyaslama değildir.
5. Neden Kopya Oluşturmak Yerine Yerinde Sıkıştırma?
Eğer bu testte “sıkıştırılmış sürümü farklı kaydet” diyen bir araç kullanılsaydı sonuç şu olurdu: Orijinal dosyalar 1,41 GB + sıkıştırılmış dosyalar 0,75 GB; toplamda 2,16 GB yer kaplardı. Bu, tersine daha fazla yer kaybettirir ve sürüyle xxx-min.jpg dosyası üretirdi. Bu dosyaların elle düzenlenmesi, veritabanındaki veya ürün tablosundaki referansların güncellenmesi gerekirdi.
ImgZilla, yerinde üzerine yazma yöntemini kullanır: Sıkıştırma sonucu doğrudan aynı yola yazılır; 78 klasördeki 4624 dosya adı değişmeden kalır. Bu, görsel yollarını veritabanına, CDN’e veya CMS referanslarına kaydetmiş siteler için özellikle önemlidir; sıkıştırmadan sonra hiçbir bağlantıyı güncellemeniz gerekmez. Bunun bedeli, orijinal dosyaları değiştirmesidir. Bu nedenle ImgZilla varsayılan olarak önce orijinal görselleri sistem çöp kutusuna taşır, ardından sıkıştırma sonucunu yazar. Fikrinizi değiştirirseniz çöp kutusunda sağ tıklayıp “Orijinal Konumuna Geri Koy”u seçebilirsiniz.
6. Kazanç Analizi: Gerçek Senaryolardan Aylık Faturalara
Bu Veriler Kimin İşine Yarar?
- Kullanıcı yüklemesine açık görsel içeren siteler / geliştiriciler: Görsel depolama ve CDN trafiği genellikle GB başına faturalanır; boyutun yarıya inmesi faturanın da yarıya inmesi demektir. Üstelik trafik ücreti her erişimde oluşan bir maliyettir; erişim sayısı arttıkça bileşik etki daha da belirginleşir. İçeri alımda olağan sıkıştırma yapılmış olsa bile bu test, “özel ayarlanmış bir sıkıştırma turu daha çalıştırmanın” kayda değer kazanç sağlayabileceğini gösterir.
- Depolama alanı dar sunucular / düşük kapasiteli disk kullanıcıları: Temizlik araçları genellikle önbellekleri ve yinelenen dosyaları siler; ancak aylar sonra alan yeniden dolar. Sıkıştırmayla kazanılan alan ise kullanımdaki dosyaların küçülmesi sayesinde oluşur ve geri tepmez. Bu 78 klasör sıkıştırılarak doğrudan 662 MB kullanılabilir alan kazanıldı; üstelik bu kalıcı bir kazanımdır.
- Verileri sık taşıyan kullanıcılar: Kopyalarken, senkronlarken veya yedeklerken boyut %46,8 azaldığı için aktarım süresi de yaklaşık aynı oranda kısalır. Bir kez sıkıştırın, sonraki her taşımada zaman kazanırsınız.
Aylık Fatura Karşılığı: Bu %46,8 Gerçekte Ne Kadar Değer?
Boyut azalmasının ikna edici olması için faturaya yansıması gerekir. Aşağıda “sıkıştırma dönüşümü artırır” tarzı hiçbir istatistik kullanılmamıştır; yalnızca bu testteki %46,8, ana bulut sağlayıcılarının açık depolama/trafik fiyatlarıyla çarpılmış ve saf aritmetik bir hesaplama yapılmıştır.
Depolama tasarrufu = Kazanılan boyut (GB) × Birim fiyat (yuan veya dolar / GB / ay)
Çıkış trafiği tasarrufu = Kazanılan boyut (GB) × O ayki indirme/erişim sayısı × Birim fiyat (yuan veya dolar / GB)
Boyut yarıya indiğinde her iki fatura kalemi de kabaca yarıya iner. Bu bir tahmin değil, matematiktir.
Depolama Ücreti: Kitaplık Büyüdükçe Kazanç Daha Belirgin
Çin’deki sağlayıcılar:
| Kitaplık boyutu | Kazanılan boyut | Alibaba Cloud OSS Standart ¥0,09/GB/ay |
|---|---|---|
| 10 GB | 4,68 GB | ¥0,42/ay |
| 100 GB | 46,8 GB | ¥4,21/ay |
| 1 TB | 479 GB | ¥43,1/ay |
Yurtdışı sağlayıcılar:
| Kitaplık boyutu | Kazanılan boyut | AWS S3 Standard $0,023/GB/ay |
Google Cloud Storage $0,020/GB/ay (ABD Bölgesel) |
Azure Blob Storage $0,018/GB/ay (Hot, LRS) |
Cloudflare R2 $0,015/GB/ay |
|---|---|---|---|---|---|
| 10 GB | 4,68 GB | $0,11/ay | $0,09/ay | $0,08/ay | $0,07/ay |
| 100 GB | 46,8 GB | $1,08/ay | $0,94/ay | $0,84/ay | $0,70/ay |
| 1 TB | 479 GB | $11,02/ay | $9,58/ay | $8,62/ay | $7,19/ay |
Birkaç büyük yurtdışı sağlayıcının depolama birim fiyatları birbirine çok yakındır (fark %30’un altında). Önemli olan hangisinin daha ucuz olduğu değil, hangisini seçerseniz seçin boyut yarıya inince bu fatura kaleminin de yaklaşık yarıya inmesidir; üstelik her ay yinelenir. Bir kez sıkıştırın, bundan sonraki her ay yeni boyut üzerinden faturalanırsınız. Bu, tek seferlik bir yatırımın uzun vadeli ve sürekli getirisidir.
Trafik Ücreti: Asıl Büyük Kalem, Erişimle Büyür
Trafik ücreti, depolama ücretinden daha çok dikkati hak eder; çünkü boyut × indirme sayısı çarpımıdır — görsele ne kadar sık erişilirse sıkıştırmanın kazancı o kadar artar. Farz edelim ki 100 GB’lık bir görsel kitaplığı o ay CDN üzerinden 500 GB indirme trafiği oluşturdu (yani kitaplığın tamamı yaklaşık 5 kez indirildi):
| CDN / çıkış trafiği fiyatı (ilk kademe) | Sıkıştırma öncesi aylık trafik ücreti | Sıkıştırma sonrası (trafik -%46,8) | Aylık tasarruf | Yıllık tasarruf |
|---|---|---|---|---|
| Alibaba Cloud CDN Çin içi (düşük kademe ¥0,15/GB) | ¥75,0 | ¥39,9 | ¥35,1 | ¥421 |
| AWS CloudFront Asya Pasifik ($0,12/GB) | $60,0 | $31,9 | $28,1 | $337 |
| Google Cloud CDN Kuzey Amerika/Avrupa ($0,08/GB) | $40,0 | $21,3 | $18,7 | $224 |
| Azure Front Door Standard Zone 1 ($0,08/GB) | $40,0 | $21,3 | $18,7 | $224 |
Yukarıdaki değerler her sağlayıcının en düşük kademe fiyatıdır; gerçek kademeli fiyatlar genellikle daha yüksektir (Alibaba Cloud CDN’in Çin içi trafik kademeleri en üstte ¥1,31/GB’ye ulaşabilir). Fatura büyüdükçe sıkıştırmanın sağladığı mutlak tasarruf da o kadar belirgin olur. Ayrıca Azure’daki bu kademe şu anda Front Door Standard sürümüdür; GB başına faturalanan çıkış trafiğine ek olarak aylık yaklaşık $35 temel hizmet ücreti içerir. Bu ücret sıkıştırmayla azaltılamaz ve tablodaki tasarrufa dahil edilmemiştir.
Cloudflare R2 bir istisnadır: çıkış trafiği zaten $0’dır. Depolama alanı R2 ile birlikte kullanılıyorsa, sıkıştırma kazancı neredeyse tamamen depolama ücretine yansır; trafik kalemi baştan faturalanmaz. Bu, “depolama + trafik” şeklindeki çift taraflı faturalandırma mimarisinden (ör. Alibaba Cloud OSS+CDN, AWS S3+CloudFront) farklı bir maliyet yapısıdır; sağlayıcı seçmeden önce kendi faturalama kalemlerinizi netleştirmeniz gerekir.
Yukarıdaki birim fiyatlar, 2026 itibarıyla platformların kamuya açık fiyat listelerinden derlenmiştir. Gerçek fiyatlar bölgeye, hesap indirimlerine ve kademelere göre değişebilir; lütfen resmî sitelerdeki güncel fiyatları esas alın. İndirme/erişim sayıları örnek varsayımlardır; tahmin için kendi faturanızdaki gerçek verileri koyun.
7. Aktarım ve Yükleme Süresinden Tasarruf
Boyut yarıya indiğinde aktarım süresi de yaklaşık aynı oranda kısalır. Bu kural yalnızca bulut faturalarına bağlı değildir; yerel kopyalama ve yedeklemede de, kullanıcı yüklemesinde de geçerlidir.
Yerel Senaryo: USB 3 ve Gigabit Ağ
- USB 3 taşınabilir mekanik disk: Sürekli okuma/yazma hızı genellikle 100–150 MB/s arasındadır; orta değer 120 MB/s alınır.
- USB 3 taşınabilir SSD: Hızlar belirgin şekilde yüksektir, genellikle 400–500 MB/s; 450 MB/s alınır.
- Gigabit kablolu ağ (1000 Mbps): Kuramsal üst sınır 125 MB/s’dir; protokol yükü düşüldüğünde ölçülen sürekli hız yaklaşık 100–110 MB/s’dir; 105 MB/s alınır.
Yukarıdakiler, yaygın ölçüm aralıklarından yola çıkılarak yapılan tahminlerdir. Gerçek hızlar disk ortamına, arayüz kalitesine ve ağ koşullarına bağlıdır; yalnızca yaklaşık hesap içindir.
| Senaryo | Kazanılan boyut | USB 3 mekanik disk @120 MB/s | USB 3 SSD @450 MB/s | Gigabit ağ @105 MB/s |
|---|---|---|---|---|
| Bu testteki görseller | 662 MB | ≈5,5 sn | ≈1,5 sn | ≈6,3 sn |
| 10 GB kitaplık | 4,68 GB | ≈40 sn | ≈10 sn | ≈45 sn |
| 100 GB kitaplık | 46,8 GB | ≈6,5 dk | ≈1,7 dk | ≈7,4 dk |
| 1 TB kitaplık | 479 GB | ≈66 dk | ≈18 dk | ≈76 dk |
Bu testteki tek seferlik 662 MB, yalnızca birkaç saniye olduğu için az görünebilir. Ancak depolama ücretindeki mantıkla aynı şekilde, bu tek seferlik bir yatırım ve uzun vadeli bir kazançtır: ister taşınabilir diske kopyalayıp çıkarın, ister NAS senkronlayın, ister Time Machine çalıştırın, ister yeni Mac’e geçin ya da meslektaşınıza iletin — bu verileri her taşıdığınızda aynı oranda zaman kazanırsınız. Bir kez sıkıştırın; sonraki her aktarımda zaman kazancı sürer.
Sıkıştırma Kullanıcı Yüklemesinden Önceyse: Kazanılan Bekleme Süresi
Yukarıdaki hesaplar, “görseller depolandıktan sonraki” kazançları içeriyor: depolama ücreti, CDN trafiği, yerel aktarım. Bir de ayrıca üzerinde durulmaya değer bir halka var: kullanıcının “Yükle” düğmesine bastığı andan ilerleme çubuğunun tamamlandığı ana kadar geçen bekleme süresi. Bu süre kullanıcının kendi yükleme (upload) bant genişliğini kullanır ve yükleme hızı genellikle tüm bağlantıdaki en yavaş darboğazdır — çoğu tüketici geniş bant bağlantısının yükleme hızı, indirme hızının yalnızca beşte biri ila onda biri kadardır; mobil ağlarda bu daha da belirgindir. Web sitesi veya uygulama, kullanıcı yüklemeden önce görselleri ImgZilla ile sıkıştırırsa, kazanılan boyut doğrudan kullanıcının bekleyeceği sürenin azalmasına dönüşür.
Bu testteki ortalama görsel boyutuyla hesap yapalım: sitenin daha önce sıkıştırdığı orijinalde ortalama 299 KB, ImgZilla sonrası ortalama 159 KB; görsel başına ortalama 140 KB kadar kazanç.
| Yükleme bant genişliği (açık hız testi verilerinin tipik aralığı, yalnızca referans) | Tek görsel 299 KB → 159 KB |
50 görselli albüm yükleme ≈15,0 MB → 8,0 MB |
Bu testteki 4624 görselin tümü 1,41 GB → 0,75 GB |
|---|---|---|---|
| Mobil ağ (4G/5G karışık; Çin’deki açık hız testlerinde medyan yaklaşık 10–50 Mbps, 30 Mbps alınmıştır) | ≈0,04 sn tasarruf | ≈1,9 sn tasarruf | ≈3 dk tasarruf |
| Yaygın ev geniş bant yükleme hızı (100/1000 Mbps indirme paketlerinde yükleme genellikle sınırlıdır; yaklaşık 20–30 Mbps, 25 Mbps alınmıştır) | ≈0,04 sn tasarruf | ≈2,2 sn tasarruf | ≈3,5 dk tasarruf |
| Gigabit simetrik geniş bant yükleme (az sayıda operatör/kurumsal hat, 1000 Mbps) | ≈0,001 sn tasarruf | ≈0,06 sn tasarruf | ≈5,3 sn tasarruf |
| Yurtdışı referans: ABD ortalama sabit geniş bant yükleme hızı (Ookla verileri, 2026) | ≈0,02 sn tasarruf | ≈1 sn tasarruf | ≈1,5 dk tasarruf |
Bu tabloya tek görsel açısından bakınca anlamsız görünebilir — 0,04 saniye neredeyse hissedilmez. Bu dürüst bir sonuçtur: bu test örneklemi zaten büyük değildi (web sitesi depolamadan önce sıkıştırmış; ortalaması yalnızca 299 KB). Değeri ortaya koyan iki senaryo vardır: bir albümü veya onlarca görseli tek seferde yükleyen toplu işlemler ve daha büyük ham kaynaklar (örneğin kameradan çıkan JPEG’ler veya web sitesinde sıkıştırılmamış ilk kez yüklenen UGC görselleri — bunlar genellikle birkaç yüz KB değil, birkaç MB olur). Aynı sıkıştırma oranında, tasarruf edilen mutlak saniyeler de aynı oranda büyür. Zaten yavaş yükleme bant genişliğine sahip mobil ağ kullanıcıları için bekleme süresindeki kısalma daha da belirgin olacaktır.
Mobil ağ ve ev geniş bandı aralıkları, Çin’deki açık hız testi istatistiklerine dayanır (4G/5G medyanı, geniş bant yükleme oranları). Gerçek hızlar operatöre, bölgeye, cihaza ve ağ tıkanıklığına göre büyük ölçüde değişir; yalnızca büyüklük sırası için referans verilmiştir. ABD sabit geniş bant yükleme verileri Ookla Speedtest ile ilgili raporlardan alınmıştır.
Kendiniz doğrulamak ister misiniz? ImgZilla’yı doğrudan Mac App Store’dan indirin, kendi sitenizde işlenmiş birkaç görselle test edin, sonra diğerlerini sıkıştırıp sıkıştırmamaya karar verin.
Mac App Store: https://apps.apple.com/app/apple-store/id6749323539?pt=127227004&ct=v2&mt=8
Daha fazla bilgi: https://imagetool.app/ImgZilla