網站「慢」嘅根本原因通常唔係某一張圖片，而係請求鏈路 + 伺服器生成 + 靜態資源分發疊加造成嘅：

  • 用戶離你嘅伺服器太遠，網絡 RTT 高（跨洲更明顯）
  • WordPress 每次請求都要行 PHP、查數據庫、渲染模板 → TTFB（首字節時間）上升
  • 頁面仲要加載 JS/CSS/字型/第三方腳本，渲染同互動變慢

緩存插件解決嘅核心係：將「重複計算」嘅頁面結果保存落嚟，等伺服器唔使次次重新計算；並喺合適嘅策略下，令更多用戶命中緩存，從而顯著降低 TTFB。WordPress 官方文檔亦都指出，好似 W3 Total Cache、WP Super Cache 呢類外掛可以將頁面緩存成靜態檔案，再直接提供畀用戶，減輕伺服器處理負擔。

閱讀呢一頁之前先記住 3 條鐵律

1. 一次只使用一個頁面緩存插件

同時啟用多個緩存外掛，最常見嘅結果唔係更快，而係：

  • 互相覆蓋緩存規則、互相清理緩存、緩存命中率下降
  • 登入狀態/語言/購物車/價格等動態內容被緩存，導致「錯內容」事故
    好多插件文檔/說明都會建議喺使用某個緩存插件時停用其他緩存插件為咗避免撞。

2. 電子商務/會員制/多語言網站:緩存唔係一個「開關掣」,而係一套「規則系統」。“

WooCommerce 官方效能文檔清楚提醒：喺快取插件入面要確保 購物車 / 結帳 / 帳戶 呢啲頁面唔好畀佢緩存，仲建議避免壓縮 JavaScript 檔案（因為容易引起兼容問題）。

3. 「緩存插件≠CDN」,但緩存插件係CDN嘅基礎

緩存插件解決“源站少算”；內容分發網絡 解決「內容離用戶更近」。兩者係疊加關係：先將源站 TTFB 壓低，再將靜態資源交畀 CDN 擴散，呢個先係面向全球用戶最穩陣嘅路線。

快速揀型：網站最常見嘅 4 種場景

如果你唔想睇晒全文，跟住下面 4 條揀，基本上唔會錯：

  1. 想慳心、要穩定、面向全球訪問 → WP Rocket（付費）
  2. 主機明確係 LiteSpeed/OpenLiteSpeed → LiteSpeed 緩存（免費但強依賴伺服器能力）：快取功能需要 LiteSpeed 嘅伺服器組件先至可以運作
  3. 內容站/博客/文檔站，想免費又穩陣 → WP Super Cache（靜態 HTML 緩存）：生成靜態 HTML 檔案畀大多數未登入用戶
  4. 你有技術團隊，要精細控制（CDN/物件快取/多模組） → W3 全能緩存（強但複雜）：主打全面嘅性能框架同 CDN 整合

缓存究竟缓存啲乜嘢？

“「點解有啲網站裝咗緩存都係慢」，我哋將 WordPress 性能拆成 5 層：

  1. 瀏覽器快取：令到用戶第二次訪問快啲（靜態資源緩存頭、版本號）
  2. 頁面緩存: 將頁面輸出結果緩存成 HTML（本頁主角）
  3. 物件快取: 緩存數據庫查詢結果對象（動態網站更有價值）
  4. PHP OPcache: 緩存 PHP 字節碼（通常由伺服器配置，唔係插件重點）
  5. CDN/邊緣緩存：將資源擺喺離用戶更近嘅節點

本文重點講：頁面緩存插件；
但會不斷提醒你：網站往往需要 2 + 5 嘅組合先至「真係快」。

插件1:WP Rocket（付費）——「慳心」嘅一體化方案

WP Rocket 喺「WordPress」場景度咁受歡迎，原因唔係佢有咩神奇，而係佢將最常見嘅三類性能工作整成「可控嘅套餐」：

  • 頁面緩存（降低源站 TTFB）
  • 緩存預載/預熱（提升全球分佈訪問下嘅首次訪問體驗）
  • 前端關鍵優化（尤其係 JS 延遲、CSS 處理等）
WordPress 快取優化 - LikaCloud

佢嘅官方文檔裏面亦都明確提到：就算你閂咗頁面緩存，開啓預加載仍然可以觸發/驅動某啲優化流程（例如 CSS/JS 相關嘅優化）。

