WordPress 圖片優化指南：壓縮、格式與延遲載入

圖片優化其實不是比誰裝的外掛多，而是比誰把順序走對。很多人的現況是：壓縮外掛裝了兩三套，延遲載入全開，跑一次測速，LCP 還是亮紅燈。問題多半出在優化的順序搞反了，外掛其實不是癥結。

整個觀念的核心只有一句：先把原圖的尺寸、格式與品質做對，再用外掛和 CDN 補上自動化與交付。不同網站的瓶頸不一定相同，但源頭檔案若已符合顯示需求，後續通常會更容易維護。

重點摘述

• 上傳前先處理尺寸與格式，外掛則負責自動化與回溯處理。
• 先決定尺寸與格式，再依畫質需求壓縮。
• 首屏可見的圖要優先載入、不延遲；版面下方要滾才看到的圖才延遲載入。
• 素材網站不等於 CC0 圖庫；每次下載前都要確認該平台與該素材的授權。
• 舊站的媒體庫不是無解，但要用對方法、按優先級分批處理，別想一次全救。

接下來我把整條圖片供應鏈拆開來講，從數字、觀念、格式、壓縮、延遲載入，一路到舊站搶救與一張上傳前檢查表。

為什麼圖片是拖垮 WordPress 速度的頭號嫌犯

HTTP Archive 的 Web Almanac（2022 年 Page Weight 章）顯示，圖片是許多網頁裡占用位元組的重要資源。根據 Statista 的追蹤（2026 年 4 月），全球網頁流量約有六成來自行動裝置。圖片體積越大，在較慢或不穩定的連線上越容易拉長等待時間。

Google 用 Core Web Vitals 衡量部分頁面體驗，其中 LCP（Largest Contentful Paint，最大內容繪製）關注視窗內最大內容元素的顯示時間，而首圖常是該元素。若 LCP 圖片過大，縮小傳輸量可能改善載入；幅度仍受主機回應、資源優先級與快取等因素影響。Google 也指出速度會影響使用者體驗與轉換，應用自身數據驗證改善成果（見 web.dev 的〈Why does speed matter?〉）。Core Web Vitals 是有限的排名訊號，內容相關性仍然更重要。

對使用行動網路的讀者來說，過大的首圖可能讓主要內容遲遲無法顯示，增加離開的機會。跳出率可以協助觀察使用行為，但不是 Google 公開的直接排名訊號，也不能單憑高低判定內容品質。圖片優化主要解決的是載入體驗，是否帶動留存與轉換仍要實測。

圖片太大還可能增加儲存、備份與傳輸成本，實際費用取決於主機和 CDN 方案。把原圖處理好通常能同時減少傳輸量與媒體庫體積，但不宜預設它一定是每個網站投資報酬率最高的項目，仍要先找出真正瓶頸。

所以圖片優化不是「讓網站好看一點」的邊緣工作，它掛在 技術性 SEO 的成績單上，和 結構化資料 Schema 標記、Canonical URL 重複內容處理屬於同一層基礎工程。想理解這些指標背後的完整脈絡，可以先看 Core Web Vitals 指標的完整拆解，或是回到 網頁速度（Page speed）是什麼建立基本觀念。

很多人以為裝了圖片壓縮外掛就等於處理完，其實部分外掛也能縮放原圖、轉檔或產生不同尺寸，能力依方案而異。上傳前先決定尺寸與格式，通常能減少後續處理量；檔名則影響管理與語意，不會直接改變圖片體積。

先建立全貌：圖片優化的槓桿曲線

可以把整件事看成一條處理鏈：素材授權、尺寸與格式在上傳前決定；自動壓縮與延遲載入在上傳後補上。各階段處理的問題不同，不應把外掛當成唯一解法。

優化階段	發生時機	對檔案大小影響	常見工具
授權與素材選擇	上傳前	決定可用範圍，與檔案大小無直接關係	授權清楚的圖庫或自製素材
尺寸裁切	上傳前	圖片遠大於顯示需求時通常最明顯	修圖軟體
格式選擇	上傳前	依圖片內容與編碼設定而異	轉檔工具
手動壓縮	上傳前	依原檔與品質設定而異	瀏覽器版或桌面版壓圖工具
外掛自動壓縮	上傳後	可壓縮、縮放或轉檔，依外掛與方案而異	WordPress 圖片優化外掛
延遲載入	執行時	不影響檔案，改變載入順序	瀏覽器原生 loading=lazy 或外掛

