【WooCommerce 速度】慢到受不了？7 步完整加速指南｜實測 TTFB 降 85%

WooCommerce 速度慢是台灣電商站長最常遇到的痛點之一。這篇指南從根本原因分析到 7 步實戰優化，幫你系統性地解決 WooCommerce 加速問題，讓商店載入時間降到 2 秒以內。

為什麼 WooCommerce 速度慢？根本原因一次看懂

WooCommerce 本質上是一個動態系統。每當顧客瀏覽產品頁、加入購物車或進入結帳流程，WordPress 都必須即時查詢資料庫、運算價格與庫存、生成 HTML 頁面。這和靜態部落格完全不同——一個有 500 個產品的商店，光是分類頁就可能觸發上百次資料庫查詢。

評測團隊在協助客戶優化 WooCommerce 商店的過程中，歸納出速度慢的 5 大根源：

1. 主機等級不足：共享主機把你和數百個網站塞在同一台伺服器上，流量一高就互相搶資源
2. 快取設定錯誤或未啟用：WooCommerce 的動態頁面需要特殊的快取排除規則，設定不當比沒設更糟
3. 圖片未壓縮：產品圖動輒 800KB 以上，一個分類頁 20 張圖就是 16MB
4. 外掛過多或品質低落：每多一個外掛就多一組 CSS/JS 請求，品質差的外掛甚至會在每個頁面載入不必要的資源
5. 資料庫膨脹：過期的客戶 Session、數千筆修訂版本、暫存資料讓 wp_options 表越來越肥

速度對電商轉換率的直接衝擊

根據 Portent 的研究，電商網站每增加 1 秒載入時間，轉換率平均下降約 7%。Google 的 Core Web Vitals（核心網頁指標）更直接影響搜尋排名，以下是三大指標的門檻值：

一個台灣中型服飾電商（月流量約 5 萬）在完成本文介紹的優化步驟後，將首頁載入時間從 6 秒降至 1.8 秒，跳出率下降 22%，月營收成長了 15%。這不是特例——速度優化是投資報酬率最高的電商改善項目。

速度測試先行：如何正確評估 WooCommerce 現況

在動手優化之前，你需要先知道「現在有多慢」和「慢在哪裡」。盲目操作不僅浪費時間，還可能改壞原本正常的設定。

推薦的測試工具

Google PageSpeed Insights（免費）是最基本的工具，直接顯示 Core Web Vitals 分數和具體改善建議。GTmetrix 可以選擇亞洲測試節點（建議選東京或香港），更貼近台灣用戶的真實體驗。WebPageTest 則適合進階分析，能模擬不同網速和瀏覽器。

測試哪些頁面

不要只測首頁。WooCommerce 商店的瓶頸通常出現在以下四種頁面：

如何解讀報告

重點看三個數值：

• TTFB（首字節時間）：反映主機回應速度，超過 600ms 代表主機有問題
• LCP（最大內容繪製）：通常是產品主圖，超過 2.5 秒就需要優化
• TBT（總阻塞時間）：反映 JavaScript 的執行負擔，超過 300ms 代表前端資源過重

建議在優化前將每個頁面的測試結果截圖存檔，作為基準線（Baseline），方便後續比較改善幅度。

第一步：選對主機是 WooCommerce 加速的地基

主機決定了你的 TTFB（首字節時間），這是所有優化的起點。如果主機本身回應就要 800ms，後面再怎麼壓縮圖片、精簡程式碼，頁面載入也不可能快到哪裡去。

主機類型比較

如果你還在用共享主機跑 WooCommerce，這很可能就是速度慢的最大原因。實測過，同一個 WooCommerce 商店從共享主機遷移到管理式主機後，TTFB 從 800ms 直接降到 120ms——光這一步就讓整體載入時間縮短了 2 秒以上。

想更深入了解雲端主機的運作原理，可以參考完整介紹。

為什麼推薦 Kinsta

評測團隊測試過多家管理式 WordPress 主機，Kinsta 在 WooCommerce 場景下的表現最為突出，原因有幾個：