1.1 WP Rocket 適合邊個

WP Rocket 特別適合呢啲網站：

  • 企業官網、品牌網站、內容營銷網站、落地頁（流量嚟自多個國家地區）
  • 希望「上線快、穩定優先」，唔想砌好多免費插件組合
  • 冇專職運維/性能工程師，但又對體驗同 SEO 有要求
  • WooCommerce 都可以用，但要更加謹慎（呢節後面會講規則同風險）

1.2 佢喺網站訪問場景嘅關鍵價值（唔單止係「緩存開關」）

A. 緩存預載：解決「網站分佈訪問導致嘅首次訪問唔穩定」“

網站用戶分散嘅時候，你會遇到一種好典型嘅慢：
某個地區嘅用戶第一次打開某個頁面，咁啱該頁面緩存過期或者從未預熱 → 呢個用戶要承受完整嘅 PHP/DB 渲染成本。
預載機制嘅意義就係：將「首次生成」嘅成本提前支付，減少「首訪當白老鼠」嘅概率。

  • 唔預載：邊個先訪問邊個受罪
  • 有預載：由系統喺後台統一生成緩存，首次訪問體驗更穩定

B. 延遲 JavaScript 執行：網站訪問入面最容易「體感立竿見影」嘅功能，但風險亦最大

WP Rocket 官方將「“延遲 JS 執行”「描述為其最強嘅 JS 優化：佢會將腳本執行推遲到用戶發生互動（移動滑鼠、觸控、滾動、撳鍵等）之後，以優先渲染頁面。」

呢個對網站訪問好重要，因為跨洲網絡之下，腳本加載同執行阻塞更容易放大：

  • 資源下載慢啲 → 主線程更容易俾腳本拖住
  • 第三方腳本（統計、廣告、聊天插件）更容易導致 INP/互動延遲惡化

但係都可能會造成一啲問題：

  • 延遲 JS 好可能影響到：菜單、輪播、彈出視窗、表單驗證、支付、追蹤埋點
  • 所以佢適合「循序漸進 + 黑名單排除」嘅策略

C. 同其他插件/主題嘅兼容性：慳心唔等於「零衝突」“

WP Rocket 官方專門列咗「“唔兼容嘅插件/主題”」清單，原因包括會影響 WP Rocket 快取/優化嘅輸出緩衝等機制。

  • 如果你個網站插件好多、主題好重，請將「性能優化」當成一次小型上線項目：每次改動都要做迴歸測試（表格、登入、支付、多語言切換等）

1.3 對 WooCommerce/動態站嘅特別提醒

WooCommerce 官方文檔喺配置緩存插件時嘅核心提醒係：

點解？：

  • 購物車、結算、帳戶頁面強烈依賴 cookie / session / nonce
  • 緩存一旦將呢啲頁面當成「靜態頁面」，輕則按鈕失效，重則價格/庫存/帳戶資訊錯亂
  • 最恐怖嘅係：你可能喺一個地區測試冇問題，另一個地區因為 CDN/緩存命中差異而出事

1.4 緩存插件策略級建議

第 1 層：基礎安全收益（幾乎所有站都應該做）

  • 開啟頁面緩存
  • 開啟緩存預加載（提升首次訪問穩定性）
  • 合理嘅瀏覽器緩存策略（WP Rocket/伺服器/CDN 任何一層都可以實現）

第 2 層：中等收益，中等風險（適合大多數內容網站）

  • 延遲加載圖片/iframe（圖片優化頁再深入）
  • 控制 CSS 體積（例如 移除未使用嘅CSS）

第 3 層：高收益但高風險（必須有回歸測試清單）

1.5 價格與授權

  • WP Rocket 係付費授權制，按網站數量提供唔同許可

插件2:LiteSpeed Cache (LSCWP)——「免費頂配」嘅前提係伺服器真係用緊 LiteSpeed

WordPress 快取優化 - LikaCloud

好多人對 LiteSpeed Cache 嘅誤解係：以為佢只係一個 WordPress 插件，裝咗就可以好似 WP Rocket 咁喺任何主機上發揮晒全部威力。但其實唔係。

LiteSpeed 官方文檔清楚解釋：LSCWP 嘅緩存特性之所以需要 LiteSpeed Server，係因為佢要同 LiteSpeed Web Server 內置嘅頁面緩存（LSCache）通訊；插件負責話俾伺服器知邊啲頁面可以緩存、緩存幾耐，同埋用標籤觸發清理。

