把網站速度做起來，多數站長第一個動作就是裝一支快取外掛。但 WordPress 的快取從來不是裝一支就好這麼單純，一個請求從瀏覽器送到伺服器、再從伺服器回到瀏覽器，中間至少有三層快取在運作，每一層的命中與否，會直接決定首頁打開要 0.4 秒還是 2.8 秒。

LiteSpeed Cache、WP Rocket、W3 Total Cache 這三套是 2026 年市佔最廣的快取外掛，背後的邏輯卻差很多。LiteSpeed 綁伺服器層，WP Rocket 純 PHP 實作，W3TC 模組化但設定門檻高。再加上 Cloudflare、BunnyCDN 這類網路內容傳遞網路（CDN）在最外層攔截，整套堆疊（stack）誰負責哪一段，講不清楚就會出現「我裝了三支快取為什麼還是慢」的怪事。

這篇 wordpress 快取外掛比較把焦點放在快取在 stack 中的位置、三套外掛的觸發機制差異，以及 CDN 規則該怎麼配合外掛運作。讀完之後，要新站從零選型、或舊站想換外掛，都能對齊到自己的主機與流量條件上做判斷。

快取在 WordPress 請求路徑的三層位置

一個訪客打開頁面，從點下連結到看到內容，請求會依序穿過 CDN 邊緣節點、網站主機的網頁伺服器、再到 PHP 與 MySQL。快取就分別架在這條路徑的三個位置，包括邊緣、頁面、物件。瀏覽器本身的快取算第四層，但那層由 HTTP 標頭（Header）控制，外掛只能間接影響。

邊緣快取（Edge Cache）位在 CDN 節點上。整張 HTML 直接從離訪客最近的資料中心吐出來，請求根本不會回到原站，這是最快的一層。Cloudflare APO、BunnyCDN 的全頁快取（Full Page Cache）、LiteSpeed 自家的 QUIC.cloud 都屬於這層。

頁面快取（Page Cache）位在原站主機上，由快取外掛把 PHP 算好的 HTML 存成靜態檔案。下次同樣 URL 進來，伺服器直接讀檔回吐，跳過 PHP 與資料庫。LiteSpeed Cache、WP Rocket、W3 Total Cache 的核心功能都是這層。

物件快取（Object Cache）位在 PHP 與資料庫之間。WordPress 跑一支頁面會打十幾到幾十次資料庫查詢，把這些查詢結果用 Redis 或 Memcached 存在記憶體裡，下次同樣的查詢直接從記憶體取，省掉資料庫的硬碟讀寫。動態頁面例如登入後台、購物車、會員中心無法做頁面快取，這層就是動態頁面的主要加速來源。

這三層是疊在一起的，不是互斥選項。理想堆疊是 CDN 邊緣命中後，由原站頁面快取補位，再讓物件快取兜底動態請求。多數人裝快取外掛只開到頁面快取就停手，這也是為什麼購物車、會員頁、留言送出後常常感覺站台「突然慢一截」——那塊本來就沒被頁面快取覆蓋，物件快取沒配起來，每次都打到資料庫硬讀。

三套主流外掛的觸發機制差異

LSCWP、WP Rocket、W3TC 都做頁面快取，但快取怎麼建立、什麼時候失效、誰來吐檔這三件事，實作差很多。差異不在 UI 介面，而在背後的網頁伺服器整合層級。

LiteSpeed Cache（LSCWP）綁定 LiteSpeed Web Server 或 OpenLiteSpeed 伺服器。快取規則由伺服器本身執行，PHP 完全不介入吐檔過程，請求進來，LSWS 直接從快取資料夾讀檔回應。這在效能上是 0 PHP 開銷，但前提是主機要跑 LSWS。如果跑 Nginx 或 Apache，LSCWP 雖然能裝，頁面快取功能會降級成走 PHP 的偽伺服器層快取，效益打七折。LSCWP 對 WooCommerce 購物車、登入態 cookie 有獨立的私有快取（ESI）支援，這塊比另外兩套完整。

WP Rocket 是純 PHP 實作的付費外掛，不挑主機。安裝後它會修改 .htaccess 或建立 advanced-cache.php，當請求進來時透過 PHP 早期攔截（在 WordPress 完整載入前）回吐快取檔案。這個攔截還是要起 PHP 行程，比 LSWS 直讀慢一截，但比走完整 WordPress 流程快很多。WP Rocket 的主要價值來自內建延遲載入、延遲執行 JS、資料庫清理、預載入這套整合工具鏈，加上設定極簡，預設值就接近最佳化。