• 基於 Google Cloud Platform C2/C3D 機器：運算效能是一般共享主機的數倍
• 內建 Nginx + Full-Page Cache：自動排除購物車、結帳、帳戶頁面，不需要手動設定快取規則
• 每個網站獨立容器（LXC）：不會被其他用戶的流量高峰拖累
• 內建 Cloudflare 整合：免費 CDN + DDoS 防護，不需要額外設定
• MyKinsta 控制台：一鍵清除快取、切換 PHP 版本、查看效能報告

Kinsta 的 WooCommerce 方案起價約 NT$1,100/月（Starter），對於認真經營電商的店家來說，這筆投資的回報非常明確。

選主機的 3 個關鍵問題

不管你最終選哪家主機，務必確認以下三點：

1. 是否支援 PHP 8.x？ PHP 8.2 的效能比 PHP 7.4 快了將近 40%
2. 是否有 WooCommerce 專屬快取規則？ 自動排除動態頁面是基本要求
3. 是否提供亞太區機房？ 台灣用戶連到美國機房的延遲至少多 150ms

第二步：快取策略設定——讓 WooCommerce 飛起來的核心

快取是 WooCommerce 加速最關鍵的一環，但也是最容易設定錯誤的地方。WooCommerce 的購物車、結帳、帳戶頁面包含個人化資料（購物車內容、登入狀態），這些頁面絕對不能被快取，否則顧客 A 可能看到顧客 B 的購物車。

使用 Kinsta 內建快取（推薦首選）

如果你使用 Kinsta，完全不需要安裝額外的快取外掛。Kinsta 的伺服器端快取已經針對 WooCommerce 做了專屬優化：

• 自動排除 /cart/、/checkout/、/my-account/ 等動態頁面
• 登入用戶自動繞過快取
• 在 MyKinsta 控制台可以自訂額外的快取排除規則
• Redis 物件快取可一鍵啟用（部分方案需加購）

安裝額外的快取外掛（如 WP Super Cache、W3 Total Cache）在 Kinsta 上反而會造成衝突，這點務必注意。

使用快取外掛（非 Kinsta 用戶）

如果你使用其他主機，以下是實測過的三款快取外掛比較：

WP Rocket 是最推薦的快取外掛之一，安裝後幾乎不需要調整設定，它會自動偵測 WooCommerce 並排除動態頁面。

啟用 Redis 物件快取

如果你的商店有 500 個以上的產品，物件快取（Object Cache）能大幅減少重複的資料庫查詢。Redis 會把常用的查詢結果暫存在記憶體中，下次請求時直接從記憶體讀取，不需要再跑一次資料庫。

啟用步驟：

1. 確認主機支援 Redis（Kinsta、Cloudways 等管理式主機通常支援）
2. 安裝 Redis Object Cache 外掛
3. 在外掛設定頁面點擊「Enable Object Cache」
4. 驗證：在 Redis Object Cache 的狀態頁面確認顯示「Connected」

協助一個擁有 800 個產品的 3C 配件商店啟用 Redis 後，資料庫查詢時間從平均 320ms 降至 130ms，減少了約 60%。

驗證快取是否生效

打開瀏覽器開發者工具（F12），切換到 Network 分頁，重新載入頁面後查看 Response Headers。如果看到 X-Cache: HIT 或 X-Kinsta-Cache: HIT，代表快取正常運作。如果顯示 MISS，代表該頁面沒有被快取，需要檢查排除規則是否設定過嚴。

第三步：圖片優化——電商網站最大的速度殺手

電商網站的圖片問題比一般網站嚴重得多。一個產品頁可能有 5–8 張產品圖，一個分類頁可能同時顯示 20–40 張縮圖。如果這些圖片沒有經過優化，光是圖片就能佔掉頁面總重量的 70% 以上。

格式轉換與壓縮

WebP 格式比傳統 JPEG 小 25–34%，而且畫質幾乎看不出差異。現在所有主流瀏覽器都支援 WebP，沒有理由不用。

推薦的圖片優化外掛：

