一張 Banner 從三百 KB 瘦到一百出頭：WebP 壓縮管線的原理，讀完是一張頻寬成本單

2026 年 9 月 14 日，掘金上一篇標題直白的技術長文《WebP 壓縮到底在幹嘛？小白也能看懂的原理拆解》開始累積閱讀。文章不走學院路線，不推公式，而是帶著一張圖片走完整條壓縮管線，講清楚照片、Logo、透明圖為什麼都能塞進同一個格式，以及檔案變小的每一步各自犧牲了什麼。

這類內容每隔一兩年就會週期性翻紅一次。原因很實際：前端工程師換個副檔名，CDN 帳單就出現肉眼可見的落差。一張看似不複雜的 Banner，原始輸出動輒兩三百 KB，轉成 WebP 後視覺差異有限，體積卻少了一截。理解這一截從哪裡省出來，等於理解一整套內容傳輸的計價邏輯。

先分兩條路線：有損與無損

原文第一個釐清的觀念，是大多數人對「無損」的誤讀。無損不是沒有壓縮，而是換一種存法，解碼後像素逐位還原；有損也不等於肉眼可見的模糊，而是允許細節在一定容差內偏移，換取更小的檔案。作者用「幫檔案打 ZIP 包」比喻無損路線，但補充說明無損 WebP 還會利用相鄰像素的顏色關聯，壓縮率優於通用壓縮格式。

這裡的分流直接對應到使用場景的計價差異。照片類素材走有損路線，追求的是單位畫質下的最小位元組；UI 圖示與帶透明通道的素材走無損路線，寧可檔案稍大，也不接受像素漂移造成的邊緣雜點。一個格式同時覆蓋兩種需求，取代的目標清單就拉長了：JPEG 之外，還包括 PNG 的部分版圖。

有損管線的三個動作

原文把有損路線拆成幾個連續步驟，並反覆強調「數字的個數並沒有直接減少」，真正省空間的是表達方式的改變。

第一步是色彩空間轉換。RGB 三個數值描述一個像素，WebP 先換成 Y、U、V 三份數值表：Y 記錄明暗，U 與 V 共同記錄顏色差異。拆開的理由來自人眼感知的不對稱：一行小字的邊緣明暗一糊立刻難讀，天空裡細微的色偏通常不易察覺。

第二步是色彩降採樣，也就是 4:2:0 結構。以一個 2×2 區域為例，四個位置保留四個明暗值，但只保留一個 U 和一個 V 採樣。換算到 1920×1080 的圖片，Y 表維持 1920×1080，U、V 各降為 960×540。原文特別點出常見誤解：這既不是把圖片寬高縮小，也不是把四個位置變成同一種顏色，減少的是色彩取樣密度。這一步已經在丟資訊，不是等到後段量化才首次有損。

第三步是預測與殘差。處理顏色平緩的天空時，已解碼的鄰居像素能給出近似值：預測亮度 118，真實值 120，只需記錄殘差 2。一串相近的亮度值於是變成許多接近零的差值，後續更容易找到規律。工程上的約束是，編碼端只能參考解碼端也拿得到的鄰居，不能偷看只有原圖才有的資訊。

之後的變換步驟把殘差分組整理。原文的例子是十六個位置差值都是 2，逐位記錄要寫十六次，換個說法則是「這一整片都是 2」加上位置資訊，一次講完。量化再把精度降低，讓更多差值落到整齊的區間，這是有損路線中畫質折損最集中的環節。

這條管線動到誰的成本結構

把鏡頭從演算法拉到商業帳上，WebP 的壓縮率直接計價的欄位是 CDN 流量費。以大型內容平臺的規模估算，圖片普遍佔頁面總體積的五到六成，若格式轉換帶來三成上下的體積縮減，傳輸端省下的是以流量計費的線性成本。這與我們先前拆解過的PNG 轉 WebP 的頻寬與運算成本帳屬於同一條帳：頻寬省在帳單上，運算成本花在解碼再編碼的 CPU 裡。

受惠方結構清楚。內容平臺與電商網站是流量大戶，格式轉換的固定工程投入攤到海量請求上，單位成本趨近於零；CDN 業者表面流量計費收入縮水，但邊際頻寬本就是採購成本，量縮對毛利的影響視合約結構而定。承壓的一端是舊格式生態與轉換初期的運算開銷：批次轉檔喫 CPU，手機端解碼 WebP 也比 JPEG 略耗，這筆隱含成本由伺服器營運方與終端使用者分攤，帳面上通常看不到。

替代曲線走到哪一段

WebP 由 Google 於 2010 年開源釋出，瀏覽器支援在 2020 年前後才算補齊主流版圖。對照 JPEG 從 1992 年標準化到完全普及的週期，格式替代是一條以十年計的緩坡。真正加速替代的變數不是演算法改良，而是硬體解碼支援與內容工具鏈的預設值：當設計軟體與上傳管線預設輸出 WebP，前端工程師甚至不需要做那個「換副檔名」的決策。

更晚進場的 AVIF 與 JPEG XL 沿用同一套評估框架，比較的項目仍是壓縮率、解碼耗能與生態支援三欄。掘金這篇文章的價值在於把「壓縮率」那一欄拆開攤平，讓讀者看見 4:2:0 降採樣、預測殘差、量化各自貢獻多少、又各自付出什麼。

回到最初的問題：一張圖片轉檔後省掉了什麼。答案不是像素，而是重複表達。明暗與色彩拆開記、稀疏處採樣少記、相近處用差值短記，每一步都在壓縮「說同一件事的次數」。對平臺而言，這套原理換算成流量帳單；對工程師而言，它決定了畫質容忍度那條線該畫在哪。理解管線之後再下轉檔決策，至少知道省下的每一 KB 是從哪個環節擠出來的。