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

裝了圖片壓縮外掛、開啟延遲載入，LCP 仍可能偏慢。先查看真正的 LCP 元素、圖片下載尺寸與載入時序，再判斷瓶頸來自原檔、交付設定、主機還是其他資源。

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

重點摘述

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

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

先確認圖片是否是 WordPress 的效能瓶頸

圖片常占用不少頁面傳輸量，但每個網站的裝置分布與主要瓶頸不同。請先用自己的流量資料和瀏覽器 Network 記錄確認：哪些圖片被下載、使用多大尺寸、傳輸多久，再安排優化順序。

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 或外掛

尺寸遠超顯示需求時，先縮放通常能減少待處理像素。部分外掛或圖片 CDN 也能自動完成縮放與轉檔；選擇手動或自動流程時，要看能否穩定產生合適的檔案，而不是預設某一種工具一定較有效。

可以把上傳前規格與自動化搭配使用：編輯者先確認構圖、授權和必要細節，再由已測試的外掛產生尺寸與格式。避免連續多次有損重編碼，並保留可重新匯出的來源檔。

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

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

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

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

圖片尺寸要根據實際 CSS 顯示寬度、裝置像素密度與放大需求決定。顯示寬 800 CSS 像素、目標密度 2x 時，1600 像素可作為一個候選尺寸；高密度螢幕、較寬版面或商品放大檢視可能需要其他尺寸，兩倍不是通用上限。

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

WordPress、主題與外掛可能註冊多種縮圖，但實際產生哪些檔案，還取決於原圖尺寸、裁切方式、格式與處理設定。上傳大圖也可能保留原檔和縮放版。估算儲存、備份與壓縮額度時，應抽查實際附件檔案；圖片數量則依內容需要決定，不以多放小圖取代合理編排。

在不同螢幕寬度下，用瀏覽器開發者工具查看圖片的顯示尺寸、實際下載檔案與 srcset／sizes。依裝置像素密度準備合適候選圖，再確認瀏覽器是否下載了預期尺寸。不同版位可訂出各自規格，無須用同一個長邊上限處理所有圖片。

可依版位建立圖片規格，以下是檢查方向，不是固定像素上限：

• 文章內文實景相片：依內文欄寬與目標像素密度準備候選尺寸。
• 首圖與全寬橫幅：測量桌面與手機版面，必要時準備不同裁切。
• 產品圖：同時考慮列表、商品頁與放大檢視所需細節。
• 圖表與截圖：依文字清晰度與顯示尺寸測試，必要時提供可放大版本。
• Logo 與圖示：點陣檔依顯示需求輸出；向量檔須確認來源與安全處理。

以足夠清楚且能有效交付為原則，讓瀏覽器透過 srcset／sizes 選擇合適檔案；不要為了固定倍數犧牲細節，也不要一律傳送大型原檔。

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

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

JPG 適合許多實景相片，支援廣泛但沒有透明背景；反覆有損重編碼可能累積失真。PNG 適合需要透明或保留精確像素的圖片，但未必比 WebP 或其他格式小。請以同一張圖比較畫質與檔案體積，不以格式名稱直接判定最佳結果。

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

判斷的兩個維度很直觀：

• 色彩與細節：相片可比較 JPG、WebP 或 AVIF；文字與圖形可比較 PNG 或無損 WebP，向量原稿也可評估 SVG。
• 是否需要放大檢視：商品與圖表要保留必要細節；裝飾圖也要檢查漸層、邊緣與放大後品質，不宜無條件壓到最低。

先依內容選擇候選格式，再看實際編碼結果。WordPress 支援 WebP，也可在主機影像函式庫支援時使用 AVIF；不必為了轉檔而一律先上傳 JPG。SVG 則需另行確認安全的上傳與清理方式。

↔ 左右捲動檢視完整表格

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

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

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

上傳前處理、轉檔與外掛自動化如何搭配

圖片可在匯出、上傳或交付時處理。依團隊流程分工，避免不同工具重複改寫同一張圖。

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

第二層是格式轉換。可以從保留的高品質來源直接輸出 WebP 或 AVIF，也可以交由已測試的外掛或 CDN 產生。轉成有損格式同樣屬於重新編碼，仍需比較細節，不應把轉檔當成完全不影響畫質的步驟。

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

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

品質參數的範圍與效果依格式和編碼器而異，同樣的數字不能跨工具比較。先測試數個品質設定，檢查文字、邊緣、漸層與商品細節，再選出畫質可接受且體積較小的版本；不要固定使用 70 或 80，也不必對已合適的檔案再壓一次。

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

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

