WordPress 快取怎麼選，Page Cache、Object Cache、CDN 的差異和搭配方式
- 最後更新日期：
🚀 讀者專屬工具
立即開啟 →
在開始閱讀前，先用 AI 自動生成您的網站架構圖？
網站變慢時，很多人第一反應是「裝個快取外掛就好」。但 WordPress 快取不是單一開關，它更像餐廳備料流程，有人先把整份便當裝好，有人先把常用食材洗切好，也有人把餐點先送到離你最近的取餐點。選對層級，速度和穩定性會一起上來，選錯層級，則可能出現登入後看到別人的內容，或購物車亂跳這種災難。
這篇會用實務角度，把 WordPress 快取分成 Page Cache、Object Cache、CDN 三層，說清楚差異、互補方式，還有在 Cloudflare 這類 CDN 開啟 HTML 快取時，怎麼跟外掛分工不打架。
先搞懂三種 WordPress 快取在「快什麼」
把一次瀏覽想成「從主機端現煮一碗麵」。WordPress 的動態頁面通常會跑 PHP，載入外掛和主題，查一堆資料庫，最後才輸出 HTML。快取的目的，就是盡量把「現煮」變成「直接端上桌」。
**Page Cache（全頁 HTML 快取）**是把最後產出的整頁 HTML 存起來，下次同樣條件的訪客來，就直接回傳 HTML。它最有效，因為能大幅減少 PHP 和資料庫工作量。風險也很直觀，內容如果跟「登入狀態、語系、地區、購物車」有關，規則沒寫好就會快取到不該快取的版本。想更完整理解類型差異，可參考 Page Cache、Object Cache 與 CDN 快取解析。
**Object Cache（物件快取）**快的是「WordPress 內部計算結果」，像是資料庫查詢結果、options、taxonomy、某些 API 回應。它不一定能讓首次載入變成秒開，但對登入會員、後台、結帳流程這種「不能全頁快取」的場景特別有用。實務上通常指持久化物件快取，例如 Redis 或 Memcached，透過 object-cache.php drop-in 讓多次請求共用快取。
**CDN（邊緣節點快取與靜態加速）**主要快的是圖片、CSS、JS 等靜態資源，並把檔案放在離訪客更近的節點。CDN 也可以選擇快取 HTML，但這就進入「全站快取策略」領域，需要更嚴謹的 bypass 和 purge 規則。最常見、最穩的做法是，先用 CDN 加速靜態，再由主機端 Page Cache 負責 HTML。
外掛定位上，LiteSpeed 環境通常會優先用 LiteSpeed Cache 外掛，因為它能跟伺服器層 LSCache 配合。非 LiteSpeed 主機，WP Rocket、W3 Total Cache、Cache Enabler 這類偏向「外掛做 Page Cache」的路線較常見，其中 W3 Total Cache 外掛頁 也能看到它同時涵蓋 Page Cache、Object Cache、CDN 整合的定位。
選型矩陣：依流量、登入比例、主機環境做決策
快取選型別先看「哪個外掛最紅」，先看你的站像哪一種。下面用一個矩陣，把最常遇到的條件拉出來。
| 條件 | 優先策略 | 為什麼 |
|---|---|---|
| 內容站、訪客多為未登入 | Page Cache + CDN(靜態) | HTML 可以大量命中，CDN 降低延遲 |
| 會員站、課程站、登入比例高 | Object Cache + 針對性 Page Cache + CDN | 很多頁面要依登入顯示，Object Cache 更吃香 |
| 電商站(WooCommerce) | Page Cache(分流) + Object Cache + CDN | 商品頁可快取，但購物車/結帳必須 bypass |
| 共享主機 | 輕量 Page Cache + CDN | 資源有限，先把 HTML 和靜態擋住最有感 |
| VPS/自管主機 | Page Cache + Redis/Memcached + CDN | 可控性高，三層都能做得完整 |
| 託管主機(含內建快取) | 以主機快取為主，外掛輔助 | 兩套全頁快取同時開，最容易衝突 |
| 主機含 LiteSpeed/OpenLiteSpeed | LiteSpeed Cache +（需要時）Redis + CDN | 伺服器層快取通常效率最好 |
如果要用「決策樹」快速落地，可以用這三句話定調：
- 未登入為主，先把 Page Cache 做好，再補 CDN 靜態加速。
- 登入或動態為主，先上 Object Cache，把查詢和計算壓下來，再談哪些頁可以分流快取。
- 跨國流量或尖峰很大，CDN 先擋第一波，必要時再把 HTML 也放到邊緣，但規則要更嚴格。
在 WPTOOLBEAR 的維運經驗裡，速度問題常常不是少裝一個外掛，而是少了一個「一致的規則」。如果你想把快取策略做到可維護，從主機端快取和 CDN 分工開始規劃，後面更新外掛或改版才不會每次都重來。
Cloudflare 開啟 HTML 快取時，如何和 Page Cache 分工不衝突
很多人把 Cloudflare 開到「Cache Everything」後，覺得更快了，但接著就遇到兩種狀況，第一是登入後菜單不對，第二是更新文章後前台還是舊內容。這不是 Cloudflare 不好，是「雙重快取」沒對齊。
實務上建議先決定誰當 HTML 的主控：
- 方案 A（最常見）：Cloudflare 只快取靜態資源，HTML 由外掛或主機端 Page Cache 負責。優點是規則比較直覺，purge 也通常由 WordPress 觸發。
- 方案 B（進階）：Cloudflare 也快取 HTML，外掛 Page Cache 仍可留著當「來源端保護」，但必須確保 bypass 條件一致，並把 purge 串起來，否則會出現 Cloudflare HIT 但內容是舊的。
避免衝突的三個重點是 purge、bypass、變因控制。
- Purge 觸發：文章更新、產品庫存變動後，要能清掉對應 URL 的 CDN 快取。沒有整合時，只靠等 TTL 會讓內容更新延遲變長。
- Bypass 規則：登入 Cookie 要繞過快取，WooCommerce 常見包含
wordpress_logged_in_、woocommerce_items_in_cart、woocommerce_cart_hash等。購物車、結帳、我的帳戶頁面要直接 bypass。 - Query String 規則：帶參數的 URL 常造成快取碎片化，UTM 追蹤參數尤其常見。需要明確決定是忽略、正規化，或直接不快取。若你用 Cloudflare 的「移除快取破壞參數」類功能，這份 Cloudflare Cache Buster 參數處理指南 有不少細節提醒。
電商和會員站還有一個常被忽略的點是「片段內容」。首頁可能可以快取，但右上角的購物車數量不能被凍結。這時可以考慮片段快取，或在 LiteSpeed 生態用 ESI，把可快取的區塊和必須動態的區塊拆開，速度和正確性才不會互相拉扯。登入使用者為何更慢，以及該如何壓低頁面生成時間，也可以參考 登入使用者加速做法 的整理。
測試與上線檢查：用標頭看 HIT/MISS，用順序排查問題
快取有沒有生效，不要只看「感覺」。用瀏覽器開發者工具的 Network，看主文件的 TTFB，再看回應標頭是否命中快取。不同系統標頭不同，Cloudflare 常見 cf-cache-status: HIT/MISS，LiteSpeed 常見 x-litespeed-cache，有些主機會加 x-cache。同一頁連續刷新兩次，第二次如果還是 TTFB 很高，多半是沒命中或被 bypass。
想做簡易壓測也不難，挑 1 到 2 個代表頁面(首頁、熱門文章或商品頁)，在調整前後用同一工具、同一地點、同一時間段測 3 次取平均。重點不是跑到多漂亮的分數，而是確認尖峰時主機 CPU 和資料庫不會被打爆。
最後用一份可操作清單收尾，照這個順序做，上線會穩很多：
- 上線前設定
- 確認哪些頁「一定不快取」，購物車、結帳、我的帳戶、後台、個人化頁面先排除。
- 設定快取失效規則，發文、更新產品、改選單時能自動 purge。
- CDN 與 Page Cache 的 bypass 條件一致，尤其是 Cookie、裝置版型、語系。
- 日常維運
- 每次更新主題或外掛後，清一次 Page Cache 和 CDN 快取，並抽查 3 種頁型。
- 觀察高峰時段 TTFB 和錯誤率，先抓趨勢，不要等客訴。
- 出問題的排查順序
- 先看 CDN，是否快到不該快的頁，或 TTL 太長導致內容不更新。
- 再看 Page Cache，是否被登入 Cookie 或 query string 全面 bypass。
- 再看 Object Cache，是否有持久化，是否因外掛衝突導致命中率低。
- 最後才回到 資料庫，看慢查詢與外掛造成的額外 query。
速度優化做對了，感受很直接，頁面不只快，主機也更穩。把 WordPress 快取當成分工系統來設計，你會發現很多「加主機規格」才能解的問題，其實用對策略就能先解掉一半。下一次你準備把 Cloudflare 的 HTML 快取打開時，先問自己一句話，你的 bypass 規則，真的和 WordPress 端一致了嗎？