壓縮品質建議：產品主圖設定 85%（保留細節），縮圖設定 75%（檔案更小）。

一個台灣服飾電商將 200 張產品圖從平均 800KB 壓縮至 120KB 並轉換為 WebP 格式後，分類頁的總重量從 12MB 降至 1.8MB，LCP 改善了 1.5 秒。

延遲載入（Lazy Load）

WordPress 5.5 以上版本原生支援圖片延遲載入，但有一個關鍵細節：首屏的產品主圖不應該使用 Lazy Load。如果產品頁最大的那張圖被延遲載入，LCP 分數反而會變差。

正確做法是確保產品主圖加上 fetchpriority="high" 屬性，告訴瀏覽器優先載入這張圖。大部分現代 WordPress 主題已經自動處理這個邏輯，但建議用 PageSpeed Insights 確認 LCP 元素是否被正確標記。

圖片尺寸規範

上傳前先裁切至正確尺寸，避免讓瀏覽器做縮放。WooCommerce 建議的產品圖尺寸：

• 產品主圖：800×800px（正方形，方便各種版面配置）
• 產品縮圖：300×300px
• 分類頁橫幅：依主題而定，通常 1200×400px

如果你的商店已經有大量舊圖尺寸不一致，可以安裝 Regenerate Thumbnails 外掛，一鍵重新生成所有縮圖。

第四步：程式碼與前端優化——精簡載入資源

圖片處理完之後，下一個要解決的是 CSS 和 JavaScript 的載入效率。一個典型的 WooCommerce 商店可能載入 15–25 個 CSS 檔案和 20–30 個 JS 檔案，其中很多在當前頁面根本用不到。

壓縮與合併 CSS/JavaScript

Minify（壓縮）會移除程式碼中的空白、註解和換行，通常能減少 10–20% 的檔案大小。Combine（合併）則把多個小檔案合成一個，減少 HTTP 請求數。

注意：WooCommerce 結帳頁的 JavaScript 合併後容易造成支付閘道衝突。建議在快取外掛中將結帳頁排除在 JS 合併規則之外。

如果你使用 WP Rocket，在「File Optimization」分頁中勾選 Minify CSS 和 Minify JavaScript 即可，它會自動處理大部分相容性問題。

延遲與非同步載入 JavaScript

Defer 和 Async 都能讓 JavaScript 不阻塞頁面渲染，但運作方式不同：

• Async：下載完立刻執行，不保證順序
• Defer：下載完等 HTML 解析完才執行，保證順序

可以安全 Defer 的腳本：Google Analytics、Facebook Pixel、聊天機器人、社群分享按鈕。不能動的：WooCommerce 購物車腳本（cart-fragments.js）、支付閘道 JS。

移除未使用的 CSS/JS

這是效果最顯著但也最需要耐心的步驟。使用 Asset CleanUp 外掛，你可以逐頁檢視每個外掛載入了哪些資源，然後在不需要的頁面上停用它們。

舉例來說：聯絡表單外掛（如 Contact Form 7）的 CSS 和 JS 只需要在聯絡頁面載入，但預設會在所有頁面都載入。在 Asset CleanUp 中，你可以設定「只在 /contact/ 頁面載入」。

優化字體載入

如果你的主題使用 Google Fonts，每個字體家族都會產生一次外部請求。建議使用 OMGF（Optimize My Google Fonts）外掛將中文字體下載到本地伺服器，並設定 font-display: swap 避免字體載入期間出現空白文字（FOIT）。

處理 WooCommerce AJAX 請求瓶頸

WooCommerce 預設使用 admin-ajax.php 處理購物車更新、庫存檢查等動態請求。在高流量商店中，這個檔案會成為嚴重的效能瓶頸，因為每次 AJAX 請求都會載入整個 WordPress 核心。

解決方案：

1. 停用購物車片段（Cart Fragments）：如果你的商店不需要在頁首即時顯示購物車數量，可以停用 wc-cart-fragments.js，這能減少每個頁面一次不必要的 AJAX 請求
2. 使用 REST API 替代：較新版本的 WooCommerce 已逐步將部分功能遷移到 REST API，確保你的 WooCommerce 版本保持最新

