一張圖片的瘦身帳：PNG轉WebP省下的頻寬，先花掉的是誰的CPU

2026年9月14日，掘金上一篇題為「PNG/JPG如何變成WebP？真相不是改後綴」的技術長文再次被推上熱榜。文章的核心其實是一句話：格式轉換的本質，是把原檔解碼回像素，再用目標格式的編碼器重新壓縮一次。改副檔名得到的只是一個副檔名錯誤的PNG，瀏覽器讀到檔頭就會拒收。

這個看似工程師常識的話題，之所以每隔一段時間就會被重新討論，背後有一筆實實在在的基礎設施成本帳。這篇文章把那筆帳攤開來算。

先看格式轉換在技術上發生了什麼

PNG內部用的是篩選器加DEFLATE無損壓縮，JPEG走的是DCT變換、量化、熵編碼的有損路徑，WebP則有自己的一套預測與變換機制，同時支援有損與無損兩種模式，還能保留透明通道。

三種格式在檔案層級的資料結構完全不同。但一旦解碼，到達圖像處理庫（例如文中反復提到的libvips）這一層，剩下的就是一組規格化的像素：寬1920、高1080、RGB或RGBA，每個像素是一組數值。輸出時再交給目標格式的編碼器重新打包。

這裡有一個關鍵分岔。PNG轉WebP若選無損模式，且中間不做縮放、裁剪、調色等改變像素的操作，那麼解碼出來的像素與再編碼後解回來的像素完全一致，內容零損失，只是換了一種更省空間的存放方式。若選有損模式，量化從這一步才真正開始，資訊的丟失發生在WebP編碼器內部，而不是發生在「轉檔」這個動作本身。

為什麼平臺願意為這個重打包付錢

根據Google WebP官方頁面長期公布的基準數據，WebP無損模式比同解析度的PNG平均小26%，有損模式在同等視覺品質下比JPEG小25%至34%。以一個日均圖片請求量十億級的內容平臺估算，單檔平均縮小四分之一，直接意味著CDN回源流量與邊緣節點儲存佔用同步下降一個臺階。

頻寬是CDN計價的硬指標。假設一個平臺每月圖片流量100PB，每GB頻寬成本按主流雲端報價落在0.01至0.08美元區間，取中值估算，25%的檔案縮減對應的是每年數百萬美元級的支出減項。這也是為什麼Google自2020年起在Chrome穩定版全面支援WebP、蘋果自iOS 14與macOS Big Sur的Safari跟進之後，各大平臺的圖片管線改造在2021年前後密集上線。格式支援的瀏覽器覆蓋率跨過門檻，轉檔的投資回收期才成立。

但這筆帳的借方同樣具體。解碼再編碼不是免費操作，每一張上傳圖片都要消耗一次完整的CPU週期。原文之所以特別推薦libvips，正是因為它相對主流替代方案的解碼與縮放速度快上一個量級，在同等機器預算下能撐住更高的轉檔吞吐量。對內容平臺而言，轉檔是即時發生在使用者上傳鏈路裡的，轉檔延遲直接寫進上傳體驗，這決定了工程團隊願意為編碼器效能付出多少選型成本。

影響推演：誰受惠，誰承壓

受惠端首先是雲端CDN與物件儲存業者。客戶單位流量成本下降，表面上壓縮了計費收入，但流量總量隨短影音與高解析度圖片需求持續膨脹，儲存側的絕對用量仍在上升，格式升級更像是把計費結構從頻寬往「轉檔次數、邊緣運算呼叫次數」遷移，ARPU未必受損。以圖片處理為賣點的Serverless圖片服務，本質上就是把這次解碼再編碼的CPU帳，包裝成按次計費的產品。

承壓端是自建圖片叢集的中型平臺。轉檔管線改造涉及上傳、審核、縮圖、CDN快取鍵值的整條鏈改造，還要處理新舊格式並存的過渡期，一次性工程投入不小，而節省的金額要攤到未來數年的流量上才能回本。使用者規模不到一定量級，這筆投資的回收期就拉得很長，這也是為什麼格式替代呈現明顯的規模分化：頭部平臺早已完成，長尾站點仍在觀望。

另一個值得記錄的張力在解碼端。WebP檔案更小，但解碼運算量高於JPEG，對低階手機的電量與流暢度是一筆轉嫁給終端使用者的隱性成本。格式競爭從來是壓縮率與解碼開銷的交換，這與內容生產領域的論文生產成本塌方有相似的結構：生產端成本驟降之後，瓶頸會移到鏈條的另一端，在那裡重新計價。

收束判斷

把時間軸拉長，WebP本身也已不是終點。Google主導的AVIF與JPEG XL相繼進場，前者已獲主流瀏覽器支援，壓縮率對WebP再有提升。每隔幾年，同一套「解碼回像素、再重新編碼」的流程就要為新格式重跑一遍，每一次重跑的決策變數都相同：編碼CPU成本、儲存與頻寬節省、終端解碼覆蓋率，三者相加是否為正。

對多數平臺，這道算術題的答案隨流量成長而不斷翻正。掘金這篇熱文的價值，在於把「轉WebP」這個被產品經理輕描淡寫的需求，還原成一次真實消耗運算資源的完整工程動作。帳本上省下的頻寬是真的，花掉的CPU也是真的，兩者記在同一張表上，才是格式遷移決策該有的樣子。