工具
如何減少圖片檔案大小,讓網站跑得更快
笨重的圖片,正是網站感覺慢的頭號原因。一般商品頁或行銷頁會帶出 2 MB 多的重量, 其中大約一半都是圖片——還是以全解析度、全畫質、錯誤格式在傳輸。檔案一大, 最大內容繪製時間就會超出 2.5 秒目標,跳出率被推高,轉換默默流失——每一張 橫額圖多 100 KB,都會在手機與桌機兩邊都蝕掉可量度的互動。本季若只能做一次 效能 pass,選圖片就對了。
為甚麼笨重圖片會拖垮你的頁面
Google 的 Core Web Vitals 把頁面裡最大的圖片視為最大內容繪製(LCP)元素。 目前的「良好」門檻是 2.5 秒以下(以真實用戶第 75 百分位數計)。 HTTP Archive 顯示,桌面頁面中位數約 2.5 MB,手機頁面中位數 約 2.2 MB,而圖片幾乎都佔了 約 50% 的重量。 因此單單一張 1.2 MB 的橫額照片,就能決定你的 LCP 評分是綠、黃還是紅——而這 一切還沒輪到你精心寫的 JavaScript 跑起來。
商業面也一樣清楚。Google 自家研究顯示,行動載入時間每改善 1 秒,零售、 旅遊、潛客開發等網站的轉換率都會跟著提升。在不穩定的 4G 連線下,600 KB 的圖與 60 KB 的圖會被當成兩個截然不同的產品:前者會跳動著滑入,後者瞬間 載入。減少圖片大小,是現成最便宜的效能改善手段——沒有伺服器端重寫,沒有 架構變更,只是少寄一些本來就沒必要送的位元組。
4 步縮減流程
你不需要圖片優化服務或建置流水線。每個現代圖片 CDN 都在做的事,你可以 在瀏覽器內一張接一張地做,一分鐘以內搞定。請按以下順序執行,因為每一步 都依賴上一步的結果。
| 步驟 | 動作 | 常見節省幅度 |
|---|---|---|
| 1. 縮到顯示尺寸 | 把點陣圖縮到版面實際渲染的最大尺寸。一張 4000×3000 的照片餵進 1200×600 的位置,超過 90% 的像素根本是多餘。 | 60–80% |
| 2. 畫質設到約 75–80 | 把編碼器畫質滑桿拖到大約 75–80(針對照片)。正常觀看距離下視覺差 別幾乎看不出來,位元組節省卻非常戲劇性。 | 30–50% |
| 3. 轉成 WebP | 把縮好尺寸、重設過量化的點陣圖再編為 WebP。同尺寸、同畫質下, 通常只佔原 JPG 或 PNG 的三分之一位元組。 | 25–35% |
| 4. 清除中繼資料 | 移除 EXIF、IPTC、XMP、色彩描述檔與作者備註。一張手機照可以帶 上 50–100 KB 瀏覽器根本不會渲染的中繼資料。 | 2–10% |
四個步驟疊起來,常規可以把一張 1.2 MB 的原圖壓到 150 KB 以下, 在一般網頁尺寸下完全看不見品質損失。
逐個格式的指引
不同的視覺工作需要不同格式。請按內容選擇,不要照反射動作選。
- 照片。JPG 設在畫質 75–80,或同等畫質 的 WebP。AVIF 還能再進一步,但編碼時間較長,且在少數舊裝置上不支援—— 若相容性重要,改用 WebP。
- 標誌、圖示、UI 圖像。保留透明度請用 PNG, 或更好——帶 Alpha 通道的 WebP。如果來源是向量,SVG 還更小,而且能無限縮放 不帶點陣瑕疵。
- 插畫與平面美術。WebP 或 PNG。WebP 贏在 位元組數,PNG 贏在無所不在的支援。如果兩個都要,就用 picture 元素生一份 WebP, 再準備 PNG 當後備。
需要把一整批舊素材從某個格式切到另一個?圖片轉檔工具能一次把 JPG、PNG、WebP 與 AVIF 批次重新編碼,並提供並列預覽, 讓你在按下確認前先看見品質取捨。
訂立預算
沒有預算的優化,只是把圖稍微變小。給頁面上每個類別一個硬性的位元組上限, 在 CI 中強制執行,頁面平均重量就會應聲塌下。一個以內容為主導的網站, 合理的起步預算:
- 橫額圖:100 KB 以下。這是你的 LCP 元素, 再重一點就是在用 Core Web Vitals 付帳。
- 畫廊縮圖:每張 50 KB 以下。乘以首屏可見的 縮圖數量,就是一個站得住腳的預算。
- Open Graph 圖:200 KB 以下。爬蟲與社群 預覽會反覆重抓這張,設個緊的上限能讓連結展開維持俐落。
- 首屏總圖片:300 KB 以下。超過這個數字, 再多的 code-splitting 都救不回 LCP 分數。
跑一次四步流程,把輸出貼進上面的預算,再上線。頁面更快、Core Web Vitals 更好、 訪客更滿意——而你少送的每一位元組,都是你不必付出傳輸成本的。