原生 loading="lazy" 讓瀏覽器在圖片接近視窗時再下載，但觸發距離依瀏覽器與連線狀態不同，未滾到仍可能預先下載。WordPress 會依上下文處理圖片載入屬性，較新版本也會嘗試辨識優先圖片；自訂版面仍須檢查實際輸出的 HTML。

可能成為 LCP 的圖片應能及早被發現，通常不適合延遲載入。確認實際 LCP 元素後，可對該圖片使用 fetchpriority="high" 提示較高優先順序，但它不能抵消 loading="lazy" 的延遲，也不應套在每一張首屏圖上。

判斷原則可以這樣記：

• Above the fold（首屏可見）的圖：不延遲；確認是 LCP 圖片後，再考慮設定 fetchpriority="high"。
• Below the fold（要往下滾才看到）的圖：延遲載入，省下初期載入。
• 背景裝飾大圖：先確認是否需要；首屏背景可能是 LCP，不應一律延遲。CSS 背景圖不接受 img 的 loading 屬性，需由相應版面或腳本實作。

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

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

還有一個觀念要先分清楚：延遲載入不改變檔案大小，只改變載入順序。它可降低初期下載量；若使用者離開前未觸發其他圖片下載，也可能減少實際總傳輸量。別以為掛了延遲載入就不用壓圖，那是兩件不同的事。想把延遲載入的機制、外掛做法與常見陷阱弄清楚，可以再看 Lazy Loading 延遲載入的專篇。

依圖片用途決定格式、尺寸與處理重點

相片、介面截圖與標誌需要的清晰度不同。下表提供格式與尺寸的起點，仍須比較實際畫質、下載量與顯示尺寸，再決定輸出設定。

↔ 左右捲動檢視完整表格

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

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

SVG 適合以路徑繪製的 Logo、圖示與簡單插畫，但也可能內嵌點陣圖片，並非所有 SVG 都能任意放大或保證較小。WordPress 預設不直接允許一般 SVG 上傳；如需使用，應採可信的清理機制並限制上傳權限，不能只開放副檔名檢查。

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

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

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

創用 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. 先備份，抽樣確認回溯壓縮的品質、可還原方式與額度，再分批處理舊圖；是否在背景執行須依外掛實作確認。
4. 同時把延遲載入與首圖優先載入設定好，讓現有圖片的載入順序先合理化。
5. 持續把「上傳前處理」變成新文章的固定流程，舊的慢慢還，新的不再欠債。

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

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

不必為了整理而把媒體庫全部刪掉重來。先處理影響重要頁面載入的檔案，保留正在使用的 URL 與來源備份；較少流量的頁面也可能有嚴重問題，只是安排處理順序時可一併考慮影響人數。

上傳前檢查表：固定流程

每張圖片上傳前可依下列項目檢查；授權與品質確認所需時間依素材而異，不必追求固定秒數。

• 授權：保存素材頁與授權紀錄，確認商用、改作、標示及其他限制。
• 檔名：改成有意義的描述性檔名（例如 wordpress-image-optimization-guide.webp），別用 IMG_2049.jpg。
• 尺寸：依最大顯示寬度、裝置像素密度與放大需求裁切。
• 格式：依內容比較 JPG、WebP、AVIF 或 PNG；SVG 適合向量素材，但須有安全的上傳與清理方式。
• 壓縮：用可信的壓圖工具比較前後體積與畫質。
• alt 文字：依圖片在此處的用途提供替代文字；純裝飾圖使用空 alt，圖表的重要資訊也應能從正文讀到，不堆疊關鍵字。

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

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

讓圖片處理流程持續符合版面需求

上傳前規格能減少返工，外掛與 CDN 也能補做縮放、轉檔與交付優化。把來源備份、處理設定和前台驗證串在一起，比只依賴某一階段更容易找出問題。

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

1. 從高流量頁面開始，確認首圖與首屏圖的實際下載尺寸和 LCP 狀態。
2. 跑一次測速，記下目前的 LCP，替換後再跑一次，用數字驗證前後落差。
3. 若需要自動化，選擇一套適合的處理工具，確認原檔備份與還原流程，避免功能重疊。
4. 確認 LCP 圖片可及早載入，只對必要資源提高優先順序；畫面外且適合延後的圖片再使用延遲載入。
5. 從下一篇新文章開始，固定走一次上傳前檢查表。

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

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