WordPress 圖片壓縮指南：Smush 外掛安裝設定

一張沒壓過的商品圖，可能同時拖慢載入與轉換

用手機打開 WordPress 網站，商品主圖卻遲遲沒有出現，原因可能包括圖片過大、請求太晚或主機回應慢。Smush 可協助處理圖片壓縮與載入設定；先找到瓶頸，再用畫質和實際請求驗證調整結果。

全球行動裝置流量佔比長期維持在高檔，2026 年第一季的 Statista 數據顯示，行動版網頁流量約佔整體網路流量的六成上下。Google 開發者文件也指出，緩慢的回應會影響使用者體驗與轉換，而速度改善的成果應該以自身數據驗證。圖片若沒有適當縮圖與壓縮，會增加訪客的等待時間，也可能間接影響轉換表現。

圖片經常是 WordPress 頁面裡體積較大的資源，尤其是直接上傳相機或手機原檔時。實際影響仍要看圖片尺寸、格式、數量與連線環境，所以不要先猜原因，應該從頁面測速和網路請求著手確認。

這篇會帶你走一次 Smush 的安裝、設定與延遲載入流程。免費版能處理常見的壓縮與延遲載入需求，但各功能仍以目前版本、方案及介面顯示為準。重要開關背後的取捨也會逐一說明，讓你知道自己在動什麼、為什麼動。

如果你之前完全沒碰過外掛安裝，建議先看過 WordPress 外掛安裝教學 把基本功練好，再回來跟著這篇設定 Smush。

為什麼是 Smush：WordPress 圖片壓縮外掛的選擇邏輯

市面上圖片壓縮外掛十幾款，常有站長問「到底裝哪一個」，答案都是同一句話：先想清楚瓶頸是什麼，再選工具，不要倒過來。

Smush 的定位很明確：圖片上傳後可自動壓縮，也提供延遲載入等功能。設定完成後仍要定期抽查新圖片與前台輸出，避免外掛更新、佈景主題或快取設定改變後出現漏壓或重複處理。

WordPress 從 5.5 開始支援原生 loading="lazy"，後續版本也改善了首屏判斷與 fetchpriority；並非所有圖片一律延遲，開發者也能透過屬性與 filter 調整。Smush 的價值是提供圖形化設定與排除規則，實際是否需要，要看原生輸出是否已符合需求。避免同時使用多套延遲載入機制，啟用後應檢查首屏、LCP 圖片與下方圖片的請求時序。

下表把 Smush 與其他兩種常見路線放在一起比較：

如果圖片會持續增加、又沒有工程團隊維護自訂流程，Smush 這類自動化外掛會比較省事。想了解其他路線，可以參考 圖片壓縮工具實測推薦，再依圖片量、格式需求與預算選擇。

老實說，工具選哪一個沒有那麼神聖。真正決定你網站快不快的，是你有沒有把壓縮這件事變成常態化的流程，而不是裝了外掛就覺得萬事太平。下面從安裝前的準備開始，一步步把這個流程建起來。

安裝前的關鍵一步：先量測你現在的「圖片體重」

很多站長一裝好 Smush 就急著把所有設定打開、跑批次壓縮，跑完才發現網站速度沒有想像中改善。為什麼？因為根本不知道問題出在哪。也許圖片只佔載入量的一半，另一半是沒快取的 PHP 動態請求、也許是主機回應太慢。你沒量測，就是在矇著眼睛調整。

安裝 Smush 之前，請先做三件量測：

1. 用 PageSpeed Insights 跑一次首頁和流量最高的文章頁。把「最大內容繪製（LCP）」的數字和「圖片」相關建議截圖存下來。這是你的基準線，壓完圖之後要拿同一個頁面再跑一次對比。如果你還不熟悉這個工具的操作，先看過 網站速度測試工具推薦 這篇，把檢測流程弄熟。
2. 檢查媒體庫與前台實際載入的圖片。媒體庫原檔很大，不代表前台一定載入原檔；反過來說，單張圖片不大，累積起來仍可能拖慢頁面。請用瀏覽器開發者工具確認實際下載的檔案與尺寸。想知道完整診斷思路，可以對照 網站慢怎麼辦的診斷與解法。
3. 確認其他載入瓶頸。主題、外掛、第三方指令碼與主機回應也可能影響速度；只做圖片壓縮，不一定能解決整頁的效能問題。

