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

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

你也許曾有過這種經驗？用手機打開自己的 WordPress 網站，等了三秒、五秒，那張精心拍攝的商品主圖才慢慢浮現。你心裡想「還好啦，有跑出來就好」，但你的訪客早就按了上一頁，跑去找下一個對手了。

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

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

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

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

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

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

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

有一個很多人會問的問題：Smush 和瀏覽器原生延遲載入有什麼差別？現在主流瀏覽器都支援 loading="lazy" 這個 HTML 屬性，WordPress 從 5.5 版開始也預設會自動為圖片加上這個屬性。那 Smush 的延遲載入功能到底還有什麼存在價值？差別在於控制粒度。原生做法是全部圖片一律套用，你沒辦法精細地說「這張首圖不要延遲、那個 iframe 影片要延遲」。Smush 給你的是一個圖形化介面，讓你針對不同元素類型個別開關，還能排除特定頁面或特定 class 的圖片。對簡單的部落格這層控制可能用不到，但對版面複雜、圖片種類多的電商站或媒體站，這個彈性就很實際。

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

選擇路線	代表工具	最適合誰	主要代價
外掛一鍵壓縮（本篇主角）	Smush	不想碰指令列、媒體庫已累積大量圖片的站長	進階格式轉檔需付費版
獨立壓縮工具手動處理	瀏覽器版或桌面版壓縮工具	圖片數量少、想在傳上去之前精準控制的設計師	每張都要手動跑，量大很累
伺服器端批次腳本	ImageMagick、cwebp 指令	有技術力、幾萬張圖要處理的大型站	設定門檻高，出錯除錯難

如果圖片會持續增加、又沒有工程團隊維護自訂流程，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 的體積和畫質，再決定是否套用整個媒體庫。商品細節、攝影作品等對畫質敏感的圖片，更應先在不同螢幕尺寸抽查。

自動壓縮上傳的圖片

這個開關控制的是「未來你傳上新圖時，Smush 要不要自動在背景壓縮」。一定要開。關掉它的話，你每次上傳完還要手動到媒體庫一張張點壓縮，那跟沒裝這個外掛差不多。

原始圖片備份

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

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

調整大型圖片尺寸

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

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

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

移除不需要的中繼資料

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

順帶一提，如果你經營的是 WooCommerce 電商站，商品圖的尺寸規範要特別注意。WooCommerce 會根據你的佈景主題設定，自動產生多種尺寸的縮圖（商品目錄用、單品頁用、購物車小圖用）。Smush 壓縮時會把這些自動產生的版本一起處理，所以你不用擔心某一個尺寸漏掉。但如果你改過 WooCommerce 的圖片尺寸設定，記得重新產生縮圖（用 Regenerate Thumbnails 這類外掛），否則舊的縮圖會停留在壓縮前的狀態。電商站的圖片 SEO 還牽涉到結構化資料和 alt 文字，這部分可以搭配 商品頁 SEO 優化手冊 一起看。

五個開關整理成檢查表：

設定項目	實務建議	注意事項
Super Smush 進階壓縮	先以少量圖片比較再決定	有損壓縮，需抽查畫質
自動壓縮上傳圖片	必開	關掉等於手動壓，不實際
原始圖片備份	依方案與備份策略決定	不可取代完整網站備份
調整大型圖片尺寸	依前台實際顯示需求設定	可用性依版本與方案而異
移除中繼資料	一般網站可開啟	需保留版權資料者先確認

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

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

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

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

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

• 讓背景工作完成並留意錯誤。大量圖片需要時間，若進度長時間不動，再檢查網站健康狀態、主機記錄與外掛提示。
• 特別大的圖先手動處理。如果媒體庫裡有單張超過 5 MB 的圖，建議先下載到本機用影像編輯軟體縮到合理尺寸再重傳，不要硬丟給 Smush 處理，否則它要花很久的時間壓一張圖，而且壓縮率反而不如先縮再壓。
• 跑完之後檢查壓縮報告。如果部分圖片節省比例較低，可能是原檔已壓縮、內容不易壓縮或格式選擇所致，應搭配畫質與實際檔案判斷。
• 開啟 Directory Smush 處理佈景主題圖片。媒體庫裡的圖只是你網站圖片的一部分，你的佈景主題和某些外掛自帶的圖片（放在 wp-content 的資料夾裡，不在媒體庫管理範圍）Smush 預設壓不到。免費版的 Directory Smush 功能讓你手動指定資料夾掃描壓縮，記得跑一次把主題圖片也清乾淨。

跑完 Bulk Smush 之後，你的媒體庫裡應該每張圖旁邊都會顯示一個綠色的「已壓縮」標記和節省的檔案大小。到這裡，靜態的壓縮工作就算完成了。但這只做了一半，接下來的延遲載入才是真正影響使用者感受的關鍵。

有一個你會想知道的細節：Smush 壓縮過的圖，如果你之後在媒體庫編輯器裡做了裁切或旋轉，WordPress 會重新產生那張圖的各種尺寸版本，而這些新版本不會自動被 Smush 壓過。你要手動回到媒體庫列表，對那張圖再點一次 Smush 壓縮。這是個小坑，但如果你大量編輯舊圖之後忘記重壓，等於那些修改過的圖又回到未壓縮的狀態，前面省下的體積就白費了。養成習慣：動過的圖，重新跑一次壓縮。

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

