WebP、JPG、PNG 圖片格式比較：選對格式提升速度

你也許曾遇過這種狀況？精心拍好的商品照，上傳到網站後，手機一開卻等了五秒首頁還在轉圈；縮圖壓到糊掉，桌機看又像隔了一層霧。問題多半不是攝影、也不是主機，而是你選錯了圖片格式。

圖片是現代網頁裡體積最大的資產類別，常常吃掉一半以上的頁面重量。格式選對，畫質與速度可以同時拿下；選錯，再貴的主機、再強的快取外掛都救不回來。在網站效能專案裡，重點從來不是「哪個格式最好」，而是「在這個情境下、給這些讀者、走這個 CMS 流程，哪個格式最不會出事」。這篇會把 WebP、JPG、PNG 三個主流格式拆到壓縮原理層級，再給你一份能直接套用的決策流程。

快速重點整理：攝影與連續色階照片用 JPG 或 WebP（破壞性壓縮）；需要透明背景、文字截圖、Logo、圖示用 PNG 或 WebP（無損）；新站或可控制前端的情境，主動擁抱 WebP 並用 <picture> 提供 JPG 退路。格式僅是起點，真正的分數來自「格式＋壓縮＋延遲載入＋CDN」的組合。

為什麼圖片格式是網站速度與畫質的交叉路口

圖片格式之所以值得處理，主要不是為了迎合演算法，而是減少傳輸量、縮短等待並改善閱讀與轉換體驗（見 web.dev 的研究）。圖片常是頁面中體積較大的資產，但實際瓶頸仍要用效能工具判斷，不能僅看格式。

Google 的排名系統會使用 Core Web Vitals，但官方說明指出，良好分數不保證排名靠前，相關性更高的內容仍可能勝出。因此它應視為輕量的排名考量與重要的使用者體驗指標，而不是排名捷徑。在 LCP（Largest Contentful Paint，最大內容繪製）裡，英雄圖、產品主圖或 Banner 常可能成為最大內容元素，但仍要以實際量測為準。

如果首頁全寬主圖是實測到的 LCP 元素，它的下載與呈現時間就值得優先處理。同一張照片用 PNG、JPG 或 WebP 匯出，檔案大小可能相差很多，但沒有固定七倍差距；必須用同一來源、尺寸與可接受畫質實際比較。

行動裝置讓這個槓桿變得更尖銳，Statista 對全球行動網頁流量的長期統計可作為背景。行動網路的延遲與穩定性不一，大圖在桌機寬頻無感，到了尖峰時段的手機連線就可能變慢。Google 已全面採用行動優先索引，意思是主要使用網站的行動版內容進行索引；這是索引方式，不代表手機版天然取得排名加成。

也因此，這點值得強調：格式選擇不是美編的偏好問題，而是 SEO 與轉換率的基礎工程。如果你想更全面地理解這些指標怎麼影響排名，可以先看過 Core Web Vitals 完全攻略，這篇會聚焦在「圖片」這個切入點。

JPG、PNG、WebP 的核心差異：從壓縮原理看起

很多人比較格式時僅看「檔案多大」，那是結果，不是原因。真正該理解的是背後的壓縮原理，因為原理決定了每個格式能勝任什麼任務、又在哪裡會露餡。

JPG（JPEG）走的是破壞性壓縮（lossy compression），設計目標是「人類視覺對高頻細節不敏感」。它會故意丟掉眼睛注意不到的色彩資訊，把檔案壓到極小，代價是無法完美還原，而且反覆存檔會累積失真，出現所謂的 JPEG artifact（塊狀雜訊）。JPG 不支援透明背景，這是它最大的硬傷。它的強項是照片、漸層、膚色、自然景觀這類連續色階內容。

PNG走的是無損壓縮（lossless），存什麼、讀出來就是什麼，不會失真。它用 DEFLATE 演算法處理「顏色重複」的區塊，所以對大面積純色、色塊界線分明的圖特別有效率，例如 Logo、圖示、UI 截圖、含銳利文字的示意圖。它完整支援 Alpha 通道，可以做半透明。代價是：遇到照片這類色彩變化劇烈的內容，PNG 會膨脹到非常誇張，常常是 JPG 的五到十倍大。