LiteSpeed Cache 嘅核心優勢來自「“伺服器級頁面緩存（LSCache）”」。冇 LiteSpeed/OpenLiteSpeed 伺服器，就冇呢個核心優勢。

2.1 LiteSpeed 緩存適合邊啲人

適合：

  • 你嘅主機面板有明確標示 LiteSpeed / OpenLiteSpeed（例如好多 cPanel 主機都會咁寫）
  • 你希望「免費方案都可以有好好嘅 TTFB 同並發能力」“
  • 你願意接受：佢功能好勁，但概念亦都多咗（TTL、Tag、Purge、ESI、Crawler…）

唔係好啱：

  • 你唔肯定主機係咩 Web Server，又或者確認係 Nginx/Apache（除非你淨係想用佢嘅一部分前端優化功能，但係咁樣性價比同複雜度就唔一定划算）
  • 你係複雜電商/會員/多語言網站，但係冇測試流程（LSCWP 好勁，但亦都更容易「快取錯內容」）

2.2 佢嘅快取機制：點解佢更加似「伺服器能力嘅一部分」“

你可以將 LiteSpeed Cache 嘅機制寫成一句「工程化解釋」：

  • WP Rocket / WP Super Cache 呢類更多係喺 WordPress/PHP 側做緩存同優化；
  • LSCWP 就係「WordPress 控制面板 + LiteSpeed Server 內置 LSCache」嘅組合：插件負責發送規則同清理信號，真正高速嘅頁面緩存發生喺伺服器層。

呢樣會直接影響網站訪問體驗：伺服器層吐緩衝通常更輕、更快，亦更扛並發（尤其係突發流量、搜尋引擎爬蟲高頻訪問嗰陣）。

2.3 網站用戶場景下，LSCWP 嘅「正確打開方式」“

我哋將「正確打開方式」分成 4 個層級：

第 1 層：頁面緩存策略（決定 TTFB 係咪真係可以降低）

  • 明確邊啲頁面可以緩存（大多數公開內容頁）
  • 明確邊啲頁面絕對唔可以緩存（登入、帳戶、購物車、結算、語言/貨幣切換依賴強 cookie 嘅頁面）
  • 為緩存設定合理嘅 TTL（內容更新頻率越高，TTL 越短；反之越長）
  • 建立清理策略：內容更新後清理相關標籤（而唔係粗暴全站清理）

呢一層如果做得好，網站最直接睇到嘅就係 TTFB 下降、首屏更穩定。

第 2 層：預熱/爬蟲（決定「冷門頁面首次訪問快唔快」）

網站訪問常見嘅「體驗唔一致」來自緩存嘅「冷熱差異」：

  • 熱門頁面一直有人訪問，緩存一直係熱嘅
  • 冷門頁面好耐冇人撳，第一次撳嘅人就好慢

預熱唔係錦上添花，而係網站訪問體驗一致性嘅關鍵

第 3 層：動態內容嘅安全方案（電商/會員/多語言）

LSCWP 嘅能力強在佢俾咗好多「高級工具」俾你，例如：

  • 對登入用戶、評論用戶等嘅差異化緩存策略
  • 邊緣端包含（ESI）嘅核心思路係：將頁面拆分為「可緩存嘅公共主體」同「不可緩存嘅動態片段」，分別處理之後再喺邊緣節點拼接。

第 4 層：在線服務同可選增強

好多站長會喺 LSCWP 入面接觸到 QUIC.cloud 嘅在線服務（例如頁面優化類服務）。QUIC.cloud 文檔清楚寫到：佢向 LSCWP 提供頁面優化服務，包括 Critical CSS（CCSS）、Unique CSS（UCSS）、Viewport Images（VPI）等等。

  • 呢類服務係可選嘅：你可以淨係用伺服器緩存，唔使啟用線上優化
  • 一旦啟用線上服務，你嘅網站資源/頁面處理鏈路會發生變化（呢個對企業/私隱敏感客戶係重要資訊）

