壓縮工具最常見的宣傳口徑，就是「體積減少 70%」這類無從查證的數字。本文不引用任何行業統計數據，只放一組真實跑測結果，附上完整對照方法，任何人都可以自行複現。
一、測試對象：不是原圖，而是「別人已經壓過一遍」的圖
多數壓縮測試選用相機直出的原始圖片，條件過於理想。本次測試刻意貼近真實業務場景：一個允許用戶上傳圖片的網站，入庫時已經自行執行過一輪常規壓縮——也就是說，測試對象不是未經處理的生圖，而是已經被「壓過一次」的成品圖。
樣本規模：78 個資料夾，共 4624 張圖片（以 JPG 為主），目錄結構為「一個專輯一個資料夾」的典型歸檔方式，未做任何篩選或清洗。
這批檔案在伺服器上的原始總體積：1.41 GB。
核心問題：一張已經被壓縮工具處理過的圖片，再交給另一個壓縮工具，還能擠出多少空間？ 多數使用者直覺認為「壓過就壓過了，再壓也意義不大」。
二、對照組：打包成 zip 能省多少？
在執行 ImgZilla 之前，先將同一批檔案原樣打包為 zip，觀察通用壓縮演算法的效果：
| 體積 | 相對原始 | |
|---|---|---|
| 網站壓縮後的原始檔案 | 1.41 GB | — |
| 打包成 zip | 1.41 GB | -0.2% |
幾乎無變化。原因不複雜：JPEG 本身就是一種壓縮格式，圖像資料已經過熵編碼，通用演算法（zip 使用 DEFLATE）面對已壓縮資料難以進一步壓縮——無論原圖是否經過網站處理，zip 對此都無能為力。
三、ImgZilla 再壓縮實測
將上述檔案拖入 ImgZilla，原地壓縮。78 個資料夾、4624 張圖片，檔案名稱與目錄結構完全保留：
| 體積 | 相對原始 | |
|---|---|---|
| 網站壓縮後的原始檔案 | 1.41 GB | — |
| 打包成 zip | 1.41 GB | -0.2% |
| ImgZilla 再壓縮後 | 0.75 GB | -46.8% |
在網站已自行壓縮的基礎上，ImgZilla 額外省下約 662 MB，體積接近腰斬。 所有資料夾路徑、檔名、層級關係前後完全一致——這是可直接核驗的真實數據，並非行銷話術。
這說明一個關鍵事實：「網站上傳時壓過」與「使用格式特定參數進行精細編碼壓縮」是兩回事。 多數網站入庫時執行的是一次性、偏保守的壓縮（通常僅限制品質參數或尺寸），遠未榨乾每種格式的編碼空間。ImgZilla 針對每種格式單獨調校參數，對 JPEG 實施視覺無損的重新編碼——像素層面確實存在變化，但參數設定在肉眼幾乎無法分辨的區間，從而在「已壓縮」的基礎上繼續挖掘空間。
需要澄清一個容易混淆的概念：「視覺無損」不等於「無損」。真正意義上的無損（像素完全不變）僅適用於 PNG（oxipng）和 SVG；JPEG、WebP、AVIF、HEIC、GIF 在原理上均屬於有損重新編碼，只是壓縮參數被控制在視覺無損的閾值內。ImgZilla 內建對比視窗，支援壓縮前後左右分割畫面、縮放至實際大小逐像素比對，可供自行驗證。
四、明細分析：逐檔案壓縮比、像素尺寸與任務耗時
前面 46.8% 的總體壓縮率是 4624 張圖片的彙總結果。拆解到單一檔案層面，還能獲得更多細節。
每張圖片的壓縮比分佈不均
逐一計算每張圖的壓縮比（壓縮後位元組數 / 壓縮前位元組數），範圍從 32.3% 到 85.8% 不等：
- 壓縮比最高的一批：約 765 KB 壓至 109 KB，壓縮比 85.8%——這類圖片通常初始壓縮強度不足，仍有較大重新編碼空間。
- 壓縮比最低的一批：約 572 KB 壓至 387 KB，壓縮比 32.3%——這類圖片此前已被壓縮得較狠，可挖掘餘地有限。
- 4624 張圖片的壓縮比算術平均值為 46.44%，與按總體積計算的 46.8% 接近但不完全相同——前者是各檔案壓縮比的簡單平均，後者是「總節省位元組 ÷ 總原始位元組」，兩者差異表明，壓縮比高低不同的檔案在總體積中的權重並不對稱，少數大體積檔案對總量影響更大。
值得注意的是，所有圖片的壓縮比均為正數，沒有出現「已最小、跳過」的情況——即這批「網站已壓縮過」的圖片，每一張都能被 ImgZilla 繼續壓縮出實際空間。
像素尺寸：分毫不差
統計全部 4624 張圖片的像素尺寸，最常見規格為 1600×2400（1756 張）及其橫式 2400×1600（500 張），尺寸範圍從最小的 450×675（約 30 萬像素）到最大的 3000×2000 / 2000×3000（約 600 萬像素）。
抽樣核對壓縮前後像素尺寸，完全一致，無任何變化：
| 檔案（範例） | 原始尺寸 | 壓縮後尺寸 |
|---|---|---|
| 樣本 1 | 1600×1066 | 1600×1066 |
| 樣本 2 | 2000×3000 | 2000×3000 |
| 樣本 3 | 1416×2128 | 1416×2128 |
這也是「原地壓縮」定義中容易被忽視的另一半：不僅檔案名稱和路徑不變，解析度也固定不動。ImgZilla 不做縮放、不裁切，所有體積縮減純粹來自重新編碼，而非犧牲像素。
任務耗時：51 分 32 秒完成 4624 張，平均每張 0.669 秒
測試環境：Mac mini 搭載 Apple M1 晶片，8GB 統一記憶體，圖片存放於透過 2.5G 有線網路連接的 NAS 機械硬碟中。
依據每張圖片的最後寫入時間（即 ImgZilla 完成壓縮並寫回磁碟的時刻）追蹤任務進度：首張寫入於 16:06:09，末張寫入於 16:57:41，整批處理總耗時 51 分 32 秒，平均每張 0.669 秒。
該數據符合產品「循序處理」的設計——逐張順序壓縮，而非並行亂序寫入。換算下來，約為每分鐘處理 90 張。實際速度取決於圖片體積和機器效能，此處給出的僅為這批平均單張 ~305 KB 圖片在以上環境中的真實耗時，並非通用基準。
五、為何選擇「原地」壓縮而非另存副本
如果本次測試採用「另存為壓縮版」的工具，結果將是：原始檔案 1.41 GB + 壓縮版 0.75 GB，同時佔用 2.16 GB，反而更加佔空間，且會生成大量 xxx-min.jpg 檔案，需要手動整理並更新資料庫或商品表中的引用。
ImgZilla 採用原地覆寫方式：壓縮結果直接寫回原路徑，78 個資料夾中的 4624 個檔案名稱均保持不變——這對已將圖片路徑寫入資料庫、CDN、CMS 引用的網站尤為重要，壓縮後無需改動任何連結。代價是它會修改原始檔案，因此預設先將原圖移入系統垃圾桶，再寫入壓縮結果，如需反悔，可在垃圾桶中按右鍵「放回原處」。
六、收益分析：從實際場景到月度帳單
這組數據對哪些人有實際價值
- 擁有使用者上傳圖片業務的網站 / 開發者：圖片儲存和 CDN 流量通常按 GB 計費，體積減半意味著帳單直接減半——且流量費是每次訪問都會產生的成本，訪問量越大，複利效應越顯著。即使入庫時已執行常規壓縮，本次實測表明，「再執行一輪專門調校的壓縮」仍能獲得可觀收益。
- 儲存空間緊張的伺服器 / 小容量磁碟使用者：清理工具通常刪除快取和重複檔案，但數月後又會重新堆積；而壓縮騰出的空間是正在使用的檔案本身變小了，不會反彈。這批 78 個資料夾壓縮後直接多出 662 MB 可用空間，且為永久性釋放。
- 頻繁搬運資料的使用者：拷貝、同步、備份時，體積削減 46.8%，傳輸時間基本同步縮短。壓一次，後續每次搬運都能省時。
換算成月度帳單：這 46.8% 究竟值多少錢
體積縮減最終要體現在帳單上才有說服力。以下不引用任何「壓縮提升轉化率」之類的統計，僅將本次實測的 46.8% 乘以主流雲端服務商的公開儲存/流量報價，做純算術推算。
儲存費節省 = 省下的體積（GB） × 單價（元或美元 / GB / 月）
流出流量費節省 = 省下的體積（GB） × 當月下載/訪問次數 × 單價（元或美元 / GB）
體積減半，兩項帳單基本也隨之下調一半——這是數學，而非猜測。
儲存費：圖庫越大，收益越明顯
中國大陸廠商：
| 圖庫原始大小 | 省下體積 | 阿里雲 OSS 標準儲存 ¥0.09/GB/月 |
|---|---|---|
| 10 GB | 4.68 GB | ¥0.42/月 |
| 100 GB | 46.8 GB | ¥4.21/月 |
| 1 TB | 479 GB | ¥43.1/月 |
海外廠商：
| 圖庫原始大小 | 省下體積 | AWS S3 Standard $0.023/GB/月 |
Google Cloud Storage $0.020/GB/月（美區 Regional） |
Azure Blob Storage $0.018/GB/月（Hot, LRS） |
Cloudflare R2 $0.015/GB/月 |
|---|---|---|---|---|---|
| 10 GB | 4.68 GB | $0.11/月 | $0.09/月 | $0.08/月 | $0.07/月 |
| 100 GB | 46.8 GB | $1.08/月 | $0.94/月 | $0.84/月 | $0.70/月 |
| 1 TB | 479 GB | $11.02/月 | $9.58/月 | $8.62/月 | $7.19/月 |
幾家海外大廠的儲存單價非常接近（差距在 30% 以內），重點不在於誰更便宜，而在於——無論選哪家，體積減半，該項帳單基本都隨之減半，且按月度重複計費。一次壓縮，此後每月均按新體積計費，屬於一次性投入、長期持續兌現的收益。
流量費：真正的大頭，隨訪問量放大
流量費比儲存費更值得關注，因為它是 體積 × 下載次數 的乘積——圖片被訪問越頻繁，壓縮收益越高。假設一個 100 GB 的圖庫，當月透過 CDN 產生 500 GB 下行流量（相當於整庫被完整下載約 5 次）：
| CDN / 出口流量報價（首檔價） | 壓縮前每月流量費 | 壓縮後（流量同比 -46.8%） | 每月省 | 一年省 |
|---|---|---|---|---|
| 阿里雲 CDN 中國大陸（低檔 ¥0.15/GB） | ¥75.0 | ¥39.9 | ¥35.1 | ¥421 |
| AWS CloudFront 亞太區（$0.12/GB） | $60.0 | $31.9 | $28.1 | $337 |
| Google Cloud CDN 北美/歐洲（$0.08/GB） | $40.0 | $21.3 | $18.7 | $224 |
| Azure Front Door 標準版 Zone 1（$0.08/GB） | $40.0 | $21.3 | $18.7 | $224 |
以上取各家最低階梯價，實際階梯價格往往更高（阿里雲 CDN 中國大陸流量階梯最高可達 ¥1.31/GB），帳單越大，壓縮節省的絕對值越可觀。另外 Azure 這一檔目前為 Front Door 標準版，除按 GB 計費的出口流量外，還包含約 $35/月的基礎服務費，該費用壓縮無法減少，未計入上表的節省中。
Cloudflare R2 是個例外：其出口流量本身就是 $0 ——若儲存桶搭配 R2，壓縮收益幾乎全部體現在儲存費上，流量部分本身無帳單。這與「儲存 + 流量」雙重計費架構（如阿里雲 OSS+CDN、AWS S3+CloudFront）屬於不同的成本結構，選擇服務商前需明確自身計費項。
以上單價為 2026 年各平台公開報價整理，實際價格受地域、帳戶折扣、階梯檔位影響，請以官網即時價格為準；下載次數、訪問量為示例假設，請替換為自己的帳單真實數據進行估算。
七、傳輸與上傳時間的節省
體積減半，傳輸時間基本同步縮短——這項規律不依賴雲端帳單，既體現在本地拷貝、備份中，也體現在使用者上傳環節。
本地場景：USB 3 與千兆網路
- USB 3 行動機械硬碟：持續讀寫吞吐常見 100–150 MB/s，取中位數 120 MB/s。
- USB 3 行動固態硬碟：吞吐明顯更高，常見 400–500 MB/s，取 450 MB/s。
- 千兆有線網路（1000 Mbps）：理論上限 125 MB/s，扣除協定開銷，實測持續吞吐約 100–110 MB/s，取 105 MB/s。
上述為常見實測區間的估算值，實際速度受硬碟介質、介面品質、網路環境影響，僅供估算參考。
| 場景 | 省下體積 | USB 3 機械硬碟 @120 MB/s | USB 3 固態硬碟 @450 MB/s | 千兆網路 @105 MB/s |
|---|---|---|---|---|
| 本次實測的這批圖 | 662 MB | ≈5.5 秒 | ≈1.5 秒 | ≈6.3 秒 |
| 10 GB 圖庫 | 4.68 GB | ≈40 秒 | ≈10 秒 | ≈45 秒 |
| 100 GB 圖庫 | 46.8 GB | ≈6.5 分鐘 | ≈1.7 分鐘 | ≈7.4 分鐘 |
| 1 TB 圖庫 | 479 GB | ≈66 分鐘 | ≈18 分鐘 | ≈76 分鐘 |
本次實測的 662 MB 單次看起來不多，僅幾秒鐘。但與儲存費同理，這是一次性投入、長期持續的收益：無論是拷入拷出行動硬碟、同步 NAS、執行 Time Machine、遷移新 Mac，還是傳給同事，只要還在搬運這批資料，每次都能按同比例節省時間。壓一次，之後每一次搬運都在省時。
若壓縮發生在使用者上傳之前：省下的等待時間
前面計算的是「圖片儲存後」的收益——儲存費、CDN 流量費、本地傳輸。還有一環更值得考慮：使用者按下「上傳」按鈕到進度條完成的等待時間，走的是使用者自己的上行頻寬，而上行通常是整條鏈路中最慢的瓶頸——多數消費級寬頻的上行僅有下行的十分之一到五分之一，行動網路尤甚。如果在使用者上傳前，網站或 App 先用 ImgZilla 壓縮圖片，省下的體積將直接轉化為使用者減少的等待時長。
以本次實測的單張圖片平均體積計算：網站已壓縮過的原始圖片平均 299 KB，ImgZilla 再壓縮後平均 159 KB，每張平均省約 140 KB。
| 上傳頻寬（公開測速資料的典型區間，僅供參考） | 單張圖 299KB→159KB |
上傳 50 張相簿 ≈15.0MB→8.0MB |
上傳本次實測全部 4624 張 1.41GB→0.75GB |
|---|---|---|---|
| 行動網路（4G/5G 綜合，中國大陸公開測速中位數約 10–50 Mbps，取 30 Mbps） | 省約 0.04 秒 | 省約 1.9 秒 | 省約 3 分鐘 |
| 常見家庭寬頻上行（百兆/千兆下行方案，上行普遍受限，約 20–30 Mbps，取 25 Mbps） | 省約 0.04 秒 | 省約 2.2 秒 | 省約 3.5 分鐘 |
| 千兆對稱寬頻上行（少數電信商/企業專線，1000 Mbps） | 省約 0.001 秒 | 省約 0.06 秒 | 省約 5.3 秒 |
| 海外參考：美國平均固定寬頻上行（Ookla 數據，2026） | 省約 0.02 秒 | 省約 1 秒 | 省約 1.5 分鐘 |
單張圖看此表似乎無意義——0.04 秒幾乎無法感知，這是誠實的結果：這批測試樣本本身已不大（網站入庫前已壓縮，平均每張僅 299 KB）。真正能體現價值的場景有兩個：一次上傳整本相簿或數十張圖的批次操作，以及體積更大的原始素材（如相機直出的 JPEG 或未經過網站壓縮的 UGC 首次上傳，單張通常達數 MB 而非幾百 KB）——相同壓縮比例下，絕對節省的秒數也將同比例放大。對於上行頻寬本就偏慢的行動網路使用者，等待時間的縮短會更加明顯。
行動網路與家庭寬頻的區間數字基於中國大陸公開測速統計（4G/5G 中位數、寬頻上行常見配比），實際速度受電信商、地區、設備、網路壅塞影響較大，僅作數量級參考；美國固定寬頻上行數據引用自 Ookla Speedtest 相關報導。
想親自驗證？ 直接從 Mac App Store 下載 ImgZilla，用自己網站上已處理過的幾張圖實測一遍，再決定是否繼續壓縮其它。
Mac App Store： https://apps.apple.com/app/apple-store/id6749323539?pt=127227004&ct=v2&mt=8
了解更多： https://imagetool.app/ImgZilla