為什麼要壓縮圖片（上傳之前就該做）

你的手機剛把一張照片存成 4 到 8 MB。對原圖歸檔來說，這個大小合理——1200 萬像素感測器、HDR 處理、JPEG 幾乎沒丟掉細節。但對你接下來要用這張照片做的幾乎所有事，這個大小都糟透了。

部落格主圖、商品卡、LINE 傳送、求職表單、寄給客戶的電子郵件：這些去處大多滿足於 100 到 400 KB。多出來的那幾 MB 不會讓螢幕上的畫面更好看。它們只會讓頁面更慢、傳送失敗、吃掉流量、備份帳單變厚。原圖和目的地真正需要的差距——就是為什麼要在上傳之前壓縮圖片。

網站為每一個用不上的 MB 買單

在網頁上，圖片通常是整頁最重的部分。Largest Contentful Paint（LCP）——追蹤主視覺何時真正出現的 Core Web Vital——往往就等於「那張主圖要下載多久？」一張 3 MB 的 JPEG 在 4G 上可以停好幾秒。同一裁切、200 KB 的 WebP 則眨眼出現。

LCP 慢不是抽象分數。首屏卡住，跳出率就會升。商品圖還在轉圈，轉換率就會掉。搜尋排名也會挨打，因為 Google 把這些指標當作排名訊號。發布前先壓縮，是最便宜的加速手段之一：你不用改網站，只是少傳一些位元組。

如果目的地是網頁，工夫就要具體——縮到顯示寬度、選現代格式、定一個仍然銳利的畫質。這條流程寫在如何縮小網站圖片檔案、讓頁面更快。底下的「為什麼」很簡單：未壓縮的上傳，是每個訪客每次載入都要交、永遠交下去的稅。

消費級電子郵件附件上限仍然大約 20–25 MB，整封信一起算。五張手機照片每張 6 MB，加上 PDF 之前就已經超標。傳送失敗、客戶收不到圖，或者 Gmail 悄悄把它們變成部分人打不開的雲端連結。事先壓縮，差別就是「圖在這裡」和之後一整串關於檔案太大的追問。

聊天應用嚴格的方式不同。LINE、iMessage 和大多數職場即時通訊會再壓你發出的內容——常常壓成有明顯瑕疵的小 JPEG——因為它們預設你沒做過。你失去畫質控制，同時仍然燒掉了原圖的上傳頻寬。自己壓到 250 KB 的檔案，第二輪通常更接近你想要的效果。

表單是同一問題的低調版本。大學入口、簽證網站、保險理賠、求職平台會寫硬上限：「JPG 或 PNG，最大 500 KB。」未壓縮的手機照片過不了驗證。人們接著截圖、在預覽裡縮到發糊，或者放棄。一次像樣的壓縮能過關，又不會把證件照變成一團朦。

同一批檔案還帶著一個你應該刻意做的選擇：有損壓縮與無損壓縮。照片扛得住有損編碼；截圖、標誌、帶文字的文件往往不該。壓縮不是一條滑桿——而是方法和檔案匹配。

一張 5 MB 圖在計量連線上不是小麻煩。它是每日流量上限裡明顯的一口、擁擠捷運上的停頓、飯店 Wi-Fi 上的逾時。用昂貴行動方案、偏鄉寬頻、舊裝置的人不是小眾——他們佔每個公開網站和每個群組很大一份。

無障礙也是同一幅圖的一部分。頁面載不完圖片，就等於有些人用不了。壓縮取代不了替代文字或對比，但它是少數直接決定內容到不到的效能選擇。送 200 KB 而不是 5 MB，差別就是「在手機上能用」和「只在都會區、有好方案的手機上能用」。

一張未壓縮的照片令人煩。一千張就是滿檔的 iCloud 或 Google 相簿。相機膠卷、客戶圖庫、「原圖應該留著」的資料夾，用沒有人會以原生解析度觀看的像素填滿硬碟和雲端配額。備份再把這些 MB 複製第二遍、第三遍。

成本不只是錢。同步更久。共用資料夾卡住。攝影師交出 400 張網頁用檔案，如果每張都是 6 MB JPEG，就是讓對方下載 2.4 GB，而其實可以只是 80 MB。到了這個規模，一張一張壓是錯工具——批次壓縮並下載 ZIP才是讓圖庫有用、而不是昂貴的方法。

粗略、典型的數字——不是實驗室基準，只是大多數人按「上傳」之前從不做的算術：

格式選擇也會改這些數字。一張照片的 PNG 往往比同一場景的 JPEG 大好幾倍；WebP 和 AVIF 對照片通常更小。如果你不確定頁面該用哪種容器，先看JPG vs PNG vs WebP vs AVIF，而不是去壓錯原檔。

你不需要再聽一套新流程講座。你需要檔案在離開這台電腦之前就對上目的地。保畫質的設定和短步驟，見如何壓縮圖片又不損失畫質。真正編碼就把檔案拖進圖片壓縮工具——在瀏覽器裡跑、什麼都不上傳，幾百 KB 通常已經夠。