15 款圖片壓縮工具實測推薦：網站圖片不失真

圖片壓縮是網站速度裡最被低估的一環

「主機升級了、快取外掛裝了、CDN 也接了，PageSpeed 分數卻還是卡在黃色。」圖片常是值得先查的瓶頸，但不能先假設九成問題都出在圖片。打開 Network 與 Lighthouse，確認首圖、商品圖、字型、JavaScript 與伺服器回應各占多少，再決定優先順序。

圖片經常是網頁中占用位元組較多的資源，但占比會隨網站類型而變，不能一概說一定超過一半。WordPress 目前驅動全球超過四成的網站（依 W3Techs 至 2026 年 6 月的統計），上傳前檢查解析度、格式與檔案大小，能避免把不必要的位元組交給瀏覽器。

Google 在 web.dev 的 Why does speed matter?（2026 年）寫得很直白：網頁載入每多一秒，使用者的離開機率就會往上跳。而行動裝置已經佔全球網路流量的六成上下（依 Statista 2026 年 4 月的季資料），Google 也早在 2023 年底就完成了行動優先索引的全面部署，見當年 10 月的 Mobile-first indexing is here 官方公告。這幾件事串起來，結論只有一句：你的網站是用手機、用 4G、用不耐煩的手指在看的，而圖片是你最能直接控制的那塊重量。

先講結論：圖片壓縮從來不是單一個動作，它是一條從來源、設計、匯出、上傳到伺服器回應的整條鏈。挑工具之前，先決定你在哪一環發力：在來源端用桌機工具預先壓好、在 CMS 上傳時讓外掛自動壓、或在部署管線用命令列跑批次。接下來把 15 款工具分成「桌機與設計師」「命令列與自動化」「線上服務」「WordPress 外掛」四個工作流，附上選擇方法、實測邏輯、踩坑清單與三步行動方案。

這篇不是那種列十五個名字就收工的清單文。既然你會認真挑一到兩款長期用下去，所以重點會放在「怎麼挑」這件事上，「全部都裝」就免了。如果你經營的是 WordPress 站，部分工具會直接導向該看的深度教學，避免你在這裡讀完又重複踩坑。

壓縮到底在壓什麼：失真、無失真，與再壓一次的陷阱

工具清單之前，先把三個名詞弄清楚，你才看得懂每一款工具在講什麼。這一段是接到圖片優化求救時，最值得先花十分鐘解釋的東西。

無失真壓縮（lossless）只重新編碼資料、移除多餘的詮釋資料（EXIF、GPS、相機型號、縮圖），像素一個不變，壓完的圖放在原圖旁邊肉眼完全分不出來，檔案卻可能小 5% 到 30%。它安全、可逆，但壓縮率有天花板，對已經很肥的 JPEG 幫助有限。

失真壓縮（lossy）會丟掉人眼不敏感的高頻細節，換來大幅度縮小。一張 3MB 的商品圖，失真壓縮壓到 400KB，肉眼幾乎看不出差異，這才是網站圖片能「飛快載入」的關鍵。風險在於壓過頭會出現塊狀雜訊、色彩斷層、文字邊緣暈開，這些統稱壓縮瑕疵（compression artifacts）。

再壓一次的陷阱常發生在 JPEG，以及採失真模式輸出的 WebP 或 AVIF；WebP 本身同時支援失真與無失真。對已失真圖片反覆重新編碼，瑕疵可能累積，檔案也不一定更小。較穩的做法是保留原始母檔，明確指定整條流程只有一處負責最終失真編碼。

要判斷壓縮有沒有「壓過頭」，不用專業軟體，三個肉眼檢查點就夠用。第一，把圖放大到 200%，看平坦色塊（例如天空、白牆、純色背景）有沒有出現一格一格的塊狀雜訊，這是失真壓縮最先露餡的地方。第二，看銳利邊緣（文字、商品輪廓、樹枝）有沒有出現類似鬼影的暈開或彩色邊緣，這叫振鈴瑕疵，代表壓縮率設太兇。第三，漸層色（例如夕陽、皮膚）有沒有出現一條條明顯的色階斷層，本來應該平滑過渡的顏色變成一圈一圈。任何一個檢查點看到明顯瑕疵，就把品質往上調一級重壓。這套檢查法搭配接下來那組測試圖，你就有了一套不用靠感覺的驗收標準。

