WebP 無損相較於 PNG 實際能為你省下什麼

簡短版

在相同像素下，WebP 無損通常比 PNG 更小。這就是人們使用它的實際原因。

但「通常」這個詞很重要。WebP 無損不是每個 PNG 的神奇替代品。它往往在具有透明度、螢幕截圖、UI 擷取，以及圖形與照片混合內容的圖片上省得最多。對於非常小的素材、高度最佳化的調色盤 PNG，以及簡單圖示，它可能省得很少，偶爾甚至會變大。

如果你正在最佳化一個真實網站，正確的問題不是「WebP 是否比 PNG 更好？」而是：「我的哪些 PNG 轉成 WebP 無損後能明顯變小，而且不會造成相容性或工作流程問題？」

這是一個更聚焦的問題，也更容易回答。

這裡的「無損」是什麼意思

無損表示解碼後的像素會與來源像素完全一致。如果一張 PNG 轉換為 WebP 無損後再解碼，圖片像素應該相同。

它不表示檔案本身相同。後設資料、色彩描述檔處理、PNG 輔助區塊、gamma 資訊、時間戳記，以及工具特定的區塊，都可能依你的轉換流程而改變、被移除，或以不同方式表示。

如果你處理的是典藏圖片、印刷工作流程、科學影像、法律證據，或任何檔案容器承載重要非像素資訊的情境，這個差異就很重要。對一般網頁傳遞而言，大多數團隊主要在意的是視覺像素、透明度、尺寸與色彩一致性。

如果你發布使用者提供的圖片，後設資料也是隱私問題。我們在 如何在網路分享照片前移除 EXIF 後設資料 中討論過這個更廣泛的主題，但同樣原則也適用於這裡：圖片最佳化應該明確說明它保留什麼、移除什麼。

為什麼 PNG 壓縮效果好，以及它在哪裡到達極限

PNG 是一個非常好的格式。它成為網頁預設選擇有充分理由：

• 它是無損的。
• 它支援 alpha 透明度。
• 它受到廣泛支援。
• 它可預期，而且容易處理。
• 它非常適合扁平圖形、螢幕截圖、標誌與 UI 素材。

PNG 壓縮的做法是先過濾圖片列，再套用 DEFLATE 壓縮。這個組合很有效，尤其在相鄰像素相似時。

問題不是 PNG 不好。問題是 PNG 已經很老。相較於較新的格式，它的壓縮模型可用技巧較少。即使你已經用良好的編碼器最佳化 PNG，仍可能留下原本可以省下的位元組，因為格式本身無法像 WebP 無損那樣有效表示某些模式。

這就是 WebP 無損登場的地方。

WebP 無損有什麼不同

WebP 無損使用的是專為圖片設計的壓縮系統，而不是把通用壓縮層附加到已過濾的列上。在底層，它可以使用預測編碼、色彩轉換、調色盤、向後參照與熵編碼等技術，緊湊地表示重複或可預測的像素模式。

你不需要背下實作細節。有用的心智模型是：

PNG 擅長壓縮列。WebP 無損有更多方式描述圖片結構。

這種額外的彈性，就是 WebP 無損經常能從相同來源圖片產生更小檔案的原因。

Google 過去曾在自家研究中描述，WebP 無損圖片平均約比 PNG 小 26%。請把它視為方向性的基準，而不是承諾。你的圖片不是平均值。你的設計系統、螢幕截圖、商品照片、插圖、匯出素材與 CMS 上傳內容，都會有各自的表現。

WebP 無損通常在哪些地方省最多

透明圖片

PNG 常被使用，是因為它支援 alpha 透明度。WebP 無損也支援 alpha，而且通常能有效壓縮。

這對以下內容很有用：

• 商品去背圖
• 貼紙與徽章
• 介面覆蓋元素
• 具有透明背景的圖表
• 匯出尺寸大於必要大小的標誌

當 alpha 通道包含大範圍可預測區域、柔和邊緣或重複形狀時，節省效果可能很明顯。如果你有一整個型錄的透明商品圖片，WebP 無損值得早點測試。

螢幕截圖與 UI 擷取

螢幕截圖通常包含大片平坦區域、重複的介面元件、文字、圖示、陰影，以及一些照片區域。這種混合內容對 PNG 來說可能不太好處理，尤其在尺寸很大時。