2.4 LSCWP 常見嘅坑

  1. 伺服器唔係 LiteSpeed，但係將 LSCWP 當成全功能快取插件
    結果：快取效果唔似預期，仲增加咗設定複雜度。解決方案：先確認主機堆疊；如果唔係 LiteSpeed，考慮用 WP Rocket 或者 WP Super Cache。
  2. 啟用過多前端優化導致功能異常
    頁面優化（CSS/JS）往往比「快取本身」更容易引發兼容問題。建議：先將頁面快取跑穩，再逐項開啟優化，並建立回歸測試清單（表格、菜單、支付、追蹤、語言切換等）。
  3. 對動態頁面缺少排除/分片策略
    典型事故：購物車、結算、賬戶頁被快取；或多語言/多幣種切換不正確。電商站必須將此當作上線前檢查項（WooCommerce 官方亦強調關鍵頁面唔好快取）。

外掛程式3:WP Super Cache（免費）——內容站嘅「低風險高回報」經典方案

WordPress 快取優化 - LikaCloud

WP Super Cache 點解可以長期流行？因為佢用一種好直接、好「伺服器友好」嘅方式解決問題：
將動態 WordPress 頁面生成靜態 HTML 檔案，之後直接由 Web 伺服器提供呢啲 HTML 檔案，從而繞過昂貴嘅 PHP 處理。

插件頁仲提到：靜態 HTML 會提供畀絕大多數未登入用戶，並畀出一個非常直觀嘅講法——「99% 嘅訪問者將會被提供靜態 HTML 檔案」，一個緩存檔案可以服務數千次。

3.1 WP Super Cache 適合邊個

強烈推薦：

  • 博客、媒體內容站、文件站、企業展示站、登陸頁
  • 訪問者主要係未登入用戶
  • 你希望：免費、穩定、維護成本低

小心使用/需要更強策略：

  • 強動態站：大量個人化內容、按用戶狀態變化嘅頁面
  • 大型電商：可以用，但要確保關鍵頁面唔緩存，同配合你嘅測試流程

3.2 佢嘅三種緩存方式：

WP Super Cache 插件描述裏面將緩存方式按速度列咗 3 種，並解釋咗差異：

  • mod_rewrite（專家）：最快，完全繞過 PHP，但要改 .htaccess，配置唔啱可能令網站用唔到，風險高啲
  • 簡單（推薦方式）：由 PHP 提供「超級快取」靜態檔案，速度接近 mod_rewrite，但配置易啲
  • WP-Cache 快取：更靈活，用喺已知用戶、帶參數網址、訂閱源等，但速度會慢啲

推薦選擇：

  • 新手/追求穩定：用推薦方式（簡單）
  • 你好熟伺服器規則、而且願意承擔改寫規則嘅風險：再諗下專家模式
  • 你需要更靈活嘅「已知用戶/帶參數」處理：理解 WP-Cache 嘅定位

3.3 WP Super Cache 嘅優勢同短板

優勢：

  1. 非常適合同 CDN 配合
    因為佢本質就係「生成靜態 HTML」，呢樣嘢天生就符合 CDN/邊緣緩存嘅思路。
  2. 對源站 CPU/數據庫壓力嘅改善好直接
    網站流量分散嗰陣，搜索引擎同社媒爬蟲可能都係嚟自世界各地。靜態化對抗「重複渲染」效果好明顯。

短板：

  1. 佢唔係「一體化性能優化套件」“
    佢主要強項喺頁面緩存，對 CSS/JS 深度優化唔似 WP Rocket 咁一套打包。你可能需要喺「圖片優化頁」「前端優化頁」再承接更多內容（或用其他插件/主題級優化）。
  2. 對「動態個人化」要更加謹慎
    例如按地區顯示唔同內容、按用戶狀態顯示唔同價錢/語言/推薦等。呢個時候你一定要建立排除策略，或者引入更適合嘅分片緩存方案。

3.4 WooCommerce 兼容性：點解佢更「安全」“

WooCommerce 嘅官方幫助文檔提到：WooCommerce 同 WP Super Cache 原生兼容，而且 WooCommerce 會向 WP Super Cache 發送訊息，令佢默認唔緩存購物車、結帳、我的帳戶頁面。

  • 就算你係新手，WP Super Cache + WooCommerce 嘅組合都冇咁易踩中「關鍵頁面被緩存」嘅雷區
  • 不過都建議上線前做返回歸測試（支付、優惠券、運費、稅率、多幣種等等）

插件4:W3 全能緩存 (W3TC)——功能最齊全嘅「性能框架」，適合工程化團隊

WordPress 快取優化 - LikaCloud

W3 全能緩存 喺 WordPress.org 嘅定位唔係「單一緩存插件」，而係一個更加似「網站性能優化框架」嘅嘢：佢強調透過 CDN 整合同最佳實踐提升 SEO、Core Web Vitals 同整體體驗。

