LEARN · ARTICLE
網站圖片轉 WebP：品質、無損與批次腳本
作者：Rock Lee 實測日期：2026-11-09（Asia/Taipei）
為什麼寫這篇
我們的教學頁每篇至少 6 張圖，加上 AI 封面，圖片是頁面裡最大的檔案。網路上常見的建議是「全部轉 WebP 就好」，但轉的時候還有幾個要決定的事：品質設多少？截圖要不要用無損？照片裡的 EXIF（拍攝資訊、GPS）會不會跟著留下？
這篇拿我們網站上真的在用的 11 張 AI 封面和 12 張介面截圖實測，最後附一個今天實際跑過的批次轉檔腳本。
實測環境
| 項目 | 內容 |
|---|---|
| 工具 | Python 3、Pillow 12.3.0（支援 WebP 和 AVIF） |
| 素材 | AI 封面 JPG 11 張（1280×720）；介面截圖 PNG 12 張（多數 1920×1350） |
| 對照 | 網站上已上線的 WebP 檔（2026-11-09 讀取） |
| 畫質指標 | PSNR（和原圖比的訊號雜訊比，數字越高越接近原圖，只當參考） |
步驟
1. 先整批試一次：封面和截圖結果完全不同
同一套設定分別套在封面和截圖上，比較 WebP 有損（品質 80）、WebP 無損、AVIF（品質 50）和 JPEG（品質 80）。
| 素材 | 原檔 | WebP 品質 80 | WebP 無損 | AVIF 品質 50 | JPEG 品質 80 |
|---|---|---|---|---|---|
| AI 封面 11 張 | 3194.5 KB | 659.9 KB（省 79.3%） | 7011.8 KB（大 119.5%） | 376.2 KB（省 88.2%） | 1254.8 KB |
| 介面截圖 12 張 | 2445.1 KB | 1045.9 KB（省 57.2%） | 744.0 KB（省 69.6%） | 462.3 KB（省 81.1%） | 1995.6 KB |
兩個重點：
- 封面（照片、插畫類）千萬別用無損，檔案會變成原本的兩倍多。
- 截圖用無損反而比有損小（744 KB 對 1045.9 KB），因為截圖大片純色、顏色少，無損壓縮很有效。
AVIF 在兩類都最小，但截圖那組編碼花了 3.61 秒，是 WebP 有損（1.39 秒）的兩倍多。我們網站目前用的是 WebP。
2. 品質要設多少：用一張圖掃一遍
拿一張封面（原檔 269.8 KB）從品質 50 掃到 95：
| 品質 | 50 | 60 | 70 | 75 | 80 | 85 | 90 | 95 |
|---|---|---|---|---|---|---|---|---|
| 大小（KB） | 23.3 | 26.7 | 31.6 | 34.8 | 50.8 | 71.3 | 121.2 | 209.1 |
| PSNR（dB） | 36.4 | 36.9 | 37.5 | 37.8 | 38.8 | 39.8 | 41.5 | 44.3 |
80 以上檔案就開始快速變大：從 80 到 90 檔案多了一倍多，PSNR 只多 2.7 dB。這張圖在 75 和 80 之間有一個跳躍，所以品質不是越高越好，要看自己的圖。
實際看局部放大：
老實說，在 2 倍放大下，我們用眼睛看不太出品質 50 和 80 的差別，文字和插圖都還清楚。我們仍選 80 當預設，是保守做法：PSNR 比 50 高約 2.4 dB，檔案又還在原檔的兩成以內。如果你的圖以插畫為主、很在意大小，可以自己試 70～75。
3. 尺寸比品質更重要
同一張封面，品質固定 80，只改寬度：原尺寸 1280 寬是 50.8 KB，縮到 800 寬是 20.5 KB，480 寬是 9.4 KB。
網站上實際放的檔案也是這樣做：
- 一張 n8n 教學的封面，480／800／原尺寸三個版本分別是 8.4／17.4／51.9 KB。
- 一張 2200×1662 的 PNG 截圖（203 KB），網站上放的是 1600 寬的 WebP，58 KB。
- 網站學習區目前共 116 個 WebP，合計 4.67 MB。
手機上 800 寬就很夠了。先把尺寸縮到實際顯示的大小，再談品質。
4. 寫成批次腳本
把前面的結論寫成一個腳本 to_webp.py：
規則只有四條：
- 寬度超過上限就等比縮小，只縮不放大。
- 一律先轉有損 WebP；如果原檔是 PNG，另外試無損，取比較小的那個。
- 轉完比原檔還大，就保留原檔。
- 不帶 EXIF。
5. 實際跑兩批
| 批次 | 指令參數 | 結果 | 時間 |
|---|---|---|---|
| n8n 教學截圖 8 張 | 寬 1600、品質 80 | 1508 KB → 464 KB（省 69.2%） | 2.7 秒 |
| AI 封面 11 張 | 寬 800、品質 80 | 3195 KB → 234 KB（省 92.7%） | 0.7 秒 |
8 張截圖這次全部選了有損，原因在下一步。
6. 確認 EXIF 有沒有被清掉
照片裡可能帶 GPS 位置。我們做了一張假的測試照（相機型號 DemoCam、GPS 北緯 10 度、東經 100 度），用不同方式轉檔再讀回來：
| 轉法 | EXIF 欄位 | GPS |
|---|---|---|
| 原圖（JPG） | 4 個 | 有 |
| 預設轉 WebP | 0 個 | 無 |
| 轉 WebP 時傳入 exif | 4 個 | 有 |
| 預設轉 JPEG | 0 個 | 無 |
在 Pillow 12.3.0，預設轉檔不會帶 EXIF；只有明確把 EXIF 傳進去才會保留。其他工具不一定一樣，換工具時要再測一次。
結果
- 封面、照片類：WebP 有損品質 80，省約 79%；千萬別用無損。
- 截圖：原尺寸時無損通常比較小，但縮圖之後就不一定（見踩坑 1）。腳本同時試兩種、取小的最省事。
- 先縮尺寸再壓：11 張封面縮到 800 寬，從 3195 KB 降到 234 KB。
- 預設不帶 EXIF，GPS 不會外洩；但要自己驗一次。
踩坑紀錄
- 截圖縮小後，無損反而變大。 一張 2160×1290 的編輯器截圖，原尺寸時無損 62 KB、有損 78 KB；縮到 1600 寬後變成無損 93 KB、有損 54 KB。我們數了圖中不同顏色的數量：原圖 1259 種，縮圖後變 2401 種。縮圖會在邊緣產生很多中間色，對無損壓縮不利。所以第 5 步的 8 張截圖縮到 1600 寬後，全部選了有損。
- 小心意外放大。 品質掃描時我們試了把 1280 寬的封面輸出成 1600 寬，檔案變成 65 KB，比原尺寸還大，畫質也不會更好。腳本因此寫成只縮不放大。
- 同一個品質，不同 method 結果不同。 Pillow 的
method參數（0–6）控制壓縮要花多少力氣。同一張封面品質 80，method 4 是 50.8 KB，局部放大比較用的 method 6 是 44 KB。比較數字時要確認參數一樣。
常見問題
Q1：WebP 和 AVIF 該選哪個？ 我們的實測 AVIF 更小（截圖組 462 KB 對 WebP 有損 1046 KB），但編碼比較慢。我們網站目前用 WebP；要換 AVIF 前，建議先確認你的網站框架和目標使用者的瀏覽器都支援。
Q2：品質一定要設 80 嗎？ 不一定。80 是我們偏保守的選擇（見第 2 步）。建議拿自己的 2～3 張代表圖掃一遍，選一個看不出差別、又不會太大的值。
Q3：轉 WebP 會讓 SEO 變好嗎？ 這篇沒有測 SEO。可以確定的是圖片變小、頁面載入的資料變少；本系列 Lighthouse 那篇裡，頁面最大的元素就是封面圖。
Q4：原檔要留著嗎？ 要。WebP 有損是不可逆的，之後要改尺寸或換格式，都應該從原檔重新轉，不要拿 WebP 再轉一次。
複製這段給你的 AI agent
目標：把我指定資料夾裡的 JPG／PNG 批次轉成 WebP，輸出到新資料夾，並回報省了多少。 前提與禁止事項： - 只讀來源資料夾，輸出到另一個新資料夾；不要覆蓋、移動或刪除任何原檔。 - 用 Python 和 Pillow（記下版本號），不要上傳圖片到任何線上服務、不要安裝付費工具、不要部署。 - 不要保留 EXIF。 步驟： 1. 寫 to_webp.py，參數：來源資料夾、輸出資料夾、最大寬度（預設 1600）、品質（預設 80）。 2. 規則：寬度超過上限才等比縮小（用 LANCZOS），不放大；先存有損 WebP；若原檔是 PNG，另外試無損，取較小者；結果比原檔大就不輸出、標記「保留原檔」。 3. 每張印出：檔名、原大小、新大小、選了有損或無損、輸出寬度；最後印出總計、節省百分比、耗時。 4. 從輸出中挑 1 張照片類、1 張截圖類，局部放大 2 倍和原圖並排存成一張比較圖，讓我目視確認。 5. 做一張帶假 EXIF（含 GPS）的測試圖，轉檔後讀回，確認 EXIF 欄位數為 0。 驗收：原檔數量和大小完全沒變；輸出資料夾每張都比原檔小或有「保留原檔」紀錄；EXIF 測試結果為 0 個欄位；附上比較圖。