類型	原理	壓縮率	畫質損失	適用場景
無失真	重新編碼、去詮釋資料	低到中（5%–30%）	零	截圖、含文字的圖、PNG 圖示
失真	丟棄高頻細節	高（常達 60%–85%）	有，可控制	商品圖、首圖、背景照片
再次失真壓縮	對已失真的圖再壓一次	視情況	累加、不可逆	應避免

還有一個觀念叫「壓縮不是萬能」。如果一張圖的解析度遠超過它在頁面上的顯示尺寸（例如手機上只顯示 375px 寬，你卻上傳 4000px 的原圖），再怎麼壓縮都是浪費。先確認顯示尺寸，再選格式與壓縮設定，才能避免傳送多餘像素。格式的選擇，站上另有一篇完整的比較，建議搭配著看：WebP、JPG、PNG 圖片格式深度比較。

怎麼挑工具：一套可以重現的實測方法

網路上很多「圖片壓縮工具推薦」的文章，共同的問題是沒有講清楚作者是怎麼測的。檔案大小是唯一指標嗎？畫質怎麼評？同一張圖交給不同工具，結果可以差到兩三倍。這裡用的是同一套固定流程，讓每次比較都可重現、可驗證，而不是憑感覺給分。

1. 準備一組固定測試圖：一張高細節照片（例如市集攤商）、一張含銳利文字的圖（例如定價卡）、一張大面積漸層的圖（例如夕陽天空）、一張螢幕截圖。這四種涵蓋了壓縮器最容易被看出瑕疵的典型，任何人想重現這些結論，拿同類型的圖跑一遍就會得到近似的結果。
2. 設定同一個目標：實務上通常設兩組目標，一組是「檔案壓到原圖的 25%」，看畫質掉多少；另一組是「肉眼可接受的最高壓縮」，看檔案能多小。固定目標才能橫向比較。
3. 同時看三個指標：輸出檔案大小、肉眼比較（放大 200% 看邊緣與平坦色塊）、以及是否保留或移除詮釋資料。不能只信單一數字。
4. 記錄預設值而非極端值：每款工具都能調到很猛的壓縮率，但預設值才是大多數人會用的。評的是「安裝完直接執行」的結果，不是調半天調出來的最佳值。

這套方法不完美，但它把「這款看起來比較好」變成「在同一組圖、同一個目標下，這款輸出 320KB、那款輸出 410KB」。下面每一段推薦，背後都是這個流程跑出來的。你要驗證任何一款，照著這四步做一遍就好。

給你一個具體範例，方便理解這套方法跑起來長什麼樣。這張表是用「高細節市集照片」這一張測試圖（原檔 JPEG、4MB 出頭），丟進幾款代表性工具的預設值得到的結果，目標設在「肉眼可接受、不放在一起比對就看不出差異」。數字會因為你用的圖不同而不同，所以請把這張表當成「方法示範」，別把它當絕對排名。

工具	模式	輸出大小	縮小幅度	肉眼觀察
原圖（基準）	未重新編碼	約 4.1MB	基準	基準
ImageOptim（無失真）	去詮釋資料	約 3.9MB	5%	無差異
TinyPNG（預設）	智慧失真	約 1.1MB	73%	攤位布條邊緣略柔化
Squoosh（MozJPEG q=80）	失真	約 780KB	81%	幾乎無感
Squoosh（WebP q=80）	失真、現代格式	約 560KB	86%	幾乎無感

這張表只能示範比較方法，不能推廣成所有圖片的固定排名。無失真壓縮對既有 JPEG 通常空間有限；照片可測試較合理的失真品質與 WebP／AVIF，再用自己的素材比較檔案大小與視覺瑕疵。格式、編碼器、品質參數與圖片內容都會影響結果。

也要誠實說：壓縮結果會隨圖片內容變動很大。細節豐富的照片壓縮率通常較低，大面積平色的圖可以壓得很兇。所以別迷信「某款工具壓縮率 80%」這種單一數字，用自己的實際圖庫跑一次抽樣，那才是你真實會得到的結果。

桌機與設計師工作流：從來源就把圖壓好