插件描述列出嘅能力非常廣泛：頁面/文章緩存、CSS/JS 緩存、Feed 緩存、搜尋結果緩存、數據庫對象緩存、對象緩存、片段緩存（fragment cache），並支援 Redis/Memcached/APC 等多種緩存方式，仲包括移動端按 UA/Referrer 分組緩存、AMP 支援、反向代理（Nginx/Varnish）整合等。

4.1 W3 Total Cache 適合邊個

非常適合：

  • 你有開發/運維能力，願意做「逐項啟用 + 壓測 + 回歸測試」“
  • 你嘅站點複雜：多語言、多主題切換、移動端差異化、內容結構複雜
  • 你唔單止要頁面緩存，仲想將對象緩存/片段緩存納入體系（尤其係動態站）

唔啱用嘅情況：

  • 你希望「裝完即刻快」，唔想理解緩存分層
  • 你冇測試流程，但又想一口氣開啓壓縮、延遲腳本等高風險項目

4.2 點解話佢「勁但複雜」：網站睇重嘅係「可控性」“

W3TC 嘅價值唔係在於「佢一定快過人哋」，而係佢俾你足夠多嘅控制掣，令你可以將效能策略變成工程化體系：

  • 頁面快取：可以存在記憶體、磁碟或者 CDN
  • 資料庫物件快取、物件快取：可以用 Redis/Memcached 等等
  • 片段快取：對「半動態頁面」好有意義
  • 移動支援：按推薦人或用戶代理組分別緩存頁面
  • CDN 管理：對媒體庫、主題檔案等進行透明 CDN 管理

呢啲能力對網站尤其有價值，因為全球訪問經常遇到：

  • 同一頁面喺唔同裝置、地區同語言下嘅變體
  • 有啲內容可以緩存、有啲內容必須要實時（例如價錢、存貨、用戶狀態）

4.3 W3TC 嘅「推薦啟用順序」“

推薦順序：

  1. 先淨係啟用頁面緩存
    驗證：TTFB 有冇降低、內容係咪一致、登入狀態/多語言/電商關鍵流程正唔正常。
  2. 再啟用瀏覽器緩存
    目標：等回訪同靜態資源載入快啲，減少跨洲重複下載。
  3. 再評估對象緩存 / 數據庫對象緩存
    適合用喺：動態網站（WooCommerce、會員系統、複雜查詢）。
    唔適合用喺：純內容網站可能收益有限，甚至增加資源消耗。
  4. 最後先處理 壓縮 / 延遲腳本 / 前端優化
    因為呢一層最容易引發功能異常，必須建立回歸測試清單（支付、表單、追蹤、彈出視窗、選單、語言切換等）。

WooCommerce 對「快取插件設定」嘅提醒：重要頁面唔好快取，同埋建議避免壓縮 JS 檔案。

四款插件對比矩陣

注意：呢度唔係講「邊個勁啲」，而係「你嘅情況更適合邊個」。

維度WP RocketLiteSpeed 緩存WP Super CacheW3 全能緩存
核心定位省心一體化（快取+優化）伺服器級快取（依賴 LSCache）靜態 HTML 快取效能框架（多層緩存+CDN）
對主機依賴低（普遍適用）高（需要 LiteSpeed/OpenLiteSpeed 先至可以發揮核心緩存功能）低（普遍適用）中（普遍適用，但更依賴環境/配置能力）
學習成本低至中中低高
內容站推薦度好高好高（條件滿足）好高中至高（睇團隊）
電商/會員站可用但要小心排除（WooCommerce 關鍵頁唔好快取）可用但更加需要規則/分片策略可用，而且 WooCommerce 提到原生兼容並預設唔快取關鍵頁可用，適合工程化控制
預算付費免費免費免費+付費版

“「緩存事故」與預防清單

1. 由於緩存所導致「無效內容」錯誤嘅三大主要原因

A. 將「帶狀態」嘅頁面當成「無狀態靜態頁」“

典型例子：帳戶頁、購物車、結算頁被緩存。WooCommerce 官方反覆強調 購物車 / 結帳 / 帳戶 唔應該被緩存。

B. 多語言/多貨幣/地區變體冇正確區分緩存

如果你嘅網站會根據 cookie、查詢參數、地理位置顯示唔同內容，咁緩存必須考慮「變體維度」。否則 A 地區用戶生成嘅緩存可能會俾 B 地區用戶重用。