把這些量測結果記下來。等一下 Smush 跑完，你會感謝自己有先量。

這裡也要提醒一個很多人漏掉的事：圖片格式本身就決定了壓縮的天花板。一張用 PNG 存的全彩照片，再怎麼壓也很難比同畫質的 JPEG 小。如果你連格式都選錯，Smush 再強也只能在錯誤的基礎上做微調。不確定 JPG、PNG、WebP 到底怎麼選的話，先讀過 圖片格式深度比較 再回來，後面的設定會更有感。

Smush 免費版完整安裝流程

安裝本身沒有難度，但有幾個容易卡住的小地方先講出來，免得你裝完發現「怎麼跟預期的不一樣」。

步驟一：從外掛目錄安裝。進 WordPress 後台，左側選「外掛」然後「安裝外掛」，搜尋 Smush。你要找的是由 WPMU DEV 開發、名稱裡帶「Smush」字樣的那一個。安裝後啟用。

步驟二：初次設定精靈。啟用後 Smush 會引導你過一個簡短的設定流程，問你要不要啟用壓縮、延遲載入這類基本項目。這個精靈幫你把常用的開關一次打開，但走完精靈之後，建議手動再進「Smush」設定頁逐項確認，因為精靈的預設值不見得最適合你的站。之後我們在下一節會逐項講。

步驟三：檢查系統狀態與錯誤訊息。批次處理若失敗，可能和記憶體、執行時間、迴路請求、外掛衝突或主機限制有關，沒有適用所有網站的固定記憶體數字。先看 Smush 的錯誤訊息與 WordPress「網站健康狀態」，再依主機環境調整。

正因如此，主機品質直接決定外掛能不能發揮。一台回應慢、記憶體摳門的主機，再好的快取和壓縮外掛都會被綁手綁腳。如果你的站已經長大到某個規模，值得認真評估換一點等級夠的主機，可以從 WordPress 主機 的方向開始研究。

安裝過程還可能遇到圖片處理功能重疊。若同時啟用多套壓縮、WebP 或延遲載入功能，可能重複處理同一張圖。測試環境允許時，可以先停用一半的可疑外掛，再依結果縮小範圍；正式站操作前先備份，並避開流量高峰。

Smush 啟用後，媒體庫會顯示圖片的處理狀態。若長時間停在等待或出現錯誤，不要直接認定是記憶體不足；請一併檢查外掛記錄、網站健康狀態、迴路請求及主機錯誤記錄。

決定壓縮成敗的五個 Smush 設定開關

Smush 的設定頁有一整排開關，看起來眼花，但真正決定壓縮效果的其實只有五個。每個的取捨逐一講清楚，你照自己的狀況開。

壓縮層級（Super Smush）

Smush 目前把 Basic Smush 定位為無損壓縮，Super Smush 則是有損壓縮；連接 Hub 的免費帳號也可使用 Super Smush，Ultra Smush 才是 Pro 層級。方案與命名可能隨版本調整，設定前應以外掛當下顯示為準（可查 WordPress.org 上的 Smush 頁面）。

若要處理大量舊圖，先用少量樣本比較 Basic 與 Super 的體積和畫質，再決定是否套用整個媒體庫。商品細節、攝影作品等對畫質敏感的圖片，更應先在不同螢幕尺寸抽查。

自動壓縮上傳的圖片

自動壓縮適合希望新上傳圖片沿用同一規格的網站。若素材已在上傳前完成有損壓縮，或需要逐張審核畫質，可改用手動流程，避免重複有損處理；開啟後也要抽查前台實際使用的尺寸版本。

原始圖片備份

如果目前方案提供原始圖片備份，開啟後可在畫質不符預期時還原；代價是占用額外儲存空間。這項功能的可用性與保存方式以目前方案說明為準。