從這張表看出的取捨邏輯：尺寸裁切一個動作就能少掉大半像素，外掛再怎麼努力也擠不出同樣的幅度。把心力投資在最源頭，是這整套做法能省主機資源的根本原因。

換個比喻，這件事像搬家。圖片就是那些又大又重的家具，外掛壓縮像在搬家當天才想辦法把家具硬塞進卡車，能擠掉的空間有限；而在上傳前裁切、壓縮，等於在裝潢階段就先量好尺寸、買對大小的家具，從頭就沒有多餘的體積。前者是補救，後者是設計。

舉例來說，若相片原檔寬 4000 像素，前台最大只顯示 800 像素，先依裝置像素密度保留合理尺寸，再調整格式與品質，通常比只壓縮原尺寸更有效。實際可縮小多少取決於影像內容與編碼器，不能預設固定的 MB 或百分比。

把圖片規格寫進內容流程，可以避免媒體庫持續累積尺寸與格式不一的檔案。若速度問題仍存在，再檢查佈景主題、頁面編輯器、第三方指令碼與主機回應，不要只增加圖片外掛。

從瀏覽器反推：一張圖到底該生產幾個尺寸

多數人決定圖片尺寸的方式是「憑感覺」：相機或手機拍多大就上傳多大。這是災難的起點。比較好的做法是反過來，從瀏覽器實際會怎麼用這張圖，倒推你該生產什麼。

一張圖在頁面上最終只會佔一個有限的顯示寬度。多數文章內文的圖片顯示寬度頂多 800 到 1000 像素，全寬橫幅頂多 2000 出頭，你根本不需要上傳一張 5000 像素、5MB 的單眼原檔。再加上高 DPI 螢幕（手機、Retina 螢幕）會以兩倍密度渲染，實務上的安全上限大約是「顯示寬度的兩倍」。顯示 800 像素，就準備 1600 像素的檔案，再多都是浪費頻寬，讀者也看不出差別。

WordPress 會在上傳時產生多個圖片尺寸，並透過 srcset 讓瀏覽器選擇合適檔案。WordPress 5.3 起，超過大圖門檻的圖片預設也會建立縮放版作為主要附件圖片；原始檔仍可能保留在主機上，佈景主題和外掛也可能註冊額外尺寸。因此，上傳合理尺寸仍有助於控制儲存與處理量。

這裡藏著一個 WordPress 站長常低估的成本。每上傳一張原檔，系統實際寫進主機的檔案不會只有一個。假設你的佈景主題與 WooCommerce、Elementor 這類外掛總共註冊了六個額外尺寸，那麼一張原檔就會衍生出一張原圖加六張縮圖，共七個檔案。一篇文章配五張圖，媒體庫就多出三十五個檔案。原檔只要大一點，這個乘數效應會把主機儲存空間與備份體積撐得很可觀，回溯壓縮時外掛要處理的數量也跟著翻倍。於是，我會建議，寧可放數量略多、但每張都精實的圖，也別在媒體庫裡堆少數幾張超大原檔。

要決定一張圖到底該生產多大，最準的方法是打開瀏覽器的開發者工具實測，憑猜測只會浪費時間。對著你版面上的圖按右鍵檢視，看它在不同裝置寬度下「實際渲染出來的像素寬度」。把這個渲染寬度乘以二（高 DPI 螢幕的緩衝），就是你該準備的長邊。一次量好幾種版面位置（內文圖、首圖、側欄縮圖），之後同一種版型就照同一個數字走，不用每次重新想。這個動作只花你十分鐘，卻能幫你省下無數張上傳後才發現「太大要重傳」的冤枉工。

實務上我會這樣定長邊上限：

• 文章內文實景相片：1600 像素
• 首圖與全寬橫幅：2000 像素以內
• 產品圖（白底）：1200 到 1500 像素
• 圖表與截圖：顯示寬度的兩倍
• Logo 與圖示：實際顯示的兩倍，能用向量檔更好