WebP同時支援破壞性與無損壓縮，也支援 Alpha 透明與動畫（見 Google 的 WebP 開發者文件，2026 年）。Google 公布的測試結果是，破壞性 WebP 在相當 SSIM 品質下平均比 JPEG 小 25% 到 34%，無損 WebP 比 PNG 小約 26%。這是特定資料集與方法的平均值，不保證每一張圖都如此；文字、線條或特殊色彩內容仍要實測。

維度	JPG	PNG	WebP
壓縮模式	破壞性	無損	破壞性＋無損
透明背景	不支援	支援（含半透明）	支援（含半透明）
動畫	不支援	不支援（APNG 例外）	支援
最適合的內容	照片、漸層、連續色階	Logo、圖示、文字截圖、銳利色塊	兩者皆可，視模式而定
反覆存檔失真	會累積	不會	破壞性模式會累積
典型體積（同張照片）	中	最大	最小

說穿了，這三個格式各自用不同數學模型解不同的問題，並非單純的新舊進化關係。WebP 想當通才，但通才有通才的代價，下面會談到。理解原理之後，你才不會在該用 PNG 的場合硬上 WebP，結果文字邊緣糊了一圈還不知道為什麼。

透明背景、文字截圖、連續色階：三種你會選錯格式的情境

規格表背得起來，不等於實務會用。最常見的格式錯誤，剛好集中在三種情境。這三種情境每天都會遇到，絕非邊角案例。

情境一：需要透明背景的 Logo 與素材

品牌 Logo、產品去背圖、浮在彩色背景上的圖示，必須保留透明區域。很多人會直覺存成 PNG，這沒錯，但常常忘了壓掉多餘的中繼資料與色盤，讓一個小 Logo 檔莫名其妙破百 KB。如果你的網站已經支援 WebP（現在幾乎都支援了），同樣的透明 Logo 用 WebP 無損模式通常能再小個兩到三成。

這裡有個常見的坑：WebP 的無損模式對「極少量的顏色」反而未必比 PNG 小，尤其當圖僅有兩三個顏色、面積又小時，差距會縮到幾乎可忽略。所以對微型圖示，實務上會直接用 PNG 並用壓縮工具跑過，不強求 WebP。透明的去背處理本身又是另一門學問，可以搭配 AI 去背工具 把前置作業先做乾淨，再去想格式。

情境二：含銳利文字的截圖與示意圖

教學文裡的操作截圖、儀表板畫面、程式碼截圖，這類內容的特徵是「文字邊緣必須銳利」。用 JPG 存這種圖是災難，破壞性壓縮會在文字邊緣產生漣漪狀的雜訊（ringing artifact），小字直接糊到看不清楚。這類內容僅能用無損格式，PNG 是安全牌，WebP 無損也行。

老實說，教學型截圖建議全部都存 PNG。原因在於 PNG 未必比較先進，卻在「文字銳利度」這件事上最沒有意外，而且任何 CMS、任何編輯器都不會對它做二次破壞性壓縮。穩定，比極致省檔重要。

情境三：照片與連續色階內容

產品照、人物照、風景、食物照，這類內容色彩變化連續、細節豐富，是破壞性壓縮的主場。JPG 一直是預設選擇，但 WebP 的破壞性模式能在同等肉眼畫質下再省四分之一到三分之一。對電商網站來說，一個商品頁如果有八張產品圖，每張省 100 KB，整頁就少了將近 1 MB，對 LCP 與轉換率都是直接的幫助。

商品攝影的素材來源也很關鍵，從 免費圖庫 下載的素材常常已經是高壓縮 JPG，二度轉檔要特別小心失真疊加。處理電商專案時的習慣做法是：永遠從原始檔（RAW 或高畫質 TIFF）重新匯出，不要拿壓過的 JPG 再壓一次 WebP。

同一張圖怎麼比較：檔案大小、畫質與載入取捨

挑一張具代表性的照片，例如 1920×1080 的戶外人物照，分別用 JPG、PNG、WebP 匯出，記錄體積並放大檢查邊緣、漸層與細節。這能把抽象的「省多少」變成自己網站可重現的數字。