主機空間有限時，可以在確認備份位置、還原流程及壓縮品質後再評估是否保留。不要把外掛內的原檔備份當成網站備份；重要素材仍應獨立保存。

調整大型圖片尺寸

大型圖片縮放功能可在上傳時限制寬高，但目前是否可用取決於版本與方案。若介面沒有這個選項，可在上傳前縮圖，或使用 WordPress 既有的大圖縮放機制。

例如商品照的原始像素遠高於前台顯示需求時，先縮到合理尺寸，通常比只調整壓縮品質更有效。實際檔案大小會受內容、格式與品質設定影響，不宜預設固定縮幅。

最大尺寸應依內容欄寬、全寬版面、裝置像素密度與圖片是否允許放大來決定。不要直接套用固定像素；先確認前台實際顯示寬度與 srcset，再保留足夠解析度。

移除不需要的中繼資料

相機與手機照片可能帶有拍攝時間、相機型號、GPS 座標等 EXIF 中繼資料。一般內容圖片可移除不需要的資料以減少體積並避免位置資訊外洩；攝影作品、著作權管理或特定工作流程若需要保留欄位，應先確認再開啟。

順帶一提，如果你經營的是 WooCommerce 電商站，商品圖的尺寸規範要特別注意。WooCommerce 會根據你的佈景主題設定，自動產生多種尺寸的縮圖（商品目錄用、單品頁用、購物車小圖用）。Smush 可處理產生的尺寸版本，但實際範圍仍受設定、檔案限制與處理結果影響。但如果你改過 WooCommerce 的圖片尺寸設定，應確認縮圖已依新尺寸重建；WooCommerce 在相關設定變更時可觸發背景重建，必要時再依工具狀態重新產生，並核對壓縮結果。尺寸重建與壓縮是不同工作。電商站的圖片 SEO 還牽涉到結構化資料和 alt 文字，這部分可以搭配 商品頁 SEO 優化手冊 一起看。

五個開關整理成檢查表：

Bulk Smush 批次壓縮：處理大量舊圖的正確節奏

設定都調好之後，接下來是重頭戲：用 Bulk Smush 把媒體庫裡現有的舊圖全部壓過一遍。這一步也是最多人卡關的地方。

目前版本支援背景處理與不中斷的批次壓縮，不再以固定張數作為免費版的批次上限。不過主機資源、迴路請求或 API 錯誤仍可能讓工作停住，應以畫面提示與記錄判斷原因（版本特性可查 Smush 在 WordPress.org 的外掛頁）。

媒體庫累積大量商品圖時，批次工作仍可能需要較長時間。官方目前說明免費版會略過超過 5 MB 的圖片，這類檔案可先在本機縮圖或改用支援更大檔案的方案；限制若有變動，以外掛當下提示為準。

跑 Bulk Smush 的正確節奏，整理成幾個要點：

• 讓背景工作完成並留意錯誤。大量圖片需要時間，若進度長時間不動，再檢查網站健康狀態、主機記錄與外掛提示。
• 特別大的圖先手動處理。如果媒體庫裡有單張超過 5 MB 的圖，建議先下載到本機用影像編輯軟體縮到合理尺寸再重傳，不要硬丟給 Smush 處理，免費版會略過超過上限的檔案；若更換素材，需確認原網址、附件關係與使用中的頁面不受影響。
• 跑完之後檢查壓縮報告。如果部分圖片節省比例較低，可能是原檔已壓縮、內容不易壓縮或格式選擇所致，應搭配畫質與實際檔案判斷。
• 開啟 Directory Smush 處理佈景主題圖片。媒體庫裡的圖只是你網站圖片的一部分，你的佈景主題和某些外掛自帶的圖片（放在 wp-content 的資料夾裡，不在媒體庫管理範圍）Smush 預設壓不到。免費版的 Directory Smush 功能讓你手動指定資料夾掃描壓縮，先確認目錄和檔案由誰維護，備份後用少量樣本測試；主題或外掛更新可能覆寫這些檔案。

批次完成後，查看成功、略過與失敗的項目，抽查體積和畫質，再到前台確認實際下載的圖片。媒體庫顯示已處理，不代表每個頁面的圖片交付與載入順序都已最佳化。

