是的，用 WebP。2026 年，對於你自己掌控的網站，這就是完整答案：每個瀏覽器多年前就能渲染 WebP，檔案比被替換的 JPG 或 PNG 小 25–35%，訪客體驗的唯一變化是頁面載入更快。真正有意思的問題是操作層面的：哪些圖值得轉、怎麼交付 WebP 才不搞壞東西、哪些地方 PNG 和 JPG 仍然該留著。這篇指南講的就是這些。
什麼值得轉，什麼別動
不是每張圖都配得上這份功夫。決策樹很短：
先轉大件。 首屏大圖、產品照片、文章配圖——一切以幾百 KB 計的東西。一張 450 KB 的 JPG 變成 300 KB 的 WebP 是真實的收益，再乘以每位訪客的每次頁面載入。產品網格和相簿是複利發生的地方。
轉有份量的 PNG 圖形。 以 PNG 傳上去的截圖、示意圖和透明 UI 圖，轉成有損 WebP 後體積驟降；即使無損 WebP 也比 PNG 小約四分之一。技術上的原因見 WebP 與 PNG 比較。
小檔案別碰。 一個 4 KB 的圖示是四捨五入的誤差。轉它省不下任何可感知的東西，還白搭流程裡的一步。規則：如果一個檔案已經小到從來沒進入過你的腦海，那就繼續別想它。
遷移路徑
- 盤點關鍵頁面上的圖片——首頁、核心著陸頁、產品模板。你的分析工具知道是哪些。
- 批次轉換 PNG 和 JPG 素材。 把資料夾拖進 PNG 轉 WebP 或 JPG 轉 WebP；兩者都在你的瀏覽器本機運作，吃下整個資料夾，交回一個 ZIP。沒有任何東西離開你的機器——素材是客戶成果時這一點尤其重要。
- 保留原圖。 WebP 常用模式是有損的。你的 PNG/JPG 母版仍是未來任何重新編碼的事實源頭。
- 替換模板裡的引用並重新上傳。轉換器保留檔名、只改副檔名，所以在模板裡全域替換
.png→.webp就能涵蓋大頭。
如果你的網站跑在 CMS 上
動手轉換之前先查一下。現代 WordPress 接受 WebP 上傳並像其他圖片一樣產生各種子尺寸，很多代管服務和 CDN 還能在邊緣自動轉 WebP——那種情況下，遷移是一個設定頁面的事，不是檔案操作。手工轉換仍然適用於靜態網站、手寫模板，以及任何媒體流程比這個格式還老的 CMS。
帶回退地交付
<picture> 元素讓現代瀏覽器拿走 WebP，古老的一切則落回原圖：
<picture>
<source type="image/webp" srcset="/img/hero.webp" />
<img src="/img/hero.jpg" alt="Hero image" width="1600" height="900" />
</picture>
瀏覽器挑第一個它能看懂的 source；其餘的一切照常讀 <img>，彷彿什麼都沒發生。2026 年這屬於雙保險——瀏覽器的 WebP 支援早已普及——但它只花一行程式碼，就把這個問題徹底從桌上拿走。替代方案是基於 Accept 標頭的伺服器端內容協商，在 URL 層面達成同樣的效果；它很強大，但把複雜度挪進了伺服器設定——大多數小網站應該拒絕這筆交易。
保留 PNG 或 JPG 的地方
即使在全站 WebP 的網站上，三類東西仍留在舊格式：
訪客要下載的檔案。 「下載媒體資料包」這種連結應該給 PNG 或 JPG，因為接收的人可能拿任何東西開啟。瀏覽器之外的支援缺口是真實的——就是我們在 WebP 與 JPG 比較裡畫過的那道。
Open Graph 和郵件圖片。 og:image 和電子報素材是被爬蟲、聊天應用程式和郵件用戶端抓取的，它們的影像堆疊比瀏覽器老得多。用 JPG 或 PNG 交付，否則就接受部分預覽靜默失敗。
你的母版檔案。 永遠。WebP 是運輸貨櫃，不是檔案館。
想了解每種格式各自位置的完整地圖，網頁圖片格式指南有全景。
切換之後
把核心頁面在切換前後各跑一次測速。提升會出現在它該出現的地方：LCP（最大內容繪製）、頁面總重量，以及位元組最疼的行動體驗。如果某個頁面幾乎沒動，說明它的圖片本來就小——也就是說上面的決策樹完成了自己的工作，告訴過你跳過它們。把前後對比數字存好，它們是遷移網站其餘部分的論據。
轉換本身是這個專案裡最快的部分。一個資料夾的產品圖過一遍 PNG 轉 WebP 不到一分鐘；改模板花的時間更長。從你最重的頁面開始——讓瀑布圖去說服那些仍覺得這事可做可不做的人。