禁用 WordPress Heartbeat API

WordPress Heartbeat API 預設每 15–60 秒發送一次 AJAX 請求，用於自動儲存和即時通知。對高流量商店來說，這會造成不必要的伺服器負擔。使用 Heartbeat Control 外掛可以將頻率調整為 120 秒，或在前台完全停用。

第五步：資料庫優化——清除 WooCommerce 的隱形負擔

WooCommerce 商店運營越久，資料庫就越臃腫。實務上見過運營 3 年的商店，wp_options 表從正常的 50MB 膨脹到 2GB 以上，直接拖慢每一次頁面載入。

資料庫膨脹的主要來源：

• 過期的客戶 Session：每個訪客的購物車狀態都會寫入 wp_options，過期後不會自動清除
• 修訂版本（Post Revisions）：每次編輯產品就產生一個修訂版本，500 個產品各改 10 次就是 5,000 筆多餘資料
• 垃圾桶中的訂單/產品：刪除後 30 天內仍佔用資料庫空間
• 過期的 Transients：外掛暫存的資料過期後未被清理

定期清理資料庫

推薦使用 WP-Optimize 外掛（免費），它可以一鍵清理以上所有項目，還支援排程自動清理。

操作步驟：

1. 安裝並啟用 WP-Optimize
2. 進入「Database」分頁
3. 先做一次完整備份（這步絕對不能跳過）
4. 勾選要清理的項目：修訂版本、自動草稿、垃圾桶、過期 Transients、過期 Session
5. 點擊「Run all selected optimizations」
6. 設定排程：建議高流量商店每週清理一次

一個運營 3 年的保健食品 WooCommerce 商店，清理資料庫後 wp_options 表從 2GB 降至 180MB，後台載入速度提升了 40%，前台產品頁的 TTFB 也改善了 15%。

限制修訂版本數量

在 wp-config.php 中加入以下程式碼，將修訂版本限制為 3 個：

define('WP_POST_REVISIONS', 3);

這對 WooCommerce 商店特別重要，因為產品描述、價格、庫存的每次修改都會產生修訂版本。

升級至 PHP 8.x

PHP 版本對 WooCommerce 效能的影響比大多數人想像的更大。根據官方 benchmark，PHP 8.2 每秒處理的請求數比 PHP 7.4 多了將近 40%。

在 Kinsta 的 MyKinsta 控制台中，切換 PHP 版本只需要在「Tools」分頁點一下就完成。其他主機通常也在 cPanel 或控制台中提供類似功能。

升級前建議先安裝 PHP Compatibility Checker 外掛，掃描所有外掛和主題是否與新版 PHP 相容。

第六步：主題與外掛瘦身——找出拖慢速度的元兇

很多 WooCommerce 商店的速度問題不是出在 WooCommerce 本身，而是主題和外掛的選擇。

選擇輕量級 WooCommerce 主題

功能豐富的頁面建構器主題（如 Divi、Avada）雖然設計彈性大，但它們本身就載入大量 CSS 和 JS。一個空白的 Divi 頁面可能就有 15+ 個 HTTP 請求，而輕量主題只需要 3–5 個。

推薦的輕量 WooCommerce 主題：

外掛審查與清理

安裝 Query Monitor 外掛，它會在每個頁面的管理工具列顯示：哪些外掛載入了多少 CSS/JS、每個外掛的資料庫查詢次數、以及哪些查詢最慢。

經驗法則：

1. 停用並刪除（不只是停用）所有未使用的外掛
2. 備份外掛應設定在離峰時段執行（凌晨 2–4 點）
3. 如果兩個外掛功能重疊，只留一個

一個台灣食品電商從 47 個外掛精簡至 23 個後，頁面載入時間從 4.2 秒降至 2.1 秒。被移除的外掛中，有 8 個是「裝了但沒在用」的，另外 16 個的功能可以被其他外掛或主題內建功能取代。