在媒體庫裁切、旋轉或重建縮圖後，應查看新尺寸的處理狀態。啟用自動壓縮時，Smush 可處理產生的圖片副本，但整合方式、工作錯誤或限制仍可能造成漏處理；需要時重新掃描或手動處理，並抽查實際檔案，不要一概認定所有新尺寸都必須手動重壓。

Lazy Loading 延遲載入：有效，但有兩個地雷

延遲載入（Lazy Loading）的概念很簡單：網頁打開時只載入畫面看得到的那幾張圖，下面的圖等使用者捲動到接近時才開始下載。實際提前載入範圍取決於瀏覽器或外掛策略，初始請求數與速度改善幅度要從網路面板量測。

Smush 內建延遲載入功能，免費版就能用。啟用方式很直覺：在 Smush 設定頁找到 Lazy Loading 區塊，打開總開關，然後逐一選擇你要套用的元素類型（圖片、iframe 影片、背景圖等等）。

但延遲載入有兩個地雷，踩到反而會讓你的 SEO 表現變差。

地雷一：首屏圖片不要延遲載入

延遲載入的代價是圖片出現的時間會延後一點點（瀏覽器原生或 JavaScript 實作會依載入條件延後請求）。對於在畫面第一屏就看得到的圖，尤其是你的 LCP 元素（通常是文章首圖或 Hero 區塊的大圖），延遲載入會直接拖慢最大內容繪製的時間，適得其反。

先辨識實際 LCP 圖片，再用目前 Smush 提供的排除設定或支援的 no-lazyload 類別排除。只更改 loading="eager" 不一定能覆蓋外掛的 JavaScript 延遲邏輯；儲存並清除相關快取後，確認 HTML 含真實圖片網址，且圖片請求沒有等到捲動才發出。

LCP 是 Core Web Vitals 的一部分。Google 說明良好的頁面體驗可能有助於搜尋表現，但相關訊號有限，內容相關性仍更重要。如果你對這些指標還不熟，可以先讀 Core Web Vitals 完整攻略，再回來調整延遲載入。

地雷二：圖片不能只靠捲動事件才出現

Google 支援延遲載入，但內容不應依賴使用者捲動或點擊才載入。圖片應在頁面渲染時可被發現，例如使用原生 loading="lazy"，並在 src 或 srcset 提供實際圖片網址；完成後可用網址檢查工具確認渲染結果。

這不是叫你停用延遲載入。首屏與 LCP 圖片應直接載入，畫面下方的圖片可以延遲載入，但要確認網址可被渲染與索引。想深入理解實作方式，可以看 Lazy Loading 延遲載入實戰指南。

WebP 轉檔這件 Smush 免費版做不到的事

WebP 同時支援有損與無損壓縮，許多圖片在相近視覺品質下可比舊格式更小；實際差異取決於原圖與編碼設定，不能用固定百分比概括。

問題來了：Smush 免費版沒有 WebP 轉檔功能。你要嘛升級到 Smush Pro，要嘛用別的方法產生 WebP 檔案。

這裡提供三條路線，依你的技術 comfort level 選：

路線一：使用 Smush Pro。目前 Pro 可透過 CDN 或本機轉換提供 WebP、AVIF；實際交付方式與伺服器需求依所選模式而異，設定後仍須驗證實際格式、回退行為、快取與 CDN 配額。

路線二：用另一個外掛專門做 WebP 轉檔。可由專用外掛處理媒體庫轉檔，Smush 負責其他壓縮工作。兩套工具並用前要先確認是否重複壓縮、改寫網址或延遲載入。

路線三：在上傳之前就轉好。如果你產圖的流程是固定的（例如都用同一台相機、同一套修圖軟體），可以在本機先把圖存成 WebP 再上傳。這樣完全不需要外掛處理轉檔，再依 Smush 對該格式和尺寸的支援決定是否需要額外壓縮。缺點是每張圖都要多一個手動步驟。

圖片量不多時，可在本機先轉檔；多人上傳或圖片量大時，自動化方案通常較實際。WebP 不是萬靈丹，仍要同時處理尺寸與品質；格式轉換前後也要比較實際體積。