記住一個原則：寧可上傳「略大於最大顯示需求兩倍」的尺寸，也不要上傳原始未壓縮相片。前者是留緩衝，後者是純粹的浪費。

JPG、PNG、WebP、AVIF：四種格式的真實取捨

格式選擇的本質，是「這張圖的色彩結構適合哪種壓縮演算法」。把所有圖一視同仁全部存成同一種格式，會得到「Logo 變糊、相片還是太大」的尷尬結果。

JPG 是老牌的有損壓縮格式，處理色彩複雜的實景相片最在行，檔案小、相容性百分之百。它的弱點是不支援透明背景、重複壓縮會逐次失真、文字邊緣容易出現雜訊。PNG 是無損格式，色塊單純的圖示與文字截圖用它反而更小更清晰，而且支援透明背景，缺點是拿來存實景相片會大到誇張。

WebP 同時支援有損、無損、透明背景與動畫，Google 的 WebP 格式文件提供了相對 JPEG 與 PNG 的壓縮測試結果，但個別圖片仍會因內容與品質設定不同。AVIF 也能提供高壓縮效率，但仍需確認編碼與伺服器影像函式庫支援。WordPress 自 5.8 支援 WebP 上傳，自 6.5 起在伺服器環境支援時可上傳 AVIF。

判斷的兩個維度很直觀：

• 色彩複雜度：相片、漸層屬於複雜，JPG 與 WebP 處理得最好；色塊單純的圖示與文字截圖屬於單純，PNG 的無損壓縮反而更小更清晰。
• 是否需要放大檢視：產品圖、圖表常被讀者放大看細節，壓縮就保守一點；純裝飾用途的圖永遠不會被放大，可以放手壓到極限。

這兩個維度想清楚，遇到任何一張新圖都能在十秒內決定格式與壓縮力道。實務建議是：實景相片用 JPG 或 WebP，圖示與截圖用 PNG（或 SVG），Logo 能用 SVG 就別用點陣格式。

格式	壓縮類型	透明背景	適合場景	主要風險
JPG	有損	不支援	實景相片	重複壓縮會逐次失真、文字邊緣有雜訊
PNG	無損	支援	圖示、文字截圖、Logo	存相片會異常肥大
WebP	有損＋無損	支援	相片、圖形與動畫	需確認編輯流程、CMS 與影像函式庫支援
AVIF	有損＋無損	支援	相片與需要高壓縮效率的圖片	編碼成本較高，需確認伺服器支援
SVG	向量（非點陣）	支援	Logo、圖示、簡單插畫	不適合複雜相片，內嵌指令要注意資安

是否準備 JPG 備援格式，要看實際瀏覽器支援需求與交付架構。現代瀏覽器普遍支援 WebP；若仍需照顧不支援的環境，可用 <picture> 提供多個來源，或交由 CDN、圖片服務和外掛處理。上線後要在目標裝置確認實際輸出。

想把 SEO 端的圖片命名、alt 文字、結構化標記一起做對，可以再延伸看 圖片 SEO 優化的完整做法。而當使用者直接拿照片發動搜尋，圖片能不能被比對、被找到又是另一層課題，Google Lens 怎麼把照片變成搜尋結果把這層邏輯拆開講。

壓縮的三層防線，以及為什麼外掛只能當第三層

我把壓縮想成三層防線，層層把關，但每一層的能耐差很多。

第一層是上傳前的手動壓縮。瀏覽器版或桌面版工具（例如 TinyPNG）可以重新編碼圖片，讓你在上傳前比較檔案大小與畫質；節省幅度取決於原檔，不保證固定比例。

第二層是上傳時的格式轉換。如果你決定用 WebP，就在這一步把 JPG 轉成 WebP，或從影像編輯軟體直接匯出成 WebP。這層的收益來自格式本身，和「再壓一次」是兩件不同的事。

第三層是外掛自動處理。圖片優化外掛可依功能與方案執行壓縮、縮放、轉檔或回溯處理。它適合接住多人上傳與既有媒體庫，但設定前要確認是否和快取、CDN 或其他圖片功能重疊。

