圖片壓縮工具怎麼選：先找瓶頸再對症下藥的決策流程

有一種週一早晨是這樣開始的：行銷主管花了一個週末，把站上兩百多張商品圖逐張丟進線上壓縮服務，下載、覆蓋、重新上傳，檔案確實都縮小三到五成；隔天行動版的測速截圖傳回來，分數還是停在黃區，幾乎沒有挪動。追問跟著到：「是不是圖還不夠小？」此刻最誠實的答案恰恰相反：你已經壓得夠拚了，卡住的是施力順序。省體積報酬最高的動作，常常不是把檔案壓得更狠，而是少傳一些像素；順序錯了，後面的拚勁都花在報酬最小的那一層。

把場景拉遠一點看。主機升級過、快取做過、CDN 也接了，分數依然不動時，圖片通常是下一個該盤點的資源，這個直覺有數字背景：來自行動裝置的造訪約占全球網站流量的一半（依 Statista 的季別統計），而 web.dev 對載入速度與使用者行為的說明也把速度與去留連在一起。但「下一個該查」不等於「一定就是它」，字型、腳本、伺服器回應都在爭同一條頻寬，每個站的大宗資源不同，唯一公平的裁判是量測。

快速重點：省體積的施力順序是先縮尺寸、再設品質、第三層才是格式；失真編碼整條流程只該發生一次。用三個問題決定壓縮的位置：圖在哪個階段能被處理、每月圖量多大、圖能不能交給第三方。判斷寫成內部規格，挑工具排在終點而非起點。

壓了還是慢？先確認圖片是不是真的兇手

先把答案說清楚：壓縮只作用在三層槓桿裡的最下層，它處理不了「根本不需要傳的像素」，也碰不到字型、JavaScript 與伺服器回應占用的時間。動手壓任何一張圖之前，先花十分鐘做確認，這十分鐘決定接下來兩週的工有沒有效，也決定你向公司解釋資源去哪裡時，手上有沒有證據。

確認有三個動作。第一，跑一次網站速度檢測，把行動版的 LCP 數字與整頁傳輸量抄下來，這組數字是基準線，壓縮前後都拿它對比，也是日後說服內部的籌碼。第二，打開開發者工具裡的 Network 面板，重新載入頁面，照資源大小排序，看最大的幾個請求是圖、是字型、還是打包過的腳本，Lighthouse 這類工具的報告可以對照著看。第三，找出 LCP 元素是誰：是首圖、輪播，還是一段大標文字。三個動作做完，「圖片是不是兇手」就不再是猜測。

量測時有兩個細節容易漏。測的時候要模擬行動端網路，辦公室光纖會把問題全部藏起來，把網路節流到 4G 再看一次，數字才貼近真實訪客的處境；抄數字時連同日期與網路條件一起記，隔兩週再量，變因才有得比對。量完之後的判讀也要克制：字型與腳本占大宗時，該做的是字型子集化與拆包，不是回頭把圖壓得更小；伺服器回應時間長，該查的是快取與資料庫查詢。圖片在這兩種情境裡都是無辜的，繼續壓它只是做心安的。

「圖片占網頁一半以上」這句話流傳很廣，但它不是通則。以文字為主的媒體站、以圖為本的電商與作品集，占比差得很遠，同一個站在改版前後也會變動。行動版確實是主戰場，這也有官方依據：Google 的行動優先索引已全面部署完畢（Mobile-first indexing is here 公告），檢索與評估看的是行動版呈現的內容。基準線量出來之後，下一個問題是：一張圖的重量到底從哪裡來。

一張圖的重量從哪裡來：尺寸、品質與格式三層槓桿

一張未壓縮的點陣圖，體積大致等於像素數量乘上每個像素占用的位元數。可以把一張照片想成一團旅客：像素是人數，位元深度是每人手上的行李，四千萬個旅客、每人三件行李，無論行李怎麼重新打包，總重量就是人數乘上行李數。要減重，先減人數，這是後面所有槓桿的出發點。