C. 前端優化（JS/CSS）改寫導致功能異常

尤其係 JS 壓縮、合併、延遲執行。WooCommerce 甚至建議避免壓縮 JS 檔案。

2. 部署前回歸測試檢查清單

  • 登入/登出係咪正常
  • 表格提交（聯絡表格、訂閱、登入註冊）係咪正常
  • 電商流程：加入購物車 → 使用優惠券 → 運費/稅費 → 付款 → 訂單頁面
  • 多語言切換係咪穩定（切換後內容、網址、hreflang、貨幣）
  • 手機版菜單、彈出視窗、滾動、懶加載係咪正常
  • 追蹤腳本仲有冇觸發（Google Analytics、Meta Pixel、轉換事件）

常見問題

Q1：點解我裝咗緩存插件，海外訪問仲係咁慢？

最常見嘅原因係：你只係解決咗「源站重複渲染」，但冇解決到「跨洲網絡延遲」。
緩存插件可以令伺服器更快吐出內容（TTFB 下降），但靜態資源（圖片、CSS、JS、字體）同全球鏈路嘅 RTT，仍然需要 內容分發網絡 嚟縮短距離。
👉 所以正確路徑係：先將源站緩存做穩陣，再上CDN做全球分發。

Q2：點解緩存之後我改咗內容但係唔更新？

因為你睇到嘅係「舊緩存」。解決思路：

  • 建立清理策略：更新文章/頁面後清理對應緩存（而唔係全站清理）
  • 對於有預熱/爬蟲嘅方案：清理後要再預熱，否則首訪會慢
  • 對於 CDN：需要考慮 CDN 邊緣都可能緩存咗舊資源

Q3：可唔可以同時裝 WP Rocket + WP Super Cache？

唔建議。頁面緩存插件同一時間用一個最穩陣。你可以將「一個做緩存、一個做優化」嘅諗法理解為「分工」，但現實中佢哋經常都會觸碰到頁面緩存/資源改寫，衝突嘅機會好高。更推薦揀一個「主緩存插件」，其他需求用更明確嘅單項工具補齊。

Q4：電商網站用緩存係咪好危險？

唔危險，危險嘅係「冇規則」。WooCommerce 嘅建議好明確：購物車 / 結帳 / 帳戶唔好緩存，同埋避免 JS 壓縮。
另外 WooCommerce 亦都提到佢同 原生支援 WP Super Cache，同預設避免快取關鍵頁面。
所以電商網站完全可以快取，但要當佢係「上線改動」，一定要測試。

Q5：我應該揀 LiteSpeed Cache 定係 WP Rocket？

  • 你確認主機係 LiteSpeed/OpenLiteSpeed 咩？: 優先 LiteSpeed Cache（免費而且勁，核心優勢嚟自伺服器級 LSCache）
  • 你唔肯定主機堆疊 / 唔想搞咁多 / 想要一體化慳心: WP Rocket 更穩陣
  • 你係內容站而且預算敏感: WP Super Cache 更穩、更輕

緩存插件同 CDN 搭配

緩存插件解決嘅係「源站少計、TTFB 更低」；CDN 解決嘅係「靜態資源同頁面更靠近全球用戶」。兩者疊加，先係面向全球訪問嘅常見最優解。

  • 內容站常見組合：頁面緩存 + CDN 靜態分發
  • 動態網站常見組合：頁面緩存（嚴格控制排除）+ 物件緩存（按需要）+ CDN 靜態分發

👉 閱讀：CDN 加速（全球節點同緩存策略）

網站緩存推薦組合

1. 內容網站/博客/文件網站

目標： 降低 TTFB、令首屏更穩定、減輕伺服器壓力、配合 CDN 做全球分發。

1.1 最唔使煩嘅商業組合

  • WP Rocket（頁面緩存 + 預加載 + 前端優化）
    • CDN（放喺 CDN 頁面講）

適用於：

  • 你希望「設定少、見效快、風險低」“
  • 主題/插件多，想減少兼容性折騰

注意事項：

  • 前端優化（尤其係 JS 延遲）要分階段啟用，避免功能異常（例如菜單、表格、追蹤等）
  • 改版/發文頻密嘅網站要有「清理 + 預熱」策略，否則冷門頁面首次訪問會好慢