WebP 無損通常能很好地處理這類圖片。一張完整頁面的 UI 螢幕截圖，如果最佳化後的 PNG 是 900 KB，轉成無損 WebP 可能會變成 500–700 KB。有時省得更多。有時省得較少。但這個類別很有潛力。

如果這些螢幕截圖出現在文件、行銷頁面、導覽流程或案例研究中，累積效果可能很實際。

插圖與影像混合內容

許多現代網頁圖像既不是純插圖，也不是純照片。想像一張 hero image，裡面包含產品 UI、漸層、小圖示、文字標籤與嵌入照片。

PNG 可以完美保留它，但檔案可能很大。有損 WebP 或 AVIF 如果壓得太重，可能會在文字與邊緣周圍產生瑕疵。當精確邊緣很重要時，WebP 無損可以是合理的中間選擇。

若要查看涵蓋 AVIF 與有損 WebP 的更完整圖片格式決策樹，請參考 2026 年的圖片格式：AVIF 何時勝過 WebP，何時不會。

PNG 可能仍然更好的地方

極小圖示與簡單素材

對非常小的檔案而言，格式開銷很重要。一個 650 位元組的 PNG 圖示，不是顯而易見的轉換候選。WebP 可能省下 80 位元組，也可能變得更大。

在這個尺度下，營運複雜度可能超過收益。如果檔案已經很小、不阻礙轉譯，而且會被長時間快取，你大概有更值得修的地方。

仔細最佳化過的調色盤 PNG

有些 PNG 比人們預期小很多，因為它們使用有限調色盤。好的索引色 PNG 對簡單圖形來說可能很難被超越。

這尤其適用於：

• 小型標誌
• 像素藝術
• 扁平圖示
• 簡單圖表
• 色彩很少的圖形

比較 WebP 與粗糙 PNG 匯出檔時要小心。如果 PNG 是直接從設計工具輸出，帶有不必要的後設資料與糟糕的壓縮設定，WebP 可能看起來好很多。但這不表示 WebP 能以相同幅度勝過良好最佳化的 PNG。

公平的測試應該拿 WebP 無損與最佳化後的 PNG 比較，而不是與剛好被上傳的任意檔案比較。

原本就應該使用有損格式的圖片

這是一個不太起眼的錯誤：團隊把 PNG 轉成 WebP 無損，但那張圖片一開始就不該是 PNG。

照片是最常見的情況。全彩照片存成 PNG 可能非常巨大。把它轉成 WebP 無損可能會縮小檔案，但通常仍會比高品質有損 WebP 或 AVIF 大得多。

如果使用者無法察覺差異，無損通常就是錯誤目標。商品攝影、編輯圖片、背景與人像，通常應該使用合理品質設定的有損格式。

無損應該保留給精確像素很重要的情況：UI 螢幕截圖、圖表、文字密集圖形、透明度、產生式圖表，以及在有損壓縮下會明顯劣化的素材。

除了位元組之外，它還省下什麼

最明顯的節省是傳輸大小。較小的圖片檔通常代表較少頻寬、更快下載，以及在慢速連線上更好的表現。

但也有次要效益：

• 計量方案訪客使用的資料量較少
• 圖片快取填入更快
• CDN 頻寬降低
• 大規模情境下的儲存與備份容量較低
• 對效能預算的壓力較小

這些節省並不是平均分布的。一張 2 MB PNG 轉成 900 KB WebP，比五十個各省 100 位元組的圖示更重要。

這就是為什麼圖片最佳化應該依頁面影響排序，而不是依格式意識形態排序。如果 Lighthouse 標示圖片傳遞問題，請把它視為線索，而不是判決。我們的指南 如何閱讀 Lighthouse 報告而不驚慌 說明了如何把有意義的效能問題與吵雜的診斷分開。

解碼成本的取捨

較小的檔案不是唯一的效能變數。瀏覽器在繪製圖片前，也需要先解碼圖片。

PNG 解碼成熟，而且通常很快。WebP 解碼也受到廣泛支援且效率良好，但在某些情況下可能需要更多 CPU。在現代裝置上這很少會成為阻礙，但在低階手機、圖片密集頁面，或大型首屏素材上，值得測量。

實用規則是：如果 WebP 無損能把大型 PNG 減少 30–50%，網路節省通常會佔主導。如果它只把小型 PNG 減少 3%，這個取捨大概不值得在意。

效能工作充滿這類門檻判斷。不要用同樣強度最佳化每一個位元組。

一個簡單的測試方法

使用具代表性的一批圖片，而不是單張圖片。

建立一個資料夾，放入你實際網站上的範例：

• 標誌與圖示
• 螢幕截圖
• 商品去背圖
• 圖表
• CMS 上傳的 PNG
• 社群預覽圖片
• 大型 hero graphics

然後比較三件事：

1. 上傳時的原始 PNG
2. 最佳化後的 PNG
3. WebP 無損版本

在命令列工作流程中，團隊常使用 oxipng、pngcrush、zopflipng 或 cwebp -lossless 等工具。具體工具沒有像「以同等條件比較」這件事那麼重要。

追蹤：

• 檔案大小
• 解碼後的像素是否相同
• 目標瀏覽器中的視覺呈現
• 透明度是否正確
• 色彩外觀
• 建置時間
• CMS 或設計工作流程中的摩擦

一份簡單的試算表就足夠。加入原始檔案大小、最佳化後 PNG 大小、WebP 無損大小、省下的百分比，以及圖片出現在哪個頁面。

接著依總共省下的位元組排序。這個排序通常會告訴你該怎麼做。

傳遞：不要隨意破壞舊用戶端

WebP 現在已受到現代瀏覽器廣泛支援。對多數公開網站來說，使用它是安全的。不過，如果你的環境中有嵌入式 webview、電子郵件用戶端、舊版企業瀏覽器、原生應用程式，或不尋常的爬蟲，請在直接取代 PNG 前先測試。

保守的模式是保留 PNG 作為 fallback，並在支援時提供 WebP：

<picture>
  <source srcset="diagram.webp" type="image/webp">
  <img src="diagram.png" alt="Diagram showing the checkout flow">
</picture>

這種方法很無聊，而無聊是好事。支援 WebP 的使用者會取得較小檔案。其他人則取得 PNG。

如果你的建置系統會為素材產生指紋，而 CDN 也正確快取它們，維護起來並不困難。如果你的 CMS 讓替代格式變得麻煩，請從最大且最常重複出現的圖片開始，而不是試圖在一次 sprint 中轉換整個媒體庫。

隱私與本機處理

圖片轉換通常發生在建置管線或伺服器端媒體服務中。對許多團隊來說這沒問題。但如果你處理的是敏感螢幕截圖、客戶上傳內容或內部文件，請注意檔案在哪裡被處理。

瀏覽器端圖片工具已經足以處理許多簡單轉換、預覽與後設資料檢查。它有其限制，但本機處理可以減少不必要的私人圖片上傳。我們在 為什麼在瀏覽器中處理圖片是隱私上的勝利 中討論過這些取捨。

對內部素材而言，重點是政策清楚。你需要知道圖片是否離開裝置、轉換後版本儲存在哪裡，以及後設資料是否被保留。

實用經驗法則

當以下三項都成立時，使用 WebP 無損：

• 來源目前是 PNG。
• 精確像素或乾淨透明度很重要。
• 與最佳化後的 PNG 比較後，WebP 無損能省下有意義的大小。

在以下情況保留 PNG：

• 檔案很小。
• PNG 已經做過調色盤最佳化，而且很有競爭力。
• 相容性限制不尋常。
• 營運複雜度不值得為省下的位元組付出。

在以下情況使用有損 WebP 或 AVIF：

• 圖片是照片類型。
• 精確像素不重要。
• 品質設定能在沒有可見損傷的情況下大幅減少大小。

最好的圖片策略很少是到處使用同一種格式。它是一小組一致套用的規則。

<!-- tool-cta:start -->

💡 試試這個： 將同一個 PNG 透過 Image Converter 處理，產生無損 WebP 版本，並直接比較檔案大小。

<!-- tool-cta:end -->

所以，WebP 無損實際省下了什麼？

它在 PNG 已經用盡壓縮技巧的地方省下位元組。有時這代表溫和的 10%。有時則代表把大型透明圖片幾乎砍半。在真實網站上，節省通常集中在少數素材上。

這才是重要的部分。WebP 無損不是相對於 PNG 的道德升級。它是針對特定工作的一個實用選項：更小的無損網頁圖片，具透明度，並有廣泛的現代瀏覽器支援。

在數字支持它的地方使用它。在數字不支持的地方，就讓 PNG 保持原樣。