比較時要固定來源尺寸，再把視覺品質調到可接受程度。照片情境下，PNG 通常比破壞性 JPG 或 WebP 大；JPG 與 WebP 的先後則取決於編碼器、品質參數與圖像內容，不能把單次排序當成通則。

格式（同張照片，品質對齊）	相對體積	肉眼畫質	適用判斷
PNG（無損）	照片通常最大	保留原始像素	較適合透明、文字與銳利色塊
JPG（破壞性）	依品質參數而定	需檢查壓縮痕跡	相容性高的照片格式
WebP（破壞性）	常可小於同等品質 JPG	需與 JPG 並排檢查	現代網站常用選項

這裡要提醒一個迷思：很多人以為「無損＝畫質最好＝應該無腦選」，於是連照片都存 PNG。錯了。對照片這類內容，無損保留的是「人眼根本看不到的高頻雜訊」，你花了五倍的頻寬去傳送一個沒有人會注意的細節。破壞性壓縮的整個設計哲學，就是「在你看不到的地方省錢」。

JPG 與 WebP 的品質值不是跨工具通用的絕對尺度，也沒有適合所有圖片的固定甜區。先選一個中高品質起點，逐步降低並比較檔案大小、色帶、邊緣與細節；找到網站可接受的最低品質後，再把該工具與參數寫進流程。

想找幫你跑這類壓縮的工具，延伸閱讀可以看 圖片壓縮工具實測，裡面有批次處理與失真控制的選項比較。

WebP 真的全支援了嗎？瀏覽器相容性與 fallback 策略

WebP 已獲現代主流瀏覽器支援（見 MDN 的圖片格式指南）。是否仍需 fallback，應看實際受眾、嵌入式瀏覽器與企業環境，避免用快速變動的全球覆蓋率代替自己的流量資料。

那還需要準備 fallback（退路）嗎？判斷關鍵在於：看你讀者的組成。如果你的後台顯示訪客幾乎全是現代瀏覽器，直接用 WebP 幾乎不會出事。但如果你經營的是 B2B、政府、企業內訓這類情境，讀者可能還在用舊版瀏覽器，那 fallback 就是保險，不是多餘。

提供 fallback 最乾淨的做法是用 HTML5 的 <picture> 元素，它讓你列出多個來源，瀏覽器會自己挑選它能讀的格式：

<picture>
  <source srcset="hero.webp" type="image/webp">
  <source srcset="hero.jpg" type="image/jpeg">
  <img src="hero.jpg" alt="產品主視覺" width="1920" height="1080">
</picture>

瀏覽器會使用第一個支援的 <source>，都不支援時退到最終的 <img>。最終用 JPG 可提供廣泛相容性，但仍要確認伺服器 MIME type 與檔案可存取。加上 width 與 height，可讓瀏覽器預留空間並降低圖片造成的 CLS。

WordPress 從 5.8 開始支援 WebP 上傳（見 WordPress 5.8 adds WebP support），6.5 起也支援 AVIF（見 WordPress 6.5 adds AVIF support），但核心預設不會把既有 JPG、PNG 自動轉成 WebP。自動轉檔仍取決於主機影像函式庫、外掛或媒體處理流程。

行動優先時代的格式決策樹

講了這麼多規格，回到實務。做網站圖片健檢時，可以走一棵簡單的決策樹，把「格式選擇」拆成幾個能依序回答的問題。這棵樹的核心精神是：先問內容類型，再問透明需求，最終才問瀏覽器與 CMS。