壓縮還有一組觀念要先分清楚：無損（lossless）與有損（lossy）。無損壓縮可保留原始影像資訊，有損壓縮則捨棄部分細節換取更小體積。一般內容相片常適合有損壓縮；文字截圖、需要後續編輯或保存細節的圖片，則可能需要無損格式或較保守的品質設定。

有損壓縮的關鍵參數是品質等級。多數工具用 1 到 100 表示，數字越低檔案越小、畫質越差。實景相片我習慣落在 70 到 80 之間，這個區間通常是「檔案驟降、肉眼幾乎無感」的甜蜜點；再往下壓，邊緣會開始出現色塊與光暈，反而傷眼。圖表與截圖因為要保住文字清晰度，品質要拉高一點，或乾脆走 PNG 的無損路線。別迷信某個固定數字，要在壓縮工具裡前後拖動品質滑桿、用肉眼比對，找出「再降一階就看得出糊」的那個臨界點，往上加一點就是你的安全值。

啟用外掛前，先確認壓縮強度、原檔保存方式與還原流程，不要直接對完整媒體庫套用不可逆的最高壓縮。想看安裝與設定，可以參考 Smush 圖片壓縮外掛；若想理解整體加速鏈路，也能搭配 載入速度優化全攻略。

延遲載入的眉角：哪些圖該等、哪些圖搶著先載

延遲載入（Lazy Loading）的原理很簡單：圖片直到「快要進入可視範圍」才開始下載，沒滾到就不載，省下初期頻寬。現代瀏覽器對 loading="lazy" 已經原生支援，WordPress 從 5.5 版起也自動為 <img> 加上這個屬性，所以多數情況你什麼都不用做，就有基本效果。

但延遲載入有個容易踩錯的反面：首屏的圖不該延遲。LCP 元素，通常是首圖或英雄橫幅，如果被延遲載入，等於你叫瀏覽器「等一下再載最重要的東西」，LCP 反而會變慢。正確做法是讓首屏圖優先，甚至主動提示瀏覽器「這張先抓」。HTML 的 fetchpriority="high" 屬性就是做這件事的，把它加在 LCP 圖片上，等於明確告訴瀏覽器這張是 VIP，請提早發出請求。

判斷原則可以這樣記：

• Above the fold（首屏可見）的圖：不延遲；確認是 LCP 圖片後，再考慮設定 fetchpriority="high"。
• Below the fold（要往下滾才看到）的圖：延遲載入，省下初期載入。
• 背景裝飾大圖：能改成純色就改純色，不行就延遲，甚至考慮直接拿掉。

延遲載入還有一個最常被漏看的副作用：版面跳動。當一張延遲的圖下載完成、突然塞進版面時，下方所有內容會被往下推，讀者原本想點的按鈕瞬間位移，這就是 Core Web Vitals 裡 CLS（Cumulative Layout Shift，累計版面位移）在量的東西。CLS 太高，不只體感差，也會直接拖累你的速度分數。

解法是在圖片下載前就先把空間留好。最乾淨的做法是給每張圖明確的寬高屬性，或用 CSS 的 aspect-ratio 指定比例，讓瀏覽器在圖還沒載入時，就先畫出正確大小的占位框，圖下載完直接填進去，版面不動。現代 WordPress 在插入圖片時大多會自動帶上寬高屬性，但自訂版面或舊文章裡的圖常常漏掉，值得回頭補。把延遲載入與預留空間一起做，才算真正把這件事做對。

還有一個觀念要先分清楚：延遲載入不改變檔案大小，只改變載入順序。所以它解決的是「感知速度」與初期載入，不是總頻寬。別以為掛了延遲載入就不用壓圖，那是兩件不同的事。想把延遲載入的機制、外掛做法與常見陷阱弄清楚，可以再看 Lazy Loading 延遲載入的專篇。

一張決策矩陣，十秒判斷任何新圖怎麼處理

不同類型的圖，最佳處理路徑並不一樣。把所有圖一視同仁全部丟進同一個壓縮工具，往往會得到「Logo 變糊、相片還是太大」的尷尬結果。我把常見類型整理成一張決策矩陣，遇到任何新圖，照表對照就能在十秒內決定格式、尺寸與處理重點。