這條路的好處，是它在「圖進到網站之前」就搞定。設計師或內容製作者在自己電腦上把圖壓好、縮好、取好檔名，再交給網站，下游什麼都不用做。對講究控制度的團隊來說，這是最乾淨的架構。

1. ImageOptim（macOS 必裝）

Mac 使用者的第一選擇，開源、免費、拖拖拉拉就能用。把圖片丟進視窗，它會自動套用一組無失真與可選失真的壓縮器（背後是 Zopfli、MozJPEG、pngcrush、OxiPNG 等），同時抹掉所有詮釋資料。實務上習慣把它設成「壓完直接覆蓋原檔」的無腦模式，設計交稿前每張圖都過一次。它的失真選項在有損模式下可以再榨出 20% 左右的空間，但會破壞畫質，所以建議只對照片開、對含文字的 PNG 保持關閉。

2. FileOptimizer（Windows 對應選擇）

Windows 上的對應選擇，同樣免費。它的設計哲學是「把幾十種壓縮引擎串在一起，一次全部跑一遍，取最小的結果」，支援的格式非常廣，從 JPEG、PNG、GIF 到 PDF、SVG、甚至 Office 文件都能壓。預設會覆蓋原檔，所以一定要先備份。它的介面比 ImageOptim 冷門一點，設定也比較多，但對 Windows 工程師來說，一次部署就能壓整個資料夾，是它的強項。

如果你是設計師，這裡順帶提一個更上游的習慣：在設計階段就用對的尺寸與格式匯出，比事後壓縮更有效。設計工具的匯出設定通常能直接指定倍率與格式，1x、2x 的資產在交稿時就標好；而圖片來源如果走免費圖庫，很多來源本身就提供已經壓好的 WebP 版本，下載時選對格式就省了一道工。把源頭顧好，下游的壓縮工具只需要做收尾。

命令列與自動化：給工程師的硬派路線

如果你的網站是靜態站、Headless CMS、或任何有部署管線的架構，命令列工具才是正解。它可以把壓縮寫進 CI/CD，每次建置自動跑、零人工。以靜態站為例，常見的做法是這樣：圖片進版控之前，CI 自動壓過一遍，不存在「有人忘了壓」這種事。

3. jpegoptim（JPEG 必裝）

老牌的 JPEG 壓縮器，幾乎每條 Linux 發行版的套件庫都有。它最大的優點是「可以設最大檔案大小上限」，例如 jpegoptim --max=300k *.jpg 會把每張圖壓到 300KB 以內，對需要統一商品圖大小的電商極度實用。它同時支援無失真（只去詮釋資料）與失真模式，一行指令搞定。

4. optipng 加 pngquant（PNG 雙刀流）

PNG 工具要先分無損與有損。optipng 會以無損方式重建檔案；pngquant 則把影像轉為最多 256 色的色盤，通常能進一步縮小檔案，但可能出現色階、透明邊緣或品牌色偏差。是否先跑 pngquant 再跑 optipng，要用代表性素材比較檔案大小與畫質，沒有適用所有 Logo、icon 與插圖的固定最佳組合。

5. cwebp（搭配 cavif 認識 AVIF）

當你決定改用現代格式，cwebp 是 WebP 專案提供的編碼工具，cavif 則來自 libavif 工具鏈。不同格式的檔案大小取決於內容、編碼器與品質目標，不能保證固定省下 25% 到 35%。現代瀏覽器已廣泛支援 WebP 與 AVIF；若仍需照顧不支援的環境，可用 <picture> 提供回退格式。

6. sharp（Node.js 管線之王）

在 Node.js 裡，sharp 是常見的圖片處理程式庫之一，底層使用 libvips，可在 pipeline 裡完成縮放、裁切、格式轉換與壓縮。部分框架預設或建議使用 sharp，但實際實作與版本可能不同，不宜寫成整個生態唯一選擇。

命令列的進入門檻較高，但寫進管線後，就不必依賴人工記得壓圖。若要維持可重現性，還要固定工具版本、參數與原始檔保存方式；自動化能降低差異，不能在未鎖版本時保證多年後輸出完全一致。

線上壓縮服務：貼上去就能用的快速解

不是每個人都需要長期方案。有時候你只是手上有十張圖、想馬上壓一壓寄出去，不想安裝任何東西。線上服務就是為這種一次性需求存在的。它的代價是：你要把圖傳到別人伺服器，所以任何含敏感資訊、客戶個資、未公開產品照的圖，都不該走這條路。