1. 這張圖的主要內容是什麼？若是照片、連續色階、漸層、人物、風景，走向破壞性壓縮這一支（JPG 或 WebP 破壞性模式）。若是 Logo、圖示、含銳利文字的截圖、UI 示意圖，走向無損這一支（PNG 或 WebP 無損）。
2. 需要透明背景嗎？需要，就排除 JPG。在 PNG 與 WebP 無損之間選一個。微型圖示偏 PNG，較大的去背素材可試 WebP。
3. 這張圖會被反覆編輯存檔嗎？會，就保留一份原始無損檔（PNG 或 TIFF），對外發布才轉成破壞性格式。千萬別拿壓過的 JPG 當工作母檔。
4. 你的 CMS 與前端支援 WebP 嗎？支援，且瀏覽器覆蓋沒問題，就用 WebP 當主要輸出，搭配 <picture> 與 JPG 退路。不支援或沒把握，先用 JPG/PNG 過渡。
5. 這張圖是不是頁面的最大內容（LCP 元素）？若是，就避免延遲載入，並視圖片發現時機考慮 fetchpriority="high"。僅有在瀏覽器無法及早發現圖片時才考慮預載入，避免重複或過度提高資源優先序。

這棵樹的最大用途，是讓你在面對一張新圖時不必每次重新推理。團隊成員也能照著走，格式決策從「靠經驗」變成「照流程」。決策樹本身不會給你新知識，但它會把對的選擇變成預設行為，這才是工程化的價值。

響應式圖片也不能忽略。小螢幕通常沒必要下載為大螢幕準備的原始尺寸；用 srcset 與 sizes 屬性，讓瀏覽器依版面與裝置挑選合適版本，是獨立於格式的優化。實際節省量取決於原圖、輸出尺寸、壓縮與使用者裝置，應以 Network 面板或效能工具量測。響應式的整體觀念可以看 響應式網頁設計 RWD 這篇。

把響應式圖片與格式選擇疊起來，會得到一個更完整的 <picture> 寫法：先讓瀏覽器選格式（AVIF 優先、WebP 次之、JPG 兜底），再讓它在每個格式裡選尺寸。這層組合是現代前端圖片處理的標準做法，WordPress 與大多數 CMS 的優化外掛最終產出的就是這種結構。你不必手寫，但要看得懂它做了什麼，這樣出問題時才知道該檢查哪一層。

還有一個比格式更上游的問題值得問：這張圖真的需要這麼大嗎？很多時候我們放了一張 2000 像素寬的圖，實際顯示寬度僅有 600 像素，那多出來的解析度純粹是浪費頻寬，再怎麼挑格式也救不回來。格式優化的前提，是尺寸已經先收斂到合理範圍。先問尺寸，再問格式，這個順序搞錯，後面的功夫都是白做。

把格式選擇接上 Core Web Vitals：LCP 才是真正的戰場

前面多次提到 Core Web Vitals，這裡把它與圖片格式的關係說清楚。web.dev 的 Vitals 說明（2026 年）定義了三個核心指標：LCP（載入效能）、INP（互動回應速度）、CLS（視覺穩定度）。圖片在這三個指標裡都會插上一腳，但權重最大的是 LCP。

web.dev 的 Optimize Largest Contentful Paint（2026 年）指出，LCP 優化要拆成 TTFB、資源載入延遲、資源載入時間與元素渲染延遲。圖片壓縮與格式轉換主要改善資源載入時間；若瓶頸在伺服器回應或圖片發現太晚，僅換格式不會解決全部問題。

INP 主要反映互動延遲。大量圖片解碼有可能占用主執行緒，但是否構成實際瓶頸要用效能追蹤確認；不能僅憑格式推論。若 INP 不佳，應同時檢查長任務、第三方腳本與事件處理。

CLS 則是另一個圖片直接相關的指標。圖片沒有設定 width 與 height，瀏覽器在它載入前不知道要保留多大空間，於是載入瞬間會把下方內容擠下去，造成版面跳動。這個跳動會進入 CLS 計算。解法跟格式無關，但跟「圖片優化」這個大主題高度相關，所以每次講圖片都要重申：給圖明確尺寸。更完整的指標拆解可以看 Core Web Vitals SEO。

Core Web Vitals 指標	圖片如何影響	格式能幫上什麼
LCP（載入效能）	大圖是最大內容時，下載時間直接計入	體積越小，LCP 越快
INP（互動回應）	大量圖片解碼佔用主執行緒	間接幫助，但解碼成本需留意
CLS（視覺穩定）	無尺寸的圖片造成版面跳動	與格式無關，但屬同一優化主題