這條公式可以粗算一遍。一張 4000×3000 的全彩照片，每像素三個位元組，未壓縮的原始資料約三千六百萬個位元組；就算相機存檔時已經過一道編碼，落在千萬位元組級也不奇怪。同樣的畫面縮到 1600px 長邊，像素數剩不到兩成，體積的量級直接掉一階。這就是「先減人數」的數學根據：任何後端的壓縮技巧，都追不上前端少傳像素的省法。

能動的槓桿有三層，省幅一層比一層小。第一層是解析度：版位需要多少像素，就只給多少，砍在這裡的每一個像素都是全額省下。第二層是品質參數：失真編碼願意丟掉多少細節，數字設下去，體積跟著變。第三層才是格式：同樣的畫面交給不同編碼器，成果不同。EXIF 與其他詮釋資料也占體積，但那是零頭，值得順手清，救不了大局。

用一張 4000px 的商品照做方法示範，數字以量級呈現，實際結果依內容與設定浮動：

↔ 左右捲動檢視完整表格

處理階段	動作	檔案量級變化
原始輸出	4000px、相機預設品質	千萬位元組級
第一層	縮到版位實際需要的 1600px	掉一個數量級
第二層	品質參數設在中段	再少一大段
第三層	轉成現代格式	再收一截

槓桿的施力順序，就是報酬的順序。解析度遠超過顯示需求時，壓縮等於在浪費上做精算：手機版位只有 375px 寬，上傳的卻是 4000px 原圖，多出來的像素占了頻寬，在畫面上卻沒有任何表現機會，先把尺寸對齊版位，後面的動作才有意義。完整的排序是先縮尺寸、再設品質、格式放在第三層；順序顛倒，等於在最便宜的槓桿上斤斤計較、把最貴的槓桿留給自己扛。WebP、JPG、PNG 的格式特性與轉檔取捨，站上另有專文展開：三種常見格式的挑選邏輯與適用情境。

壓過頭會長什麼樣：失真機制與三個肉眼檢查點

失真壓縮不是亂丟資料，它丟的位置經過挑選，標準是人眼的弱點。人眼對亮度的變化遠比色彩敏銳，多數編碼器因此把色彩的解析度記得比亮度粗，這叫色度抽樣。人眼對平坦區域的細微變化比雜亂紋理區敏感，編碼器於是把部分頻率成分粗略量化，紋理裡的細節先被捨去。第三個機制發生在邊緣：銳利輪廓在頻率上是變化最劇烈的成分，量化把它削掉時，邊緣周圍會長出原本不存在的波紋狀暈染，這叫振鈴。人眼對這種暈染特別敏感，因為大腦靠邊緣判斷物體輪廓，邊緣一糊，整張圖的清晰感就垮了。這幾個設計解釋了為什麼輕度失真肉眼多半無感，也解釋了丟過頭時，傷痕為什麼總出現在同樣的地方。

露餡的位置固定，驗收因此可以用肉眼完成。放大圖片，依序看三個地方：天空、白牆、純色背景這類平坦色塊，有沒有一格一格的方塊感；文字與商品輪廓這類銳利邊緣，有沒有暈開或鑲上色邊；夕陽、膚色這類漸層，有沒有變成一圈一圈的色階。任何一個位置看得出瑕疵，就回頭把品質參數抬高一級再出一次，不要拿縮圖看起來還好當準則，縮圖會藏掉一半的問題。

這三個檢查點也反推了處理方式的分界。截圖、圖表、含文字的圖，內容恰恰由平坦色塊與銳利邊緣組成，是失真最先露餡的類型，該走無失真處理；照片的細節雜、雜訊多，人眼容忍度高，合理的失真設定能換來一個量級的體積差。把這兩類混在一起用同一種設定處理，是「壓完變糊」這類求救訊號的主要來源。