WebP 的交付方式不只一種，可以直接在 HTML 使用 WebP，也可以透過 <picture>、CDN 或伺服器規則選擇格式。採用哪一種要看外掛、快取、CDN 與主機架構；轉檔後應在瀏覽器網路面板確認前台實際收到的格式，不能只看媒體庫是否產生檔案。

想知道 WebP 在整體圖片優化策略裡的位置，搭配 WordPress 圖片優化指南 一起看會更完整。壓縮只是圖片優化的一環，檔案命名、alt 替代文字、結構化資料這些 圖片 SEO 的基本功也不能漏，這些資訊能協助理解圖片與頁面關係；壓縮大小本身不會保證圖片搜尋曝光。

壓完圖之後的驗收：用 Core Web Vitals 確認真的變快

壓縮跑完、延遲載入開好，不代表工作結束。你必須回到一開始量測的那幾個頁面，用同一套工具再跑一次，看看數字到底改善了多少。沒有驗收的優化，跟沒做差不多。

驗收要看三個數字：

縮小 LCP 圖片可減少下載時間，但若圖片仍等候 JavaScript、樣式或主機回應，整體 LCP 未必同幅改善。延遲載入也不必然造成 CLS；主要風險是在圖片載入前沒有保留正確空間。先看 LCP 各階段與位移來源，再調整相應設定。

解法是確保圖片有明確的寬度與高度屬性，讓瀏覽器在下載前先保留空間。WordPress 區塊編輯器通常會輸出這些屬性；Smush Pro 也提供修正缺少尺寸屬性的功能。無論使用哪一種方式，都要在前台檢查實際 HTML。

驗收時也要看真實使用者數據，不要只看單次實驗室測試。Google Search Console 的 Core Web Vitals 報表採用最近二十八天的 Chrome 使用者體驗資料，並以相似網址群組呈現；它與單次測試用途不同，兩者應搭配解讀。如果你還沒使用這個報表，可以從 Google Search Console 教學 開始。

壓縮前後的數字對比，建議用一個簡單的表格記下來：

• 壓縮前 LCP：幾秒（哪一頁）
• 壓縮後 LCP：幾秒（同一頁）
• 圖片總體積下降比例：百分之多少
• Bulk Smush 處理的圖片總數：幾張

這份記錄不只是給自己看，未來你如果要做網站速度的整體改善報告、或跟合作夥伴討論優化成效，這些數字就是最有說服力的證據。

驗收的時候也要注意一個心理陷阱：PageSpeed Insights 同時提供可用的真實使用者資料與 Lighthouse 實驗室診斷；下方效能分數不能代替上方 CrUX 指標。同一個網站在不同時間測、用不同地點的伺服器測，分數可能因測試條件和伺服器狀態而變動。不要為了追逐那個 90 分以上的綠色數字而過度優化，例如把圖片壓到畫質明顯劣化只為了分數好看，那是本末倒置。真正該盯的是 LCP 從幾秒降到幾秒、真實使用者的跳出率有沒有改善、轉換率有沒有跟著動。分數是參考，使用者行為才是答案。你可以用 GA4 工作階段報表 觀察優化前後的跳出率與平均工作階段時間變化，並核對所用指標定義；流量來源、內容和活動也會影響這些數據，不能只從前後變化推定壓縮的因果效果。

如果你的站已經做過一輪圖片優化、分數還是卡在某個區間上不去，瓶頸往往已經從圖片轉移到 JavaScript 載入量、第三方追蹤碼、或主機的伺服器回應時間（TTFB）上頭了。這些問題 Smush 一個都解決不了，需要從 技術 SEO 的角度做更系統的盤點。把力氣花在真正的瓶頸上，別再重複雕已經夠好的圖片。

Smush 解決不了的情境：什麼時候你該換工具

Smush 並非萬能。有些情境它真的幫不上忙，硬撐著只用它反而會讓你錯過更根本的問題。以下幾種情況，Smush 不是答案：