格式選擇不是孤立的技術選型，它會影響下載量與 LCP，但 Core Web Vitals 僅是 Google 排名系統採用的多項考量之一。投入圖片優化最直接的理由，仍是讓讀者更快看到內容。網頁速度與排名的整體關係，可以再對照 網頁速度是什麼 與 技術性 SEO 指南。

Core Web Vitals 的達標判斷以實際使用者資料（field data）為主；Search Console 的報告來自 CrUX 彙整資料，Lighthouse 則是特定條件下的實驗室診斷。兩者用途不同：用 Search Console 觀察真實使用者趨勢，用 Lighthouse 定位可重現的技術問題，不必期待數字完全一致。

WordPress 與電商情境的落地實作

理論講完，進入落地。多數讀者跑的是 WordPress，所以這段會聚焦在 WordPress 的實作路徑，並補上電商情境的特殊考量。

WordPress 處理 WebP 有兩條主路徑。第一是透過圖片優化外掛在上傳或批次處理時產出 WebP，再依外掛與伺服器設定向支援的瀏覽器提供新格式；不是每款外掛都一定改寫成 <picture>。第二是先在外部轉好 WebP，再利用 WordPress 5.8 之後的原生上傳支援。選擇前要檢查備份、原圖保留、CDN 相容性與回復方式。

兩條路徑不互斥。實務上的偏好是用原生 WebP 上傳主要的英雄圖與產品主圖（這些圖建議手動微調品質），再讓外掛批次處理其他歷史圖。更完整的 WordPress 圖片優化流程，包含壓縮、格式、延遲載入，可以看 WordPress 圖片優化指南。如果你的速度瓶頸不僅出在圖片，WordPress 網站加速 與 WP Rocket 完整設定 能把快取、腳本延遲、資料庫清理這些環節也補上。

挑外掛時有一個觀念要先建立：沒有任何一個外掛能完美處理所有情境。每一款都有自己的壓縮演算法偏好與品質預設，有人對照片激進、有人對截圖保守。實務做法是挑兩款都試，用同一批圖跑過一次，比較體積與畫質，再選一個固定下來。這個前置測試若花半小時，卻能避免你用錯工具長達一年。外掛不是萬靈丹，它僅是把你的格式決策自動化的執行者，決策邏輯本身還是要你先想清楚。

電商情境有兩個額外壓力。第一，商品頁圖片數量多，一頁八到十二張產品照是常態，格式紅利會被放大。第二，商品圖直接影響購買決策，畫質不能妥協到讓客人對商品產生疑慮。所以電商情境的習慣做法是：商品主圖用品質稍高的 WebP（品質 82 到 85），確保細節清晰；縮圖、分類頁預覽圖則可以壓更兇，因為它們是導覽用途，不是購買決策的依據。經營 WooCommerce 的讀者可以對照 WooCommerce 購物網站架設，把圖片優化接進你的商品上架流程。

另一個容易被遺漏的環節是延遲載入（lazy loading）。視窗外的圖片不必急著下載，這能省下大量初始載入的預算。WordPress 從 5.5 起原生支援 loading="lazy"，但要注意一個反直覺的地雷：LCP 圖片（通常是首屏的英雄圖或產品主圖）不能延遲載入，否則反而會讓 LCP 變慢。延遲載入的正確用法是「僅延遲視窗下方、使用者還沒捲到的圖」，詳細做法見 Lazy Loading 延遲載入指南。

把這些環節串起來，你會得到一個完整的速度優化鏈：格式壓縮省體積、延遲載入省初始預算、CDN 縮短傳輸距離、快取外掛避免重算。每一環都有對應的工具，串得好就是乘數效果。速度優化的全貌可以參考 速度優化的完整做法，CDN 的角色看 CDN 是什麼，快取外掛的選擇看 WordPress 快取外掛推薦。如果你的站已經慢到需要急救，網站慢到爆怎麼辦 裡有整理好的速度瓶頸診斷流程。

從單張優化到資產管線：讓格式選擇可重複

單張圖優化不難，難的是「每一張圖都優化」。當你的網站有幾百、幾千張圖時，靠手動一定會漏，所以真正的目標是建立一條可重複的資產管線（asset pipeline），讓格式選擇變成流程的副產品，不必每次重新思考。