延遲載入（Lazy Loading）的概念很簡單：網頁打開時只載入畫面看得到的那幾張圖，下面的圖等使用者捲動到接近時才開始下載。對一篇文章放十張圖的頁面來說，這等於把初次載入的圖片量從十張砍到兩三張，首屏速度立刻有感。

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

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

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

延遲載入的代價是圖片出現的時間會延後一點點（要等 JavaScript 判斷捲動位置再觸發下載）。對於在畫面第一屏就看得到的圖，尤其是你的 LCP 元素（通常是文章首圖或 Hero 區塊的大圖），延遲載入會直接拖慢最大內容繪製的時間，適得其反。

Smush 有提供「跳過首屏圖片」的選項，把它勾起來。如果你用的是比較舊版的 Smush 沒有這個選項，那就要手動在首圖的 img 標籤加上 loading="eager" 或移除 loading="lazy" 來排除它。

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；實際交付方式與伺服器需求依所選模式而異，照官方設定精靈操作即可。

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

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

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

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

想知道 WebP 在整體圖片優化策略裡的位置，搭配 WordPress 圖片優化指南 一起看會更完整。壓縮只是圖片優化的一環，檔案命名、alt 替代文字、結構化資料這些 圖片 SEO 的基本功也不能漏，否則你把圖壓得再小，搜尋引擎不知道這張圖在講什麼，圖片搜尋的流量還是拿不到。

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

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

驗收要看三個數字：

指標	代表意義	圖片壓縮後預期變化
LCP（最大內容繪製）	頁面主要內容渲染完成的時間	若 LCP 元素是圖片，改善幅度最明顯
CLS（累計版面位移）	頁面載入時視覺跳動的程度	需確認圖片有設尺寸屬性才不會位移
INP（互動到下一個繪製）	使用者與頁面互動的回應速度	圖片壓縮的影響較間接

LCP 是圖片壓縮最直接影響的指標。如果你的首屏大圖從 2 MB 壓到 400 KB，LCP 通常會有顯著下降。但要注意一個陷阱：CLS 可能反而變差。為什麼？因為延遲載入的圖片在還沒下載之前不佔空間，瀏覽器不知道要留多少位置給它，等圖片載入後就會把下面的內容推下去，造成視覺跳動。

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

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

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

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

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

驗收的時候也要注意一個心理陷阱：PageSpeed Insights 的分數是相對的，不是絕對的。同一個網站在不同時間測、用不同地點的伺服器測，分數都會浮動個幾分。不要為了追逐那個 90 分以上的綠色數字而過度優化，例如把圖片壓到畫質明顯劣化只為了分數好看，那是本末倒置。真正該盯的是 LCP 從幾秒降到幾秒、真實使用者的跳出率有沒有改善、轉換率有沒有跟著動。分數是參考，使用者行為才是答案。你可以用 GA4 工作階段報表 觀察優化前後的跳出率與平均工作階段時間變化，如果速度真的改善了，這兩個指標通常會跟著好轉。

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

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

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

情境一：你的圖片已經很小，但網站還是慢。如果你的媒體庫前十大的圖都不到 500 KB、Smush 壓縮報告顯示平均只省了百分之五到十，那圖片根本不是你的瓶頸。這時候要往快取、資料庫查詢、主機回應時間方向找問題。先讀 快取 Cache 指南 和 WordPress 快取外掛比較，把頁面快取做好，效益會比繼續雕圖片大得多。

情境二：你的流量是跨國的，圖片傳輸距離很遠。Smush 壓縮的是檔案大小，但它改變不了檔案從你的主機傳到地球另一端訪客手上的物理距離。如果你的讀者分散在不同洲，不管圖壓到多小，跨洋傳輸的延遲還是在。這個問題要用 CDN（內容傳遞網路）解決，讓圖片從離訪客最近的節點送出。CDN 的原理和選擇，可以從 CDN 網站加速指南 開始了解。

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

情境四：你的網站圖片來源很雜，有大量外部嵌入圖。有些站的圖片不是全部存在自己的媒體庫，而是透過 iframe 嵌入第三方平台（社群貼文、地圖、外部圖床）。Smush 只能處理你伺服器上的本地圖檔，對外部嵌入的圖完全無能為力。如果你的頁面體積有一半是外部資源造成的，Smush 再怎麼壓也只能動到另一半。這種情況要從減少外部嵌入數量、或改用延遲載入把第三方資源的影響降到最低。

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

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

今天就能做完的圖片優化行動清單

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

1. 量測基準線。用 PageSpeed Insights 跑你的首頁和流量最高的一篇文章，記下 LCP 數字和圖片相關建議。同時進媒體庫排序檔案大小，找出前十大的圖。
2. 安裝並設定 Smush。先用少量圖片比較壓縮層級與畫質，再決定自動壓縮、備份、大圖縮放及中繼資料設定。
3. 跑 Bulk Smush 批次壓縮。讓背景工作完成並檢查錯誤；免費版略過的超大圖片先縮小再重傳。若要處理媒體庫外的本機圖片，再評估 Directory Smush。
4. 啟用延遲載入並避開地雷。勾選跳過首屏圖片，確認 LCP 元素沒有被延遲。重要產品圖和資訊圖保持正常載入。
5. 決定你的 WebP 策略。依你的站點規模和技術能力，從升級 Pro、裝第二個外掛、或本機預先轉檔三條路線裡選一條。
6. 重新量測並記錄。用同一個頁面再跑一次 PageSpeed Insights，比較 LCP 的變化。進 Google Search Console 看 Core Web Vitals 報表，確認真實使用者數據也在改善。

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

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