W3 Total Cache 走完全模組化路線。頁面快取、資料庫快取、物件快取、瀏覽器快取、CDN 整合是五個獨立模組，每個模組可以各自選後端，像是磁碟（Disk）、Memcached、Redis、APC、OPcache 都能挑。彈性最高，但設定面板有十幾個分頁，調錯一個就會吃虧——例如物件快取後端沒裝 Redis 卻選了 Disk，結果反而比不開還慢。W3TC 的傳統使用情境是主機支援 Redis 或 Memcached，站長知道自己在調什麼，不是給新手用的。

三套的快取失效（Invalidation）邏輯也不同。LSCWP 透過伺服器層的標籤機制，發文時可以精準清除相關標籤，例如某分類底下所有列表頁，不會全站清光。WP Rocket 比較粗，發文預設清除首頁、當篇、分類頁、作者頁，其餘留著。W3TC 看模組設定，可以做到精準，也可以設成全清，由站長決定。流量大的站要避免全清，因為一清就回到冷啟動狀態，原站會被回源請求打到 CPU 飆高。

三套外掛的選型對照

選哪一套，主機條件決定 60%，需求與預算決定剩下 40%。下表把三套放在同一個座標系比較，挑的時候從第一列伺服器相容性開始往下看，遇到不符合的就刷掉。

對應到實務場景，用 Cloudways、BlueHost、Hostinger 這類 LSWS 主機，預設答案就是 LSCWP，效益直接吃滿伺服器層整合。用 Kinsta、WP Engine 這類受管 WordPress 主機，本身已內建頁面快取，再裝快取外掛多半要關掉頁面快取模組、只用其他功能，這時候 WP Rocket 的延遲執行（Delay JavaScript Execution）與資料庫清理會比較有用。自管 VPS 跑 Nginx 加 PHP-FPM，預算有限又願意調設定，W3TC 配 Redis 物件快取的方案還是有競爭力，但要有踩過幾輪坑的心理準備。

CDN 規則怎麼配合外掛運作

外掛裝完只是把原站準備好，前面還要有 CDN 接手邊緣快取。2026 年最常見的兩家是 Cloudflare 與 BunnyCDN，各自的設定要點不同，跟快取外掛之間的接縫處最容易出問題。

Cloudflare 與 APO 的搭配重點

Cloudflare 的免費方案預設只快取靜態資源，像是圖片、CSS、JS，不快取 HTML。要把整張 HTML 推到邊緣，要走 Cloudflare APO（Automatic Platform Optimization），免費方案加購一個月 5 美元、Pro 方案以上免費內含。APO 透過 Workers KV 把 HTML 複製到 150 個以上的資料中心，預設快取 30 天，內容變動時透過 WordPress 端的 Cloudflare 官方外掛回傳清除訊號，30 秒內全網更新。

LSCWP 與 WP Rocket 都能透過 API 串接 Cloudflare，發文時自動觸發 Cloudflare 端的清除，不需要再裝 Cloudflare 官方外掛。但如果用 APO，目前最穩的組合還是 WP Rocket 加上 Cloudflare 官方外掛雙開——WP Rocket 清自己的頁面快取，Cloudflare 外掛接收事件清 APO 邊緣。少了 Cloudflare 外掛這一步，APO 不會收到清除訊號，訪客會看到舊版 HTML 直到 30 天自然過期。

要排除的 URL 路徑也要在 Cloudflare 端設規則。/wp-admin/、/wp-login.php、/cart/、/checkout/、/my-account/、含 ?nocache= 參數的請求都要設成繞過快取（Bypass Cache）。WooCommerce 站尤其要小心，APO 預設會吃掉一些 cookie 標頭，導致購物車狀態跨人混亂。Cloudflare 官方 APO 外掛裝起來會自動處理大部分情境，但購物車流程還是要實際走一輪測試。

BunnyCDN 的拉取區與邊緣規則

BunnyCDN 走拉取區（Pull Zone）模式，原站不動，CDN 主動回原站抓檔再快取。預設只快取靜態資源，要做全頁面快取要在拉取區的「邊緣規則」（Edge Rules）開設四到七條規則，把登入態、購物車、留言作者 cookie 對應的請求設成「覆寫快取時間 0 秒」，等於不快取這些動態請求。