情境一：你的圖片已經很小，但網站還是慢。單張不到 500 KB 或壓縮率偏低，都不足以排除圖片瓶頸；還要看總張數、實際下載尺寸、發現時間與 LCP 元素。這時候要往快取、資料庫查詢、主機回應時間方向找問題。先讀 快取 Cache 指南 和 WordPress 快取外掛比較，依量測結果判斷是否需要頁面快取，並排除不能共用快取的會員或交易內容。

情境二：你的流量是跨國的，圖片傳輸距離很遠。單純壓縮不能改變原站與訪客的距離；Smush Pro 另有圖片 CDN，或可使用其他相容 CDN。如果你的讀者分散在不同洲，不管圖壓到多小，跨洋傳輸的延遲還是在。CDN 可透過分散節點縮短部分傳輸路徑，實際成效仍受節點選擇、快取命中與網路條件影響。CDN 的原理和選擇，可以從 CDN 網站加速指南 開始了解。

情境三：電商頁面還有其他效能瓶頸。商品頁可能同時受圖片、頁面快取、動態購物功能、第三方指令碼與主機回應影響，光靠 Smush 不一定足夠。先以測速瀑布圖確認瓶頸，再決定是否需要快取、主機或程式調整；商品頁的內容與搜尋設定則應另外依 WooCommerce SEO 流程檢查。

情境四：你的網站圖片來源很雜，有大量外部嵌入圖。有些站的圖片不是全部存在自己的媒體庫，而是透過 iframe 嵌入第三方平台（社群貼文、地圖、外部圖床）。Smush 不會直接改寫第三方 iframe 內的素材；對頁面上的外部 img、CDN 和媒體卸載整合，則需核對來源支援與設定。第三方 iframe 內的媒體，則由來源平台管理。如果你的頁面體積有一半是外部資源造成的，Smush 再怎麼壓也只能動到另一半。這種情況要從減少外部嵌入數量、或改用延遲載入把第三方資源的影響降到最低。

把這些情境記在心裡，就不容易陷入「裝對外掛網站就會快」的迷思。工具是手段，目的是改善真實使用者的載入與互動體驗。

如果你想看 WordPress 速度優化的完整工具盤點，WordPress 網站加速外掛實測 和 網站速度優化指南 兩篇加起來會給你一張完整的全景圖。

可逐步執行的圖片優化行動清單

讀到這裡，你腦袋裡可能塞了一堆設定細節。下面把這些收斂成一份今天就能動手執行的清單，照著走一遍，你的圖片優化基本功就算打好了。

1. 量測基準線。用 PageSpeed Insights 跑你的首頁和流量最高的一篇文章，記下 LCP 數字和圖片相關建議。同時以網路面板查看前台實際下載的大圖；WordPress 核心媒體庫不一定提供依檔案大小排序。
2. 安裝並設定 Smush。先用少量圖片比較壓縮層級與畫質，再決定自動壓縮、備份、大圖縮放及中繼資料設定。
3. 跑 Bulk Smush 批次壓縮。讓背景工作完成並檢查錯誤；免費版略過的超大圖片先縮小再重傳。若要處理媒體庫外的本機圖片，再評估 Directory Smush。
4. 啟用延遲載入並避開地雷。依工具支援方式排除首屏與 LCP 圖片；畫面下方圖片可延遲，但需可被發現並保留尺寸空間。
5. 決定你的 WebP 策略。依你的站點規模和技術能力，從升級 Pro、裝第二個外掛、或本機預先轉檔三條路線裡選一條。
6. 重新量測並記錄。用同一個頁面再跑一次 PageSpeed Insights，比較 LCP 的變化。進 Google Search Console 看 Core Web Vitals 報表，在資料足夠且二十八天視窗逐步更新後觀察趨勢，即時驗收先看實際請求與測試結果。

這六步走完，就建立了一套可重複的圖片優化流程。後續可依內容發布頻率定期抽查自動壓縮、異常大檔案與主要頁面的 LCP。

如果圖片處理完成後速度仍未改善，下一步應回到實測資料，檢查主機回應、快取、JavaScript 與第三方資源，而不是繼續加重圖片壓縮。