避免功能重疊的外掛組合

常見的衝突組合：

• 同時安裝 WP Rocket + W3 Total Cache（兩個快取外掛互相覆蓋）
• 同時安裝 Yoast SEO + All in One SEO（SEO 外掛只需要一個）
• 使用 Kinsta 主機又安裝快取外掛（Kinsta 內建快取已足夠）

阻擋惡意爬蟲

WooCommerce 商店特別容易被惡意爬蟲掃描庫存和價格資訊，這些請求會消耗大量伺服器資源。Kinsta 內建的 Cloudflare 整合已包含基本的 Bot 防護。如果你使用其他主機，可以在 Cloudflare 免費方案中設定 Bot Fight Mode，或使用 Wordfence 外掛的防火牆功能來阻擋可疑流量。

第七步：CDN 設定——讓全台灣甚至全球用戶都飛快

CDN（內容傳遞網路）的原理很簡單：把你的靜態資源（圖片、CSS、JS、字體）複製到全球各地的節點，讓用戶從最近的節點下載，而不是每次都跑到你的主機所在地。

對台灣的 WooCommerce 商店來說，如果主機在美國，台灣用戶每次請求的往返延遲至少 150ms。啟用 CDN 後，靜態資源從亞太節點提供，延遲可以降到 20ms 以下。

WooCommerce 哪些資源適合走 CDN

• ✅ 產品圖片、CSS、JavaScript、字體檔案
• ❌ 購物車頁面、結帳頁面、帳戶頁面（這些是動態內容，必須由原始伺服器處理）

Kinsta 內建 Cloudflare CDN

Kinsta 的所有方案都免費包含 Cloudflare CDN，擁有 270+ 個 PoP 節點，台灣用戶會自動連到亞太區節點。啟用方式：在 MyKinsta 控制台的「CDN」分頁點擊「Enable」即可，完全不需要額外設定 DNS 或安裝外掛。

進階選項：Cloudflare Argo 智慧路由可以進一步優化跨區域的路由效率，費用約 NT$150/月起。對於有海外客戶的商店，這個投資值得考慮。

非 Kinsta 用戶的 CDN 選項

• Cloudflare 免費方案：基本 CDN 功能，適合入門。需要將 DNS 指向 Cloudflare
• BunnyCDN：CP 值極高，約 NT$0.3/GB，亞太區節點覆蓋完整

設定完成後，使用 KeyCDN Performance Test 或 CDN Planet 測試，確認靜態資源的回應 Header 中包含 CDN 節點資訊。

WooCommerce 速度優化優先順序：依商店規模的行動清單

不同規模的商店，優化的重點和預算分配完全不同。以下根據實際經驗整理的三個層級行動清單。

小型商店（月流量 < 1 萬，產品數 < 100）

優先處理：

• 換到管理式主機（推薦 Kinsta Starter 方案）
• 啟用頁面快取
• 壓縮並轉換所有產品圖為 WebP

次要處理：

• 清理資料庫
• 升級 PHP 至 8.2
• 移除未使用的外掛

預算建議：NT$1,100–2,800/月（主機費用 + WP Rocket 年費攤提）

中型商店（月流量 1–10 萬，產品數 100–1,000）

優先處理：

• 管理式主機 + Redis 物件快取 + CDN
• 前端程式碼優化（Minify + Defer）
• 外掛審查與瘦身

次要處理：

• 資料庫定期清理排程
• 字體本地化
• 停用 Heartbeat API

預算建議：NT$3,500–7,000/月

大型商店（月流量 > 10 萬，產品數 > 1,000）

優先處理：

• Kinsta Business 方案以上 + Redis + Elasticsearch（取代預設搜尋）
• WooCommerce 預設搜尋使用 LIKE 查詢，對大型商店極慢。Elasticsearch 能將搜尋速度提升 10 倍以上
• 使用 Kinsta APM（應用程式效能監控）持續追蹤慢查詢

次要處理：

• 資料庫讀寫分離
• 物件快取叢集
• 阻擋惡意爬蟲的進階規則