具體要排除的 cookie 樣式包括 *wordpress_logged_in_*、*comment_author_*、*woocommerce_items_in_cart*、*wp_woocommerce_session_*，這些匹配到就讓請求直接回原站。同時要關閉拉取區設定裡的「智慧快取（Smart Cache）」和「剝離回應 Cookie（Strip Response Cookies）」兩個選項，前者會干擾 cookie 傳遞，後者會把 WordPress 設的登入 cookie 吃掉，導致使用者一直被登出。

快取過期時間設成「遵循原站快取控制標頭」，瀏覽器快取過期時間設成「匹配伺服器快取過期」。這樣外掛端發出的 Cache-Control 標頭會被 BunnyCDN 尊重，外掛清快取時可以同步通知邊緣失效。LSCWP 與 W3TC 都有 BunnyCDN 的整合選項，WP Rocket 則透過 CNAME 設定接入，三者實際上都能用，差別只在 UI 操作便利性。

三層快取的清除連動

建立快取本身不難，難的是內容更新時怎麼讓三層同步失效。理想流程是發文按下發布之後，外掛清除原站頁面快取，外掛透過 API 通知 CDN 清邊緣，物件快取的相關鍵值自動失效。任何一環沒打通，就會出現「站長後台看到新內容、訪客刷新還是舊頁」的鬼故事。

LSCWP 與 Cloudflare 串接後是自動的，發文觸發清除訊號到 Cloudflare API，APO 邊緣也跟著清。WP Rocket 加 Cloudflare 官方外掛的組合也是自動的。W3TC 要在 CDN 模組裡設 API 金鑰並開啟「自動清除」選項。BunnyCDN 都要透過 API token 接入。

實務上建議發文後做一次手動驗證，用無痕視窗打開新發布的頁面、看回應標頭裡的 cf-cache-status 或 cdn-cache 欄位是否為 MISS（剛清完應該是 MISS，下次刷新才會變 HIT）。這比相信外掛 UI 顯示「清除成功」可靠得多。

常見的快取與動態端點衝突

裝完外掛、串完 CDN，站台速度上去了，接下來會冒出來的問題九成是動態功能壞了。購物車數字不更新、表單送出後留在原頁、登入後仍看到登出狀態，這些症狀都指向同一個根因——本該動態的請求被快取吃掉了。

WooCommerce 的 /cart/、/checkout/、/my-account/ 三個頁面以及任何含 ?add-to-cart= 參數的請求要全程排除快取。LSCWP 預設規則已涵蓋這些，WP Rocket 預設也排除了大部分 WooCommerce 路徑，W3TC 要在頁面快取模組的「絕不快取的頁面」手動加入。CDN 端也要設一份相同規則，原站排除而 CDN 沒排除等於白做。

表單外掛例如 Contact Form 7、WPForms、Fluent Forms 多半透過 AJAX 端點 /wp-admin/admin-ajax.php 送資料，這條 URL 要永遠不快取。多數外掛預設已處理，但如果站台用了自製主題並改寫過 AJAX 端點，要自己補規則。

留言區是另一個常被忽略的點。訪客送出留言後，頁面快取要立刻針對該篇文章失效，否則留言者刷新看不到自己的留言，會以為留言失敗、重送一次造成重複。LSCWP 與 WP Rocket 都會處理這個事件，W3TC 要在頁面快取設定裡確認「留言送出時清除相關頁面」是開啟的。

登入態這塊也常出包。WordPress 的 wordpress_logged_in_* cookie 應該讓所有快取層（包含 CDN）認得並繞過。如果發現登入後仍看到登出狀態的首頁，多半是 CDN 端沒設好 cookie 規則。Cloudflare APO 與 BunnyCDN 預設規則涵蓋這個情境，但用 Cloudflare 免費方案搭一般頁面規則（Page Rule）自做的全頁快取很容易漏掉，要實測登入態下的訪問。

把這條路徑走完，等於整套快取堆疊都摸過一輪。wordpress 快取外掛比較最終的判斷不在哪一套功能多，而在外掛的快取邏輯，能不能跟主機伺服器、CDN 設定、動態端點清單完整對齊。對齊得上，三套都能跑出好成績；對齊不上，再貴的外掛也救不了一張要等 3 秒才開的首頁。