一條基本的圖片資產管線會長這樣：原始檔（RAW 或高畫質 TIFF）放進素材庫，由設計師或攝影師產出編輯版，再用腳本或工具批次匯出成發布格式（WebP 為主、JPG 為輔），最終上傳到媒體庫或 CDN。每一個環節都有對應的工具：素材管理用 Eagle 素材管理工具 之類的軟體分類與標記，批次壓縮用前面提到的圖片壓縮工具，CDN 則負責最終一哩的傳遞。

規模再大一點，建議把匯出做成自動化腳本。例如用 ImageMagick 或 sharp 這類命令列工具，寫一段簡短的腳本，輸入資料夾裡的所有 JPG，一次產出對應的 WebP（指定品質 80）與縮圖版本。這聽起來像工程師的事，但寫一次、跑一輩子，比手動一張張轉檔有效率太多。即使你不懂程式，也可以請熟悉命令列的夥伴幫你把這段固定下來。

資產管線的核心好處是「一致性」。當整個團隊都用同一條管道產出圖片，格式、品質、尺寸、命名規則就會自動收斂，不會出現有人存 WebP、有人存 PNG、檔名各自混亂的局面。一致性聽起來不性感，但它就是規模化的前提。沒有一致性，優化僅能靠英雄式的個案處理；有一致性，優化才是系統的預設行為。

這也是圖片 SEO 一再強調的觀念：把單點最佳實踐，變成可重複的流程。格式僅是其中一環，命名、alt 文字、結構化資料這些都應該被收進同一條管線。完整的圖片搜尋優化觀念見 圖片 SEO 優化指南。

AVIF 與格式演進：該不該現在就跳船

談 WebP 就不能不提 AVIF，因為總會有人問：「既然 WebP 已經省很多，那下一代格式 AVIF 會不會更省？我要不要直接上 AVIF？」這是個好問題，也是個典型的「過早最佳化」陷阱。

AVIF（AV1 Image File Format）源自 AV1 視訊編碼，支援高效率壓縮、透明度與 HDR 等能力。它已獲現代主流瀏覽器支援，WordPress 6.5 也加入 AVIF 上傳與處理支援；因此到了 2026 年，不能再籠統說「還沒到進場時機」。是否採用，仍要看編碼速度、主機函式庫、CMS、CDN 與 fallback 流程（格式支援現況可對照 MDN 的圖片格式指南）。

AVIF 的編碼通常較耗運算，批次轉檔的時間與伺服器成本需要實測；舊裝置與內嵌瀏覽器也可能需要 fallback。工具鏈已比早期成熟，但不同 CMS、CDN 與圖片服務的支援仍不一致。這些都是部署前應在 staging 驗證的條件。

如果現有流程僅使用 JPG 與 PNG，可以先選 WebP 或 AVIF 做一輪代表性樣本測試，再以 <picture> 提供相容格式。WebP 的工具鏈通常較簡單；AVIF 可能進一步縮小部分圖片，但要把轉檔時間、畫質與回復流程一起算進去。兩者都不是免費且零風險的效能提升。

優先把正確尺寸、壓縮、responsive images、LCP 載入策略與備份流程做好，再比較 WebP 與 AVIF，通常比追逐單一格式更有效。格式演進會繼續，部署決策應以自己的圖片與受眾資料為準。

實務上常見的五個圖片格式地雷

收尾前，把處理網站效能時重複出現的五個圖片格式錯誤整理出來。這些不是理論推測，是真實會發生在網站上的坑。