7. Squoosh（Google 出品，教學級示範）

Google 瀏覽器團隊做的網頁 App，也是把「壓縮在做什麼」解釋給人聽時，最常用的活教材。它的介面左右分割，可以即時拉動滑桿比較壓縮前後，並標示出肉眼分不出差異的範圍。支援 JPEG、WebP、AVIF、PNG、MozJPEG 等多種編碼器，所有運算都在瀏覽器裡用 WebAssembly 跑，圖片不會上傳，隱私上最安全。它同時提供命令列版（Squoosh CLI），可以搬到 CI 裡。

8. TinyPNG（最廣為人知的代名詞）

很多人聽到「線上壓圖」直覺想到的就是它。它用的是智慧型失真壓縮，把 PNG 的顏色數量降到 8 位元色盤、對 JPEG 做 MozJPEG 等級的重新編碼，壓縮率很猛，介面也最簡單：拖進去、下載。免費版單次 20 張、每張 5MB 上限。它的 API 與 WordPress 外掛也很多人用，等於同一條壓縮技術涵蓋了線上、API、CMS 三種使用方式。

9. Compressor.io（SVG 與多格式見長）

支援 JPEG、PNG、GIF、SVG、WebP，提供失真與無失真兩種模式，介面清爽，壓完可以直接存到 Google Drive 或 Dropbox。它的強項是格式支援廣，尤其 SVG 這種很多工具不處理的格式，它在行。弱點是免費版有廣告、批次量有限。

10. Optimizilla（可調式批次壓縮）

它的差異化在於「可調式批次壓縮」。上傳多張圖後，介面給你一個品質滑桿，能逐張預覽並微調，右側即時顯示壓縮前後的檔案大小與畫質。對需要「這張壓兇一點、那張保留多一點」的人很友善。只支援 JPEG 與 PNG，沒有 WebP 與 AVIF，是它的限制。

11. Ezgif（GIF 與動態圖的救星）

當 GIF 動圖太大時，Ezgif 可用來縮尺寸、降幀率、調整色盤，或轉成 MP4、WebM。影片格式在許多動態內容上能以較小檔案提供較好畫質，但相容性、無限循環、透明度與嵌入方式仍要逐案確認。

12. FreeConvert（多格式轉檔兼壓縮）

定位上比較像「萬用轉檔器」，順便做壓縮。它支援 AVIF、HEIC 這些比較新的格式互轉，例如把 iPhone 拍的 HEIC 批次轉成 WebP。如果你手上的圖來源很雜（手機原檔、相機 RAW、各種奇怪格式），它是一個統一處理的入口。免費版有檔案大小與批次限制。

WordPress 站長專區：上傳之後自動壓

WordPress 外掛可以接管上傳壓縮與現代格式產生，但功能、額度與前台輸出方式依外掛和方案不同；WordPress 核心本身也會產生 responsive image 標記。設定後仍要定期檢查新上傳圖片與實際前台格式。可從WordPress 外掛推薦清單把圖片優化放進整體規劃。

13. Smush（新手首選）

WordPress 上歷史最久、安裝數最多的圖片優化外掛之一。免費版能做無失真壓縮、移除詮釋資料、批次壓縮媒體庫裡的舊圖，付費版再加上失真壓縮與 WebP 轉換。它的強項是介面乾淨、設定直覺，對新手最友善。站上另有從安裝到延遲載入的完整教學，想用 Smush 的人直接看Smush 外掛安裝設定與延遲載入教學，比在這裡零碎講更清楚。

14. ShortPixel（電商與攝影類的偏好）

這類服務常以圖片或點數計費，免費額度、訂閱與一次性點數方案可能調整，採用前要查看當期定價與每張圖的計數方式。ShortPixel 提供不同壓縮模式，以及 WebP、AVIF 等輸出選項；人物膚色、商品材質、lazy load 與尺寸屬性仍應用測試站確認，不要只看功能清單。

15. Imagify（WP Rocket 陣營的最無痛搭配）