圖片類型	建議格式	建議尺寸（長邊）	處理重點
文章內文實景相片	JPG 或 WebP	依版面與裝置像素密度	裁切後比較品質與檔案大小
首圖與全寬橫幅	JPG 或 WebP	依最大顯示寬度	留意 LCP，首屏圖不延遲
Logo 與圖示	SVG 或 PNG	實際顯示的兩倍	透明背景優先，向量檔更輕
產品圖（白底）	WebP 或 JPG	依縮放與放大需求	保留需要檢視的商品細節
圖表與截圖	PNG	顯示寬度的兩倍	文字清晰度優先，避免破壞性壓縮抹平字元
背景裝飾大圖	WebP	依最大顯示寬度	可採較高壓縮，首屏以外再延遲載入

這張表背後只有兩個問題：這張圖色彩複雜還是單純？這張圖會被讀者放大檢視嗎？回答完這兩題，格式與壓縮力道就底定了。

表裡特別把 SVG 拉出來講，因為它是 Logo 與圖示的隱藏王牌。SVG 是向量格式，記錄的是形狀的路徑，和點陣格式記錄一顆顆像素的做法完全不同，所以不管放大到多大都不會失真，檔案也通常比同效果的 PNG 小上一截。網站常用的 Logo、社群圖示、簡單插畫，只要原本是向量繪製的，匯出成 SVG 幾乎永遠是最佳選擇。要留意的是，SVG 內嵌指令有潛在資安風險，從外部來源拿到 SVG 時，最好用可信工具清理一遍再上傳，別直接丟陌生檔案進媒體庫。

另一個判斷技巧是看「壓縮後還能不能再小」。產品圖的白底因為色彩極度單純，壓縮率通常特別高，值得多花一秒測試不同品質等級；相對地，色彩複雜、細節密集的風景相片，壓太兇會很快出現色塊，要懂得見好就收。同一個品質數字丟給所有圖，是新手最常犯的錯。

授權先決：每個素材平台都要逐一確認條款

找圖之前先看授權。常見免費素材平台大多有自己的平台授權，不能一概稱為 CC0；同一平台也可能混有不同來源或個別授權的內容。以 Pexels 為例，多數內容適用 Pexels License，部分素材才可能標示為 CC0，並且另有禁止原樣轉售、誤導性背書等限制。下載時應保存素材頁面、作者、日期與當下授權條款。

創用 CC（Creative Commons）包含多種授權，有些要求姓名標示，有些限制商業用途或改作；CC0 的限制較少，但仍不代表素材中的商標、肖像、藝術品或財產權利一定都已處理。平台授權也不是創用 CC 授權，必須分開閱讀。如果常需要素材，可以把 商用免費圖庫總整理作為入口，但每次使用前仍要回到原始授權頁確認。

幾個容易混淆的層級是：CC BY 通常允許商用與改作，但要依條款標示；CC BY-NC 限制商業使用；CC BY-ND 不允許散布改作版本。裁切、加字或其他調整是否構成改作，要看具體行為與適用法律，不宜只憑「壓縮過」就下結論。營利網站若無法確定是否符合 NC 或 ND，改用授權更明確的素材較穩妥。這不是法律意見，有高風險用途應諮詢專業人士。

AI 生成圖片也要分別檢查工具條款、輸入素材來源、輸出使用權與所在地法律。不要預設「AI 產的就能隨便用」，也不要預設所有免費圖庫素材都是 CC0。對商業站來說，保留來源與授權紀錄，比只記平台名稱更重要。

需要去背、找圖示、找 3D 素材，也都有對應的免費資源，例如 AI 去背工具、免費 Icon 圖示網站，或 3D 素材資源。善用這些工具，能讓你在不犧牲授權安全的前提下，把版面做得更有質感，別為了省一點錢去賭一張來路不明的圖。

舊站回頭救：媒體庫已經塞滿大圖怎麼辦

舊站若已累積大量原圖，先用測速工具確認哪些高流量頁面的 LCP 元素確實是圖片，再處理那些實際下載尺寸過大的檔案。不要一開始就重壓整個媒體庫，也不要為了改檔名直接替換圖片網址；後者可能造成斷圖或需要重新導向。

舊站搶救的重點在於分批、按優先級處理，別想一次救全部：