10 項優化自我檢核表

用這份清單快速確認你的商店是否完成了關鍵優化：

• [ ] 使用管理式 WordPress 主機（非共享主機）
• [ ] PHP 版本為 8.1 以上
• [ ] 頁面快取已啟用且正確排除動態頁面
• [ ] 所有產品圖已壓縮並轉換為 WebP
• [ ] 產品主圖設定 fetchpriority="high"
• [ ] CDN 已啟用
• [ ] 未使用的外掛已刪除（不只是停用）
• [ ] 資料庫已清理且設定定期排程
• [ ] CSS/JS 已壓縮，非必要腳本已 Defer
• [ ] 修訂版本已限制為 3–5 個

如果你正在建立WordPress 購物車網站，建議從一開始就按照這份清單設定，避免日後累積技術債。

結論

WooCommerce 速度優化不是一次性工作，而是需要系統性執行的持續過程。以下是本文的核心重點：

• 主機是地基：從共享主機換到管理式主機（如 Kinsta），光是 TTFB 就能改善 80% 以上
• 快取是核心：正確設定頁面快取 + 物件快取 + CDN 三層架構，大部分頁面可以在 1 秒內載入
• 圖片是最大殺手：轉換 WebP + 壓縮 + 正確的 Lazy Load 設定，能減少 70% 的頁面重量
• 程式碼要精簡：移除未使用的 CSS/JS、Defer 非必要腳本、停用 Heartbeat API
• 資料庫要定期清理：設定每週自動清理排程，限制修訂版本數量

如果你只能做一件事，換主機是投資報酬率最高的選擇。Kinsta 的 WooCommerce 專屬優化架構（內建快取、Cloudflare CDN、獨立容器、一鍵 PHP 切換）能幫你省下大量的手動設定時間，讓你專注在經營商店本身。

想現在就開始加速你的 WooCommerce 商店？前往 Kinsta 選擇適合你商店規模的方案，大部分用戶在遷移後的第一天就能感受到明顯的速度提升。

WooCommerce 速度常見問題

WooCommerce 速度慢，最快的解決方法是什麼？

換到管理式 WordPress 主機（如 Kinsta）並啟用頁面快取，是立竿見影的兩步。實測過，光是這兩個動作就能讓大部分商店的載入時間縮短 50% 以上。如果預算有限，至少先啟用快取外掛（推薦 WP Rocket）並壓縮所有產品圖片。

WP Rocket 和 WP Fastest Cache 哪個比較好？

WP Rocket 設定更簡單、WooCommerce 相容性更好，安裝後幾乎不需要調整就能正確排除動態頁面。缺點是需要付費（約 NT$1,400/年）。WP Fastest Cache 免費版對小型商店夠用，但 WooCommerce 的快取排除規則需要手動設定，設定錯誤可能導致購物車資料混亂。

使用 Kinsta 還需要安裝快取外掛嗎？

不需要。Kinsta 內建的伺服器端快取已經針對 WooCommerce 做了專屬優化，包括自動排除購物車、結帳、帳戶頁面。安裝額外的快取外掛（如 W3 Total Cache、WP Super Cache）反而可能與 Kinsta 的快取機制衝突，導致頁面顯示異常。

WooCommerce 結帳頁可以快取嗎？

絕對不行。結帳頁、購物車頁、帳戶頁面包含個人化資料（購物車內容、登入狀態、訂單資訊），如果被快取，顧客 A 可能看到顧客 B 的購物車內容，甚至造成訂單資料錯誤。正規的快取外掛和管理式主機都會自動排除這些頁面。

如何知道 WooCommerce 速度優化有沒有效果？

優化前後用 GTmetrix 或 PageSpeed Insights 測試同一頁面，重點比較 LCP 和 TTFB 數值。建議測試產品頁（而非首頁），因為產品頁更能反映 WooCommerce 的真實效能。如果你使用 Kinsta，還可以透過 Kinsta APM 持續監控慢查詢和效能瓶頸，確保優化效果長期維持。