上個月替我媽在手機上傳妹妹的報名時照片，頁面要求「一吋照，JPG，500KB 以內」，她拍完直接選中相簿裡那張——3024×4032，6.1MB，紅字提示刷了三次：檔案大小超出限制。我先在手機上裁了又裁，還是不行，最後拿到電腦上才想通問題在哪：我一直在調「裁切框」，可真正決定體積的是像素總數和編碼品質，不是顯示尺寸。那次之後我自己網站上所有配圖也順手過了一遍，首屏載入從 3.4 秒降到 1.9 秒。這篇就寫這兩件事的結論。
一、一張照片的體積由什麼決定
把「圖片太大」當成一個問題拆開來，其實是三層：
- 像素總數：4032×3024 是 1220 萬像素，1600×1200 是 192 萬，差了六倍多。這一層不動，後面壓得再狠也有限。
- 編碼與品質：同樣的像素，JPG 品質 95 和品質 75 可能差三到五倍體積；同一畫面存成 PNG 通常比 JPG 大得多，因為 PNG 的無損演算法不擅長處理照片那種連續漸層。
- 附加資料：EXIF、拍攝時間、相機型號、GPS 座標、內嵌縮圖，一張手機原圖裡這部分常有幾十到上百 KB，而且是最容易洩東西的地方。
我自己量過的參照值：手機直出的 JPG 照片 2–4MB；一張 1440×900 的桌面截圖存 PNG 約 1.1MB，同一張轉成 JPG 品質 80 只剩 180KB 上下；標準一吋照 295×413 像素，JPG 品質 85 通常在 40–70KB。所以我媽那張 6.1MB 的照片要落到 500KB，本來就不是「稍微壓一下」的量級。
二、先降尺寸，再調品質：順序反了就白折騰
常見錯誤是先拿一張 4000 像素寬的圖去壓品質，壓到 40% 才勉強過線，文字邊緣已經糊成一團；而正確做法是先按用途把長邊縮到需要的像素，再用中等品質收尾。我用的參考檔位：
| 用途 | 建議長邊 | 品質檔 | 經驗結果 |
|---|---|---|---|
| 報名/證件照上傳（295×413 一類） | 按平台像素要求 | JPG 80–90 | 幾十 KB，遠低於 500KB 限制 |
| 部落格配圖、商品詳情 | 1600–2000 | 75–85 | 150–350KB，肉眼看不出損失 |
| 首屏大圖 | 1200–1600 | 70–80 | 再配延遲載入，LCP 才壓得住 |
| 聊天記錄、文件截圖 | 保持原始像素 | PNG 無損或 WebP | 寧可無損，文字邊緣不能糊 |
| 發給客戶的產品圖 | 按對方要求 | 85–92 | 留原圖，另存一份壓縮版 |
那張 6.1MB 的照片，我最後是把長邊收到 1200、品質給到 82，出來 240KB，列印一張一吋的排版還夠用。整個過程裡起作用的是尺寸那一步，不是品質滑桿。
三、無損、有損，還有格式選擇
無損是重新組織資料的存法，像素一個都不改；有損是允許丟掉一些人眼不敏感的資訊。選擇取決於圖的內容，不是「哪個更高級」：
| 格式 | 透明 | 擅長 | 短板 |
|---|---|---|---|
| JPG | 不支援 | 照片、漸層、體積敏感的場景 | 文字邊緣出現色帶；反覆另存會累積損失 |
| PNG | 支援 | 截圖、圖示、線條圖、需要透明 | 照片類體積偏大 |
| WebP | 支援 | 網頁配圖，同等畫質體積更小，還能裝動畫 | 極老環境打不開，需留 JPG 備援 |
有損這一層還有個隱性代價：每次用有損格式重新儲存並匯出，都會再疊一次損失。所以我的習慣是原圖永遠留著，壓縮只產出副本，需要調整參數時從原圖重跑，而不是在壓縮結果上再壓一遍。
四、我實際的處理流程
- 先判斷是尺寸問題還是編碼問題：把圖放大到 100% 看細節，如果本來就是 4000 像素寬而頁面只顯示 800 像素寬，那答案在尺寸。
- 尺寸過大的先用圖片尺寸調整按像素或百分比縮，勾上鎖定寬高比，避免拉變形；這一步支援 PNG、JPG、WebP、GIF、BMP。
- 再進圖片壓縮批次處理：一次拖十幾張，品質在 10% 到 100% 之間調，頁面上直接對比壓縮前後的檔案大小和壓縮率，效果即時可見，我一般從 80 起往下試兩檔。
- 需要透明通道的 PNG 單獨看一遍，確認 Alpha 還在；截圖類優先無損檔。
- 匯出的副本按日期重新命名放回去，原圖不動。整套處理都在瀏覽器本機跑，圖不上傳伺服器——這一點對客戶素材和證件照很重要。
五、容易被忽略的細節
- GPS 跟著原圖走：iPhone 直出的照片 EXIF 裡常帶經緯度，微信「傳送原圖」也會一併傳出去。給人發證件照前，要嘛用截圖法重製，要嘛在匯出時去掉附加資訊。
- 平台的二次壓縮：微博、微信、部分電商後台會再壓一遍你的圖。已經壓得很低的圖被壓兩次，畫質是疊加變差的，傳上去反而更糊。
- 透明背景存 JPG 會變黑底或白底：JPG 不認 Alpha，壓之前先確認目標格式，或者鋪一層底色再匯出。
- HEIC 與 iOS 相簿：iPhone 預設存 HEIC，很多網頁表單只認 JPG/PNG，上傳前要先轉一次格式。
- 首屏效能帳：我自己站點上圖片佔了首屏資源的六成左右，LCP 判定的「良好」線是 2.5 秒以內。首屏那張大圖單獨優化，收益通常比壓縮下面二十張小圖更大。
- GIF 是體積大戶：幀數多的 GIF 靠壓縮品質救不了，先減尺寸或減幀才是正解。
六、常見疑問
Q：平台限制 500KB，是該降品質還是縮尺寸？
先縮尺寸。像素減一半，體積大約降到四分之一，畫質幾乎無感；單靠壓品質往往要壓到四五十才能過線，邊緣和皮膚會一起爛掉。
Q：壓縮會讓畫質明顯變差嗎？
無損不動像素，不會有變化；有損在 75 到 85 這個區間，對照片類內容通常肉眼分不出。要判斷就在 100% 縮放對比文字邊緣和髮絲，那兩處最先露餡。
Q：截圖發群組裡該用什麼格式？
PNG 或者 PNG 的無損壓縮。截圖裡全是硬邊文字和純色塊，有損壓縮會在字緣生出色帶，看著比原圖髒。
Q：WebP 會不會有人打不開？
近幾年的主流瀏覽器和系統都支援，網頁裡可以直接用。要發給不特定的外部人群，還是保留 JPG/PNG 更穩。
Q：批次的時候會不會把原圖覆蓋掉？
我的做法是原圖單獨放一個目錄、唯讀，壓縮結果輸出成副本再改名。任何帶「覆蓋原檔案」意思的操作都不該用在原片上。
回到開頭那張 6.1MB 的照片。它最後沒被壓到極限，只是收到 1200 像素、品質 82、240KB 就通過了審核——限制是給人看的，不是給畫質看的。真正需要記住的順序只有兩條：先看像素夠不夠用，再看格式和檔位對不對；剩下的都是可重複調的旋鈕。