1. 先用測速與流量資料找出影響較大的頁面，處理數量依網站規模決定。
2. 確認首圖或首屏圖是否為 LCP 元素，再重新裁切、壓縮並安全替換。
3. 啟用外掛的回溯壓縮（bulk optimize），讓它在背景慢慢處理媒體庫裡的舊圖，但別期待它創造奇蹟。
4. 同時把延遲載入與首圖優先載入設定好，讓現有圖片的載入順序先合理化。
5. 持續把「上傳前處理」變成新文章的固定流程，舊的慢慢還，新的不再欠債。

這套節奏的好處是：你不必停下手邊所有事去搶救整個媒體庫，而是把力氣花在影響最大的那批頁面，邊還債邊前進。如果你連現在的速度基準都還沒拿到，先跑一次 網站速度測試工具，有數字才知道往哪裡施力；碰到更廣泛的效能瓶頸，也能回頭看 網站慢到爆怎麼辦的診斷流程。

舊站還可能需要重新產生縮圖。當佈景主題或外掛新增圖片尺寸後，舊附件不一定自動補齊，可以用縮圖重建工具依目前設定產生。執行前要先備份並估算儲存空間，因為這項操作可能新增大量檔案；完成後也要檢查前台與快取。

另一種常見的極端是：站長因為焦慮，一次把整個媒體庫幾千張圖全部刪掉重來。這通常是過度反應。圖片優化是投資報酬率的遊戲，不是潔癖遊戲。與其追求一個「完美乾淨的媒體庫」，不如先把會被讀者看見、會影響分數的那幾十張首圖顧好，剩下沒人點開的舊文配圖，慢慢還就行。真正會拖垮分數的，永遠是少數高流量頁面的少數幾張大圖，整個媒體庫的總和反倒次要。

上傳前三十秒檢查表：固定流程

把前面所有觀念濃縮成一張上傳前檢查表，這是一套每處理一張圖都可以走一次的固定流程，大約三十秒一張：

• 授權：保存素材頁與授權紀錄，確認商用、改作、標示及其他限制。
• 檔名：改成有意義的描述性檔名（例如 wordpress-image-optimization-guide.webp），別用 IMG_2049.jpg。
• 尺寸：依最大顯示寬度、裝置像素密度與放大需求裁切。
• 格式：實景相片用 JPG 或 WebP，圖示截圖用 PNG 或 SVG，Logo 能用 SVG 就用 SVG。
• 壓縮：用可信的壓圖工具比較前後體積與畫質。
• alt 文字：寫一句描述圖片內容的文字，為讀者與搜尋引擎而寫，別塞關鍵字。

這六個欄位走完，一張圖才算真正「上傳就緒」。聽起來囉嗦，但養成習慣後是反射動作，而且它省下的，是日後被速度問題回頭找麻煩的巨大成本。

多人協作時，建議把檢查表寫進共用規範，並集中保存圖片版本、來源與授權資訊。每個上傳者採用相同的尺寸、命名與授權記錄方式，之後回查或更換素材會容易許多。

把這套流程變成習慣，網站就不會再被圖片拖回去

圖片優化的勝負，從來都在上傳前那三十秒的基本功，外掛的強弱是次要的。外掛是保險、延遲載入是調度、CDN 是交付，這些都重要，但它們都在槓桿曲線的尾端，救不回一張一開始就沒顧好的原圖。

給你一個現在就能做的行動方案：

1. 從高流量頁面開始，確認首圖與首屏圖的實際下載尺寸和 LCP 狀態。
2. 跑一次測速，記下目前的 LCP，替換後再跑一次，用數字驗證前後落差。
3. 啟用一套壓縮外掛當保險，設定成「保留原檔備份」的安全模式。
4. 把首屏圖設為優先載入、版面下方的圖延遲載入。
5. 從下一篇新文章開始，固定走一次上傳前檢查表。

圖片處理完成後，再依測速結果評估 快取與 CDN；它們能改善重複請求與傳輸距離，但不能取代合理的原圖尺寸。若瓶頸在主機或 JavaScript，應把時間用在真正影響載入的項目。

一張圖從授權、檔名、尺寸、格式、壓縮到前台交付，每一步處理的風險不同。把上傳前規格固定下來，再用外掛、延遲載入與 CDN 補上自動化，會比只在網站變慢後才補救更容易維護。