1.2 免費又穩定嘅經典組合

  • WP Super Cache（靜態 HTML 快取）：將動態頁面生成靜態 HTML，主要服務未登入用戶

適用於：

  • 預算敏感但要穩定
  • 訪問者基本唔登入
  • 內容更新節奏可控

注意事項：

  • 呢個係「頁面緩存優先」嘅組合，唔好指望佢順便解決所有 CSS/JS 複雜問題

2. 企業網站 / 品牌網站 / 落地頁

目標： 速度要快，但更重要係「唔好因為優化搞到轉化鏈路斷咗」。

2.1 穩健可控（推薦全球投放/轉化站）

  • WP Rocket
  • +（可選）輕量嘅圖片優化（你有「圖片優化」頁面）
    • 內容分發網絡

點解適合轉化站：

  • 轉化站最驚「表單/彈出視窗/追蹤腳本俾優化搞壞」“
  • WP Rocket 嘅思路更加「集成化」，你可以喺一個體系裏面逐項啟用同埋回歸測試

企業網站嘅「上線原則」：

  • 效能優化係一次「上線變更」，必須有回歸測試清單
  • 任何涉及 JS 延遲/合併/壓縮嘅設定，都應該先喺預發佈環境驗證，再上線

3. WooCommerce 電子商務網站(訂單及動態頁面安全)

目標： 既要快，亦都要確保購物車、結帳、帳戶等頁面絕對正確。

WooCommerce 官方對快取插件嘅要點非常明確：購物車 / 結帳 / 帳戶 頁面唔好快取，而且仲建議避免壓縮 JavaScript 檔案，以減少兼容性問題。

3.1 更「新手友善」嘅免費安全路線

  • WP Super Cache + WooCommerce
    • 內容分發網絡

點解將佢列為「更安全嘅入門」：

  • WooCommerce 官方提到佢同 WP Super Cache 原生兼容，並會通知 WP Super Cache 默認唔緩存 購物車 / 結賬 / 賬戶 等關鍵頁面
  • 對於啱啱開始做電商嘅網站嚟講，「唔好出事」比「極限性能」更加重要

3.2 如果你用緊 LiteSpeed 主機（免費但好勁）

  • LiteSpeed Cache（一定要係 LiteSpeed/OpenLiteSpeed 主機先可以發揮核心伺服器緩存優勢）
  • +（可選）物件緩存（Redis/Memcached，視乎主機能力同網站規模）
    • 內容分發網絡

適用於：

  • 主機堆疊明確，而且你願意建立緩存規則同排除策略
  • 訂單量、商品量多，需要更強嘅源站抗壓能力

3.3 工程化團隊/複雜電商（多模組可控）

  • W3 Total Cache（性能框架，多緩存層同 CDN 集成）
    • 對象緩存（按需）
    • 內容分發網絡

適用於：

  • 有開發/運維，可以按「模組逐步啟用 + 壓測 + 回歸測試」上線
  • 需要片段緩存/更複雜嘅變體策略（例如按裝置/地區/語言嘅細粒度緩存）

4.會員網站/社群/網上課程(需要經常登入,並提供高度個人化體驗)

目標： 令公共內容快，同時確保「登入用戶內容唔會撈亂」。

4.1 慳心但要嚴格排除策略

  • WP Rocket
  • +（可選）對象緩存（如果動態查詢多）
    • 內容分發網絡

關鍵點：

  • 你必須將「按用戶變化」嘅頁面排除緩存：個人中心、訂單、學習進度、訊息、購物車等
  • 呢類網站最容易出現「睇到人哋嘅內容/權限錯亂」，頁面裏面要將風險講清楚

4.2 LiteSpeed 主機 + 高級策略

  • LiteSpeed Cache（伺服器緩存 + 更複雜嘅策略工具）
  • +（按需）物件快取
    • 內容分發網絡

關鍵點：

  • 會員站往往更需要「可快取主體 + 不可快取片段」嘅思路
  • 預熱同清理策略要更精細，否則「更新後用戶仲睇到舊內容」會好頻密

網站快取「排雷案例庫」“

案例 1：裝咗緩存插件，速度幾乎冇變

現象：

  • 本地/同區域測速都 OK，海外（跨洲）仍然慢
  • TTFB 有改善，但整體載入時間冇明顯下降