• 英雄圖存成 PNG。這是最致命也最常見的錯誤。一張全寬主視覺存成 PNG，體積隨便破 2 MB，LCP 直接爆掉。不少設計感強烈的站，主圖用 PNG 是因為設計師習慣從 Photoshop 直接匯出，沒意識到首頁第一張圖就是 LCP 計時靶心。解法很簡單：英雄圖一律 WebP 或 JPG，PNG 留給真正需要透明的素材。
• 拿壓過的 JPG 再壓一次 WebP。破壞性壓縮的失真會疊加。從已壓縮的 JPG 轉 WebP，省的體積有限，畫質卻會再退一階。正確做法是回到原始無損檔重新匯出。如果原始檔已經不見，這就是一個教訓：永遠保留工作母檔。
• 文字截圖存成 JPG。前面提過，破壞性壓縮會在文字邊緣產生漣漪雜訊，小字直接糊掉。教學型網站特別容易犯這個錯，因為截圖數量多，直覺想省體積。但截圖本來就該用無損格式，體積多半不會大到哪去。
• 全部圖片都延遲載入，包含 LCP 圖。這是「過度優化」的典型。延遲載入的設計是「視窗外的圖晚點載」，但很多人一刀切套用到所有圖片，結果首屏主圖也要等 JavaScript 觸發才開始下載，LCP 反而變慢。記得：LCP 圖片要優先載入，不是延遲。
• 圖片沒給 width 與 height。這個跟格式無關，但跟圖片優化主題綁很緊。沒有尺寸的圖會造成 CLS，把你的 Core Web Vitals 分數往下拉。現代瀏覽器需要這兩個屬性來預留空間，這是零成本的事，卻最常被忽略。

這五個地雷的共同點是：發生時通常無聲無息，你不會在編輯時發現，僅會在 PageSpeed Insights 或 Search Console 的 Core Web Vitals 報告裡看到分數莫名其妙變差。所以養成習慣，每次改完圖片相關的設定，就用 網站速度測試工具 跑一次驗證。這不是強迫症，是工程紀律。

五步行動方案：今天就把圖片策略升級

看完一千多字的分析，落實到行動才是重點。做網站圖片健檢時，建議固定走這五步，你也可以照著跑一遍自己的站。

1. 盤點現況。用 PageSpeed Insights 或 Lighthouse 跑首頁與流量最高的三個頁面，記下 LCP 分數與「最大內容元素」是哪一張圖。同時用 Search Console 的 Core Web Vitals 報告，看是否有格式相關的警示。這一步是建立基準，沒有基準就不知道改善多少。
2. 抓出 LCP 圖片並優先處理。那張首屏主圖，就是你投資報酬率最高的目標。確認它的格式（若是 PNG，立刻改成 WebP 或 JPG）、尺寸（不要在手機上送 1920 寬大圖）、與載入策略（不要延遲載入、加上 fetchpriority="high"）。光這一張圖處理好，LCP 常常就能進入良好區間。
3. 建立格式對照規則。用前面那棵決策樹，把你的圖片分成三類：照片類（WebP/JPG）、透明素材類（PNG/WebP 無損）、截圖類（PNG）。把這份規則寫進團隊文件，讓每個上傳圖片的人都有依歸。規則不必複雜，能被遵循比完美更重要。
4. 批次處理歷史圖片。如果你的 CMS 是 WordPress，裝一個能批次產出 WebP 的優化外掛，回頭掃媒體庫。這一步可能要跑幾十分鐘到幾小時，視圖片數量而定，但它是一次性的投入，做完之後整站自動受惠。
5. 把優化接上資產管線。訂一個素材命名規則、指定匯出格式與品質、固定保留原始檔。從今天起，新進的每一張圖都走同一條管道。舊圖慢慢補，新圖不再欠債，幾個月後回頭看，你的圖片資產就會是乾淨可維護的狀態。

這五步不需要一次做完。即使先做前兩步，也能找出最值得處理的圖片；至於 LCP 能改善多少，要以前後量測為準。重點是把優化變成常態，而非一次性的專案。

圖片格式選擇就是用合適的壓縮方式處理內容，再送給對的讀者。WebP、JPG、PNG、AVIF 之間沒有絕對贏家。把格式、尺寸、壓縮、載入策略與 CDN 一起處理，圖片就能從效能負擔變成兼顧畫質與速度的資產。

如果你在盤點過程中發現網站的速度問題不僅出在圖片，而是整體架構、主機、或技術 SEO 都需要全面調整，Whoops SEO 提供網站效能與 SEO 健檢服務，可以幫你把這些環節一次看清楚。無論是自己動手還是找人合作，把圖片格式這件基本功做好，都是最划算的第一步。