還有一種傷害不會立刻露臉，叫世代損失。失真編碼丟掉的細節拿不回來，對已經失真的檔再編碼一次，瑕疵疊加，畫質一路向下，檔案卻未必更小。實務上最常見的翻車現場，是同一張圖在流程裡被壓三次：設計師交稿前壓一次，上傳後站內外掛壓一次，快取或效能外掛再壓一次。防範原則只有一條：保留原始母檔，整條流程指定唯一一處做失真編碼，其餘環節不是無失真、就是不動。

品質 80 不是八成畫質：把判斷寫成內部規格

開始操作任何工具，第一個遇到的數字就是品質參數，而它最常被讀成「畫質百分比」。多數編碼器的品質數字，其實是量化表組合的編號：編碼器內建一組量化策略，數字只是選表的索引。這帶出兩個推論。在同一款工具內部，數字越大、丟得越少，前後對照有意義；跨工具之間，MozJPEG 的 80 與 WebP 的 80 指向不同的量化策略，拿兩個 80 互比檔案大小，比不出誰的畫質好。要比，就用同一款工具的不同設定對自己的圖輸出前後對照。

與其記住別人工具的預設值，把判斷寫成自己站上的規格：每種版位一組參數。規格表不用複雜，一份能用的版本長這樣，級距為示範，實際數字依量測調整：

↔ 左右捲動檢視完整表格

版位	長邊上限	處理方式	單張預算
首頁主視覺	1920px	中高品質失真	250KB 級
商品主圖	1600px	中品質失真	300KB 級
文章插圖	1200px	中品質失真	150KB 級
圖示與截圖	依原尺寸	無失真	不另設

母檔存在哪裡、用什麼規則命名歸檔，寫進同一份文件。規格一旦寫下來，誰操作都是同一條線，人員替換、外包交接，品質不會跟著走山。工具品牌會改版、會調價、會停更，規格才是留得住的資產。

用一個建構情境說明規格的價值。花東一位民宿主人，官網的房間圖全是手機直拍的原始檔，媒體庫裡每張三到八個百萬位元組，房間頁開起來就是慢。只做一次性批次壓縮，新照片上架隔天又回到原樣；反過來，先把規則定下來，房間圖長邊 1600px、單張不超過 300KB 這類級距，實際數字依量測調整，上傳時由外掛把關，舊圖批次跑一輪，之後每張新圖自動符合規則，維護成本趨近於零。這正是「上傳時」這個位置的價值：規則只寫一次，卻每天生效。

WebP 與 AVIF 省多少：用自己的圖才算數

「換 WebP 能省多少」沒有地毯式的答案，但也不是全無座標。Google 的 WebP 開發文件給的是量測出來的基準：無失真模式比同畫面的 PNG 小約 26%，失真模式在同等畫質下比 JPEG 小 25–34%；這種格式同時支援兩種壓縮，也保留透明度。這組數字是官方量測的平均落差，換到你的站上，省幅仍取決於圖片內容、編碼器與品質設定，離開這三個變數的百分比，都只是別人站上的結果，抄不過來。

實際比較的方法很樸素：從圖庫抽十張有代表性的圖，細節多的、平色面積大的、含文字的各挑幾張，用同一組設定跑兩種格式，檔案大小並排、放大並排看。半小時的工，換來「你的站、你的圖」專屬的答案，比任何轉載來的百分比都可靠，也順便讓團隊親眼看到品質臨界點落在哪裡。

對既有已失真的 JPEG 做無失真重編碼，期待也要放低：資料早已被丟過一輪，無失真能擠的空間有限，真正的量級差異來自回到母檔、用合理的失真設定重新編碼。AVIF 常常再小一截，代價是編碼運算成本高，省幅同樣隨內容變動；需要照顧不支援的舊環境時，用 picture 元素排好來源順序、提供回退格式即可，格式的挑選邏輯前文已指向專文，不再重複。

三個盤點問題，畫出你的壓縮決策地圖

工具形態那麼多，從哪一種開始評估？先回答三個盤點問題，答案會直接把你帶到地圖上的某一條分支，選擇題瞬間變成是非題。

第一問，位置：圖在哪個階段有機會被處理？設計或攝影交稿進站之前、內容管理系統上傳的當下、部署管線自動化的環節，三個位址對應三類完全不同的工具。第二問，量：一季補十張圖，跟每天進上百張圖，是兩個物種；量小，手動工具的摩擦可以忽略，量大，任何需要人記得的動作終將被遺忘，自動化的投資報酬完全不同。第三問，隱私：含個資的表單截圖、客戶委託的素材、未公開的產品照，該不該上傳到第三方伺服器？這一問會直接淘汰一部分線上服務，也是許多推薦名單從來不問的問題。

量的判斷有個樸素的算法：每月新進的圖片張數，乘上每張手動處理需要的分鐘數。一季十張、每張兩分鐘，一年湊不滿兩小時，手動完全合理；每天三十張、每張兩分鐘，一個月下來是三十小時，等於半個人力，這時幾乎任何自動化方案都比人力便宜。數字不必精確，量級出來，投資方向就清楚了。

三問有先後。位置先於量，因為位置圈出工具形態的範圍；量先於隱私，因為量決定自動化的必要性；隱私在終點把不合格的候選剔除。順序倒過來的人，常在還不知道自己需要哪種形態之前，就先為單一服務的條款反覆糾結，把決策做反了。

一個建構情境：品牌官網改版，設計公司一次交付三百張 4000px 的產品照，兩週內要全數上線。這種一次性、大批量、且圖本來就要公開的組合，指向「進站前」分支：在交稿端整批把關，進站後的系統保持簡單，日期壓力下也不會有人手忙腳亂選錯設定。位置、量、隱私三個答案湊齊，決策樹就自己長出來了。

決策樹三部曲：圖該在哪個位置被壓縮

三個位置各有適合的站情，判準是隱私掌控、可重現與維運成本，不是功能清單的長度。同一站只擇一處做失真編碼，其餘環節保持無失真或退場，這是唯一失真點原則的落地版本。

進站前：交稿端把關

圖在你手上，就在你手上處理。macOS 上的 ImageOptim 與 Windows 上的 FileOptimizer，是交稿前的守門員，設計端交付前整批過一次，下游什麼都不必裝。一次性的少量需求，Squoosh 很合適：運算在瀏覽器內完成，圖不離開本機，前後對比的介面拿來當驗收教材也直觀。TinyPNG 這類雲端服務方便快速，代價是圖要上傳到別人的伺服器，能不能用，回到盤點的第三問。

這個分支要配一頁交稿規格單：圖檔以最終顯示尺寸交付、檔名照命名規則、格式與品質照站上規格，驗收時抽幾張放大看邊緣。規格單的存在，讓把關不依賴設計端的自覺，也不依賴接案者的記性；換一家設計公司，同一頁規格單照用。

上傳時：站內單一外掛

圖直接進 WordPress 的站，把上傳環節的壓縮與現代格式輸出交給同一支外掛。全球超過四成網站跑在 WordPress 上（依 W3Techs 的長期追蹤），這個生態裡圖片外掛的選擇也最多，原則同樣是擇一：兩套並行會造成雙重失真與 WebP 產生規則的衝突。Smush 在站上有從安裝到設定的逐步拆解；Imagify 與 WP Rocket 同一陣營，已在用 WP Rocket 的站，可把速度設定的整體規劃一併看完再決定；ShortPixel 走額度計費，採用前先查當期方案。EWWW 提供自架伺服器的選項，圖不出站，是隱私軸上的高分選擇；Optimole 反向操作，全雲端託管，便利與掌控互換。外掛怎麼放進整體藍圖，可對照WordPress 外掛的選用總覽。

部署時：寫進管線

站走靜態產生器或 Headless 架構，壓縮就屬於部署管線的一部分。Node 管線裡用 sharp 做縮放與轉檔，cwebp 輸出現代格式，jpegoptim 能設單張檔案上限，PNG 的色盤轉換交給 pngquant。管線的價值在可重現：工具版本與參數鎖定後，同一張母檔任何時候重跑，輸出一致，不依賴任何人記得。寫進管線還有一個隱性好處：規格變成程式碼，長邊像素、品質參數、檔案上限都在設定檔裡，檢視時看得到、改動留得下紀錄，不會像口頭約定那樣隨人事漂移。

↔ 左右捲動檢視完整表格

壓縮位置	圖在誰手上	隱私掌控	適合的量級	維運成本
進站前	交稿者本機	完全自持	一次性大批或零星補圖	低，靠規格文件約束
上傳時	站內外掛	依方案，可自架或雲端	持續進圖的內容站	中，設定與額度管理
部署時	版控與建置流程	完全自持	大量且重複的固定版位	高，需要工程維護

壓縮之後的路徑：讓量測決定優先順序

圖都壓好了，分數還沒拿下來，更強的壓縮幫不上忙，該看的是一組下游工程：格式、延遲載入、尺寸標記、快取與 CDN。它們與壓縮是乘法關係，缺任何一項，前面的成果都會被打折，整組做法在網站速度調校的完整脈絡裡有系統性的展開。

尺寸標記先講。srcset 與 sizes 負責宣告多種寬度的版本，瀏覽器自己挑接近螢幕的那一份，手機因此不必拉桌機用的大檔，這是響應式版面的原理在圖片上的直接應用。延遲載入照顧首屏以外的圖，長文與列表頁感受明顯；但哪些圖不該延遲、設定怎麼寫才不誤傷首屏，要照延遲載入的設定與例外逐項檢查，不是加上屬性就收工。

對 Core Web Vitals 的對應關係也是固定的：大型首圖直接影響 LCP；圖片未標示寬高，載入時版面跳動，反映在 CLS；解碼占用的主執行緒時間與 INP 的關係，要用效能面板實測確認。各項指標的組成與量測方式，見Core Web Vitals 的組成與量測。

先後順序交給量測判定。確認 LCP 元素是首圖之後，照顧它的順位就排第一：提供貼近顯示尺寸的壓縮檔、不對它做延遲載入，preload 或 fetchpriority 屬於視情況啟用的手段，不是預設答案；不存在一體適用的 100KB 門檻，也沒有人能保證 LCP 由紅轉黃。其餘圖片跟在後面，把格式轉換、延遲載入、響應式尺寸、快取與 CDN 逐項收攏，看成同一條上線路徑上的工項，而不是各自獨立的小技巧。

快取與 CDN 的角色也要放對位置。壓縮決定每一次下載傳多少，快取決定要下載幾次：瀏覽器快取標頭設得夠長，回訪者不必重新拉圖；CDN 把檔案放到離使用者近的節點，縮短每一次來回。這兩件事不做，壓縮的成果每個訪客都要重付一次，做起來，同一份壓好的圖能服務更多人。

失真壓縮會不會傷圖片搜尋：三個疑慮的邊界

直接回答：在肉眼驗收通過的範圍內做失真壓縮，看不出會反映在圖片搜尋上的傷害。搜尋引擎要的是能被理解、能快速載入、能對應查詢意圖的圖，不是原始解析度的母檔。真正會傷害圖片搜尋的，是幾件常與壓縮一起發生、卻經常被搞砸的事。

• 網址的穩定性。重新處理整批圖時，最容易出事的一步是另取新檔名，舊網址一變 404，圖片搜尋養出來的存量與別站連入的入口會同時歸零；非換不可，就為舊網址設 301 轉址，讓累積跟著搬過去。
• 命名的機會。壓縮前順手改檔名是成本最低的動作：相機預設的編號對搜尋沒有語意，換成描述內容的名稱，配上描述畫面的 alt 與所在段落的上下文，圖片被理解的材料才算湊齊。
• 詮釋資料的取捨。抹除 EXIF 帶走的隱私風險與體積，通常大於排名風險；攝影作品集這類拍攝資訊本身就是內容的站，保留屬於特例，不是通則。
• 出問題時的救援路徑。圖已被反覆壓壞時，救法不是再壓一次，是回到原始母檔重出，並指定唯一失真點；圖片 sitemap 屬於補充手段，不保證收錄，根本做法是讓重要圖片存在於可爬取的 HTML 裡。

語意理解與載入速度是兩件分開的事：壓縮顧速度這頭，檔名、alt、周圍文字顧理解那頭，兩頭都做才互補。描述側的完整做法，見圖片在搜尋裡被理解的整組做法。

五種求救訊號：症狀、成因與下一步

導入之後的求救訊號，多數有固定成因。對症走排查路徑，不要用「再壓一次」解決一切，那通常是把問題往更深處推。

1. 越壓越大。成因多半是拿早就壓過的檔再壓一次：能丟的細節先前已經丟光，壓縮器再硬丟，畫質退一階、體積卻幾乎不動；下一步是回到母檔處理，跳過那些來路不明的中間檔。
2. 邊緣出現光暈。整條鏈上多處失真的世代損失作祟，設計端、上傳外掛、快取外掛各貢獻一次；下一步是收斂到唯一失真點，已受傷的圖從母檔重出。
3. WebP 產了卻沒被用到。通常是伺服器 MIME 設定或 picture 標籤缺漏；下一步是打開 Network 面板，看瀏覽器實際抓下來的是哪種副檔名，補上缺的那一塊。
4. 行動版 LCP 一直卡紅。先確認 LCP 元素與請求的發現時間，再決定照顧順位；不要直接套 100KB 上限，也不要一律加高優先權，固定解法常常同時是錯誤解法。
5. 批次壓縮拖垮主機。批次是處理器密集的操作，幾千張一次跑會把小型主機壓滿；下一步是分批排程到低流量時段，或改用把運算放到雲端的外掛。

五個訊號有共同的潛臺詞：症狀出現的位置，很少是問題發生的位置。畫面上看到糊圖，源頭在流程裡多壓了兩次；分數上看到卡紅，源頭可能根本不是圖。排查的紀律是沿著資料流往上游走，找到發生點再修，而不是在下游反覆重做。

落地順序：量基準線、釘規格、挑一個位置跑一輪

讀完之後的第一步，不是打開任何工具，是把基準線量出來：首頁與圖最重的分類頁各跑一次測速，記下 LCP 與整頁傳輸量，Network 面板排序抄下最大的幾張圖。第二步把規格釘下來：長邊像素、品質級距、單張預算、母檔位置，四行字就夠，貼在團隊看得到的地方。第三步在決策樹上屬於你的分支裡挑一款工具，對既有圖庫跑一輪，回到測速對比前後數字。成果用整頁傳輸量、LCP 與肉眼驗收說話；搜尋排名與流量的變化受太多變數影響，不當成承諾。

這三步還有一個常被低估的副產品：文件化。基準線與規格落在文件上，下一個接手的人不必重學；前後對比的數字留在簡報裡，爭取資源時不必重講。圖片層面做到深處，差距從來不在誰的工具厲害，而在誰的流程可以被複製。

握有五百張商品圖的店家，三年後回頭看，當年選了哪個牌子早已無關緊要，留得下來的是一份誰接手都能照著走的規格。牌子會調價、會停更、會被收購，規格只會越修越準。工具是執行者，制度才是資產，這也是整篇把工具放進決策分支、不讓它排成清單開頭的原因。

若你的站在速度、圖片與技術性 SEO 之間牽扯不清，不知從哪裡查起，這正是 Whoops 平常協作的範圍：從一份基準線與一頁規格開始，把問題一層層拆開，都行。