常見原因：

  • 你只係做咗源站緩存（TTFB），但係靜態資源（圖片/JS/CSS/字體）仍然要從源站跨洲加載
  • 第三方腳本（廣告、聊天、統計）拖慢咗渲染同互動
  • 圖片體積過大搞到下載慢（緩存解決唔到「第一次下載」嘅體積問題）

解決思路：

  • 緩存插件負責「源站少計 + 命中率」“
  • 靜態資源行 CDN
  • 圖片行圖片優化
  • 第三方腳本做延遲/拆分策略

閱讀：

案例 2：啟用咗緩存之後，改咗頁面但係前台冇更新

現象：

  • 後台已經更新咗內容/樣式，前台仲係顯示舊版本
  • 或者只有部分地區更新，其他地方仲係舊嘅（全球站好常見）

常見原因：

  • 頁面緩存未清理或者清理範圍唔正確
  • 預熱/爬蟲未運行，清理後緩存變凍導致首次訪問慢、同時你誤以為冇更新
  • 如果你啟用咗 CDN 邊緣緩存，邊緣都可能保留舊資源

解決思路：

  • 建立「發布/改版後嘅清理策略」：清理相關頁面，而唔係全站硬性清理
  • 對重要頁面（首頁、核心落地頁）建立預熱策略，避免「清理=變慢」“
  • 有需要時CDN層會做邊緣清理

案例 3：轉咗語言/貨幣之後內容亂晒

現象：

  • 轉咗語言之後頁面仲顯示之前嘅語言
  • 或者某啲地區用戶睇到錯嘅貨幣/內容

常見原因：

  • 緩存冇區分「變體維度」（cookie / 參數 / 語言前綴 / 子域）
  • 緩存命中將 A 語言嘅頁面結果俾咗 B 語言用戶

解決思路：

  • 明確你嘅多語言方案：目錄/子域/參數/cookie
  • 俾緩存規則加上「變體策略」或者對關鍵頁面做排除
  • 有啲網站需要更高級嘅「分片緩存」思路（W3TC 更適合工程化控制）

案例4：電商網站啟用緩存之後，購物車/結算出問題

現象：

  • 購物車數量唔啱、價錢唔啱、結算按鈕失效
  • 登入之後睇到唔屬於自己嘅內容（嚴重）

常見原因：

  • Cart/Checkout/My Account 等關鍵頁面被緩存
  • JS 壓縮/合併導致支付/動態組件不相容

解決思路：

  • WooCommerce 官方明確：購物車 / 結帳 / 帳戶 唔好緩存，並建議避免 JS 檔案壓縮
  • 先將「頁面緩存 + 排除」搞掂，再考慮前端優化
  • 如果用 WP Super Cache，WooCommerce 話佢原生兼容，會預設避開快取啲關鍵頁面

案例五：開咗「延遲 JS/合併腳本」之後，個菜單/表單/彈出視窗壞咗

現象：

  • 導航菜單開唔到
  • 表單驗證失效或者交唔到
  • 彈出視窗/輪播圖異常
  • 統計/轉化事件無觸發（廣告投放網站最頭痛）

常見原因：

  • 延遲 JS 會改變腳本執行時機：用戶互動前腳本唔執行，某啲組件依賴「頁面加載即初始化」“
  • 合併/壓縮可能改變腳本順序或破壞依賴

WP Rocket 官方將「延遲 JS 執行」描述為其最強嘅 JS 優化之一：腳本會推遲到用戶互動後先執行，以優先渲染頁面。呢個功能好勁，但同時意味住更高嘅兼容風險。

解決思路：

  • 分階段啟用：先快取、再圖片、再 CSS、最後 JS
  • 俾關鍵腳本加排除（支付、表單、菜單、追蹤）
  • 每次改動都要做回歸測試清單

案例 6：只係裝咗 LiteSpeed Cache，但係感覺冇乜用

現象：

  • 開咗 LiteSpeed Cache 但係 TTFB 冇降到幾多
  • 命中率都唔明顯

常見原因：

  • 你嘅伺服器唔係 LiteSpeed/OpenLiteSpeed，用唔到 LSCache 嘅核心功能
  • 或者你開咗佢嘅一堆優化，但係「頁面緩存策略/預熱/排除」未建立

解決思路：

  • 先確認主機棧：係咪 LiteSpeed/OpenLiteSpeed（呢個係前提）
  • 將工作重點放返喺「頁面緩存策略 + 預熱 + 排除 + 清理」“
  • 如果唔係 LiteSpeed 主機：考慮用 WP Rocket 或者 WP Super Cache