同樣是老牌的圖片優化外掛，背後是 WP Rocket 同一個團隊。它的三段式壓縮等級（一般、積極、超級）對應不同程度的失真，讓站長依頁面類型調整，例如商品頁用「一般」、部落格首圖用「積極」。免費額度每月 25MB，付費方案以 MB 計費。它與 WP Rocket 的整合最深，如果你本來就用 WP Rocket 做快取，Imagify 是最順手的搭配。

還有兩款常被問到、但沒進入 15 款主清單的：EWWW Image Optimizer 與 Optimole。EWWW 的特色是可選擇用自己的伺服器跑（無需把圖傳到外部），對隱私要求高的站是優點；Optimole 則是純雲端方案，圖片上傳後由它的伺服器即時依使用者裝置生成最佳尺寸與格式，等於把整個 responsive image 工作交給它。兩者的取捨在於要不要把圖交給第三方，這是一個隱私與便利性的權衡，沒有絕對答案。

選 WordPress 外掛時，建議只挑一款裝，不要同時開兩套圖片壓縮外掛。除了前面講的「再壓一次」風險，兩套外掛還會爭奪 WebP 產生與檔案命名規則，造成圖片連結錯亂。先把圖片上架流程做對（正確的 alt 文字、尺寸屬性、顯示尺寸），壓縮外掛才有意義。

15 款工具總覽對照表

散在四個工作流裡看可能還是有點散，這裡用一張表把 15 款工具的定位、所屬類型、平台、壓縮模式與最適合的使用者集中起來，方便你對號入座。

#	工具	類型	平台	壓縮模式	最適合誰
1	ImageOptim	桌機	macOS	無失真為主、可選失真	Mac 設計師、內容製作
2	FileOptimizer	桌機	Windows	多引擎串聯	Windows 工程師、批次處理
3	jpegoptim	命令列	跨平台	失真／無失真	需要設檔案大小上限的人
4	optipng + pngquant	命令列	跨平台	無失真 + 失真色盤	Logo、圖示、插圖的 PNG
5	cwebp / cavif	命令列	跨平台	失真（現代格式）	想輸出 WebP／AVIF 的工程師
6	sharp	程式庫／CLI	Node.js	全功能 pipeline	靜態站、Headless 架構
7	Squoosh	線上 + CLI	瀏覽器	多編碼器可選	想視覺化比較、隱私敏感
8	TinyPNG	線上 + API	瀏覽器	智慧失真	一次性快速壓縮
9	Compressor.io	線上	瀏覽器	失真／無失真	需要 SVG 壓縮的人
10	Optimizilla	線上	瀏覽器	可調式批次	想逐張微調品質的人
11	Ezgif	線上	瀏覽器	失真、含降幀	GIF 與動態圖處理
12	FreeConvert	線上	瀏覽器	多格式轉檔	HEIC／AVIF 等雜格式來源
13	Smush	WP 外掛	WordPress	無失真為主、付費失真	新手站長、設定一次就好
14	ShortPixel	WP 外掛	WordPress	無失真／光澤／失真	重視膚色與商品質感的電商
15	Imagify	WP 外掛	WordPress	三段式失真等級	已用 WP Rocket 的站

怎麼選：依角色給一條最少阻力路線

15 款看下來反而難選，所以這裡把「怎麼推薦」濃縮成四條最少阻力路線，直接對到你最可能的身份。這不是唯一解，而是把「重來一次會怎麼做」講清楚。

你的身份	第一選擇	備案	理由
設計師／內容製作	ImageOptim（Mac）或 FileOptimizer（Win）	Squoosh 做視覺比較	在交稿前壓好，下游零負擔
前端工程師／DevOps	sharp 加 cwebp 寫進 CI	jpegoptim、pngquant 補腳	自動化、可重現、三年後仍一致
WordPress 站長	Smush 或 ShortPixel 擇一	Imagify（搭配 WP Rocket）	設定一次終身有效，只裝一款
一次性需求	Squoosh 或 TinyPNG	Ezgif（GIF 專用）	免安裝、隱私可接受時最快

這四條路還有一個共同前提：你的圖片來源要先對。再好的壓縮也救不了構圖糟糕、解析度不足、或光線惡劣的照片。也因此要反覆強調，圖片優化是一條鏈，工具只是其中一環。

壓完之後還能做什麼：格式、延遲載入、尺寸與快取

壓縮是基礎，但只壓縮不會讓你拿滿分。接下來這幾件事與壓縮是乘法關係，少做一樣，前面的努力都會被打折。

優先順序要看量測結果。若 LCP 元素是首圖，就先提供符合顯示尺寸的壓縮檔、避免對它延遲載入，並視情況使用 preload 或 fetchpriority；沒有通用的 100KB 門檻，也不能保證把 LCP 從紅轉黃。其餘圖片再處理尺寸、格式、延遲載入、快取與 CDN。

換格式。把 JPEG 與 PNG 升級到 WebP，是當前投報比最高的下一步，相同畫質再省 25% 到 35%。AVIF 更省，但編碼慢、相容性還沒全面。格式的完整比較與 <picture> 寫法，可以搭配站上的格式深度解析一起看。

延遲載入。首屏看不到的圖片，瀏覽器不要急著下載。原生 loading="lazy" 加一個屬性就能做，效果立竿見影，特別是長文與商品列表頁。完整做法與陷阱，看Lazy Loading 延遲載入實戰指南。

正確的尺寸標記。用 srcset 與 sizes 讓瀏覽器依螢幕寬度挑圖，手機就不會下載桌機用的大圖。這與響應式設計是一體兩面，觀念在響應式網頁設計 RWD裡有完整說明。

快取與 CDN。圖片壓好之後，透過 CDN 把它推到離使用者最近的節點，能再砍掉可觀的往返時間；伺服器端的快取與瀏覽器快取標頭則決定回訪者的載入速度。這兩件事都在網站速度的實戰拆解裡展開。

對應到 Core Web Vitals。大型 LCP 圖片可能拖慢 LCP，未保留尺寸的圖片可能造成 CLS；圖片解碼也可能占用主執行緒，但 INP 仍要用效能分析確認實際長任務來源。詳見Core Web Vitals 完全攻略。

圖片壓縮與 Image SEO：壓縮會不會傷害搜尋排名

這是最常被問的一個問題：「把圖壓得這麼小，Google 圖片搜尋會不會覺得圖變差、就不排了？」這個擔心很自然，但結論可以讓你放心：在合理範圍內的失真壓縮，對圖片搜尋排名沒有可觀察的負面影響。Google 在圖片搜尋要的是「能正確理解內容、能快速載入、能對應使用者查詢」的圖，並不需要原始幾 MB 的高解析檔。

真正會傷害圖片 SEO 的，是這幾件與壓縮無關、卻常被一起搞砸的事。把這些顧好，壓縮才能放心做。

• 檔名要有意義。IMG_20260712_0042.jpg 對 Google 沒有任何語意，stainless-steel-milk-pot-16cm.jpg 才有。壓縮前順手把檔名改好，是成本最低、效益最高的圖片 SEO 動作。
• alt 文字要描述圖片。alt 不是用來塞關鍵字的欄位，它是告訴搜尋引擎與螢幕閱讀器「這張圖在演什麼」的捷徑。商品圖就寫商品名稱與關鍵特徵，截圖就寫截圖內容。
• 圖片周圍的文字。Google 判讀圖片內容時，會參考它的標題、標題文字、所在段落的上下文。一張被放在相關段落裡的圖，遠比孤零零插在版面上的圖容易被正確歸類。
• 別在換圖時換網址。重新壓縮整批圖時，最致命的錯是產生新檔名、讓舊網址 404。這會同時打掉圖片搜尋的累積與外部連入的流量。正確做法是覆蓋原檔、網址不動；非得換網址時，要為舊圖網址設 301 轉址。
• 評估圖片 sitemap。圖片 sitemap 可補充 Google 可能無法以一般爬取方式發現的圖片網址，但不保證收錄。更根本的做法仍是讓重要圖片出現在可爬取的 HTML 與有效網址中。

這裡也要破除一個迷思：把 EXIF 與詮釋資料全部抹掉，會不會傷害圖片搜尋？長期來看，對絕大多數網站來說答案是「不會」。EXIF 裡的拍攝資訊對內容意義的判讀幫助有限，而抹掉它能省下的體積與隱私風險（GPS 座標、設備序號）反而更值得。少數攝影作品集、地景紀錄類網站可能想保留拍攝地點資訊，那就在工具裡把詮釋資料保留選項打開，這屬於特例，不是通則。

換句話說，圖片 SEO 的主力從來不是「壓不壓縮」，而是「Google 知不知道這張圖在演什麼」。壓縮顧的是載入速度與 Core Web Vitals，描述性資料顧的是語意理解，兩件事是分開的。把壓縮做確實、把描述性資料填好，你兩頭都贏。語意理解這一側的完整做法，可再對照從檔名到結構化標記的圖片 SEO 完整攻略。

常見踩坑與排查清單

工具會用，不等於不會踩坑。這段是圖片優化專案裡最常見的五種「怪現象」，以及對應的排查思路。每個都附上常見的情境。

1. 壓完反而變大。對已經很小或已經高度壓縮的圖再做失真壓縮，輸出有時比原檔還大，因為壓縮器硬要破壞已經沒得破壞的資料。排查：先檢查原圖是不是早就被壓過（檔案大小相對於解析度異常小就是訊號），這類圖直接跳過、別再壓。
2. 商品圖邊緣出現光暈。這是「再壓一次」的典型後遺症，同一張 JPEG 被設計師、上傳外掛、快取外掛各壓一次。排查：在整條鏈裡只允許一處做失真壓縮，其餘改無失真或關閉；已損壞的圖只能從原始檔重新壓一次。
3. WebP 產了卻沒被使用。很多外掛會產 WebP，但前台仍載入 JPG，因為伺服器沒設正確的 MIME 或 <picture> 標籤沒寫。排查：用瀏覽器開發者工具看 Network，確認實際下載的副檔名；必要時手動補 <picture> 與 <source>。
4. 行動版 LCP 一直紅。先用 Lighthouse 或效能面板確認 LCP 元素；若是首圖，再查解析度、請求發現時間、延遲載入、優先順序與伺服器回應。不要套用 100KB 或一律加 fetchpriority="high" 的固定解法。
5. 壓縮外掛把整個媒體庫從頭跑一遍，站點卡住。批次壓縮是 CPU 密集操作，幾千張圖一次跑會把小型主機拖垮。排查：分批跑、或排程在低流量時段；雲端型外掛把運算丟出去，是避開這個問題的方法。

大量既有圖片的共同難題，是來源與壓縮紀錄不一致，而且新圖仍持續加入。比較穩的做法是依版位建立尺寸、格式、視覺品質與檔案預算，先用代表性圖片測試，再讓設計端與 CMS 共用同一規格；不要把 1600px、品質 80 或 350KB 當成所有電商都適用的門檻。

換個方式想：對一個五百張商品圖的電商來說，真正難被取代的從來不是某款壓縮工具的品牌，而是「無論誰來接手營運，圖片規格都不會走山」這個制度。工具可以換，規格不能亂。

從今天開始的三步行動方案

讀完十五款工具，真正重要的是你明天會做什麼。這裡把它收斂成一個不論你用哪條路線都適用的三步方案。

第一步：抓基準線。先用網站速度測試工具跑一次首頁與一個圖片最重的分類頁，記下 LCP 與整頁重量，並打開瀏覽器開發者工具的 Network 面板，排序看最大的幾張圖各是多少 KB。沒有基準線，後面一切優化都是憑感覺。

第二步：釘死一條規格。不論你站上是設計師、工程師還是站長自己，寫下一段「進站前規格」：長邊幾像素、用什麼格式、品質設多少、單張上限多少 KB。把這段規格貼在團隊都看得到的地方，從此新圖一律照規格走。這一步的效果遠大於挑哪一款工具。

第三步：依角色挑一款工具，只裝一款。對照前面那張角色表，挑一款、設定好、跑一輪既存媒體庫的批次壓縮，再回去重跑速度測試，比較前後的 LCP 與整頁重量。把這組前後數字留下來，它會是你接下來說服老闆、客戶、或自己繼續投資效能的最佳證據。

圖片優化的成果應以整頁傳輸量、LCP、視覺品質與轉換資料驗證，不是 Google 更新後的必然排名回報。把規格、母檔與編碼流程固定下來，後續才容易維護。

如果你看完整篇，發現自己的站同時有速度、圖片、技術性 SEO 多個層面要處理，不知從何下手，這正是我們 Whoops SEO 平常在做的事。可以把這篇當起點；真要找人一起拆解速度與圖片優化，Whoops 隨時能聊。