主頁/指南/網站優化/詳情

網站變慢嘅根本原因通常唔係單一圖片,而係請求鏈 + 伺服器生成 + 靜態資源分發由疊加而得:

  • 用戶離你嘅伺服器太遠,導致網絡往返時間(RTT)過高——尤其係跨洲時更加明顯。
  • WordPress 每次請求都要執行 PHP、查詢資料庫,並渲染模板 → 首次字節時間 (TTFB) 增加
  • 頁面仲要載入 JavaScript、CSS、字體同第三方腳本,令渲染同互動都變慢。

快取插件核心方案有兩點:儲存經過「重複計算」嘅頁面結果,咁伺服器就唔使每次都重新計算;並喺適當策略下,令更多用戶可以命中緩存,從而大幅減少TTFB。WordPress 官方文件亦要注意,例如 W3 Total Cache 同 WP Super Cache 呢啲插件,可以將頁面緩存成靜態檔案,然後直接向用戶提供,從而減輕伺服器嘅處理負擔。

喺閱讀呢頁之前,記住呢三條鐵律。

1. 同一時間只可以使用一個頁面緩存插件。

同時啟用多個緩存插件,幾乎從未帶來更快嘅性能;相反,最常見嘅結果係:

  • 互相覆蓋快取規則、互相清除快取、降低快取命中率
  • 動態內容,例如登入狀態、語言設定、購物車項目同埋價格,都會被緩存,導致顯示錯誤內容嘅情況。
    好多插件嘅文件或指引都會建議,當使用某個緩存插件時,停用其他緩存插件為咗避免衝突

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

WooCommerce 官方效能文件清楚嘅提示:確保喺緩存插件入面 購物車 / 結帳 / 帳戶 確保頁面唔會被緩存,亦建議避免壓縮 JavaScript 檔案(因為咁樣好容易引致相容性問題)。

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

緩存插件解決「來源伺服器計數不足」;CDN 解決方法係「將內容帶得更貼近用戶」。呢兩種方法相輔相成:首先減少原始伺服器嘅 TTFB,然後透過 CDN 分發靜態資源。呢個係向全球用戶提供服務最可靠嘅方法。

快速選擇:最常見嘅4個網站場景

如果你唔想睇晒成篇文章,只要跟住下面呢四點就冇錯:

  1. 追求心靈平靜、穩定同全球可及性 → WP Rocket(收費)
  2. 主機明確係 LiteSpeed/OpenLiteSpeed。 → LiteSpeed 緩存(免費,但高度依賴伺服器能力)需要緩存功能。 LiteSpeed 嘅伺服器組件能夠工作
  3. 內容網站/博客/文件網站尋求免費及穩定嘅託管 → WP Super Cache(靜態HTML緩存)產生靜態 HTML 檔案,以應付大多數未經認證嘅用戶。
  4. 你有技術團隊,需要對(CDN/物件緩存/多個模組)進行精細粒度控制 → W3 全能緩存(強但複雜):集中喺一個同CDN整合嘅全面性能框架

緩存究竟儲咗啲乜嘢?

“「點解有啲網站就算有緩存都仲係咁慢?」我哋將 WordPress 嘅性能拆解成五層:

  1. 瀏覽器快取: 讓用戶下次造訪更快(靜態資源緩存標頭、版本號)
  2. 頁面緩存將頁面輸出緩存為 HTML(本頁面的焦點)
  3. 對象快取緩存資料庫查詢結果物件(對於動態網站特別有用)
  4. PHP OPcache:緩存1TB至184TB嘅字節碼(通常由伺服器配置;唔係插件嘅重點)
  5. CDN/邊緣快取將資源放得更接近用戶

本文集中講解頁面緩存插件;
但佢會不斷提醒你:網站要「真正快」,通常要結合2同5。

插件1:WP Rocket(收費) — 無煩惱嘅一站式整合方案

WP Rocket 喺 WordPress 生態系統入面嘅人氣,並唔係因為佢有咩神奇功效,而係因為佢能夠將三種最常見嘅性能優化措施整合成一個易於管理嘅方案:

  • 頁面緩存 (在源伺服器上減少 TTFB)
  • 緩存預載入/預熱 (在全球分佈式存取下提升首次造訪體驗)
  • 前端關鍵優化(特別係 JavaScript 延遲執行、CSS 處理等等)

佢嘅官方文件明確指出:即使你停用頁面緩存,開啟預載入仍然可以觸發或推動某些優化流程(例如與 CSS/JS 相關的優化)。

1.1 WP Rocket 適合邊啲人用?

WP Rocket 特別適合呢啲網站:

  • 企業網站、品牌網站、內容營銷網站、落地頁(流量來自多個國家及地區)
  • 優先考慮快速部署同穩定性,而唔好追求大量免費插件嘅組合。
  • 冇專責嘅運維或效能工程師,但仍然要求用戶體驗同SEO達到高標準。
  • WoCommerce 佢都可以用,但要更加小心(呢點會喺本節稍後討論)。規則同風險）

1.2 喺網站存取場景中嘅關鍵價值(唔只係一個「緩存開關」)

A. 緩存預載入:解決「因分散式網站存取而導致首次訪問不穩定」“

當網站用戶分散時,你會遇到一種非常典型嘅卡頓:
當某個地區嘅用戶第一次打開某個頁面,而該頁面嘅緩存已經過期或者從未預先抓取 → 該用戶就要承擔完整嘅PHP/DB渲染成本。
預載機制意思係:預先支付「最初一代」嘅成本減少第一次到訪時成為小白鼠嘅可能性

  • 唔預先載入:先到先得
  • 預先載入:由系統在後台集中產生緩存,提供更穩定的首次瀏覽體驗。

B. 延遲執行 JavaScript:呢個功能喺瀏覽網站時最容易令人感受到即時效果,但同時亦最具風險。

WP Rocket 官方聲明:「“延遲執行 JavaScript”被譽為最強大的 JavaScript 優化:佢會將腳本執行延遲到用戶互動(滑鼠移動、觸控輸入、捲動、按鍵等)之後,從而優先渲染頁面。

呢點對網站可及性至關重要,因為腳本載入同執行受阻喺跨洲網絡上更容易被放大:

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

不過,佢亦可能引致一啲問題:

  • 延遲 JavaScript 可能會影響:選單、輪播圖、彈出視窗、表單驗證、付款同埋追蹤實施。
  • 因此,佢好適合用「逐步推進結合黑名單排除」嘅策略。

C. 與其他插件/主題的相容性:安心並不等於「零衝突」。“

WP Rocket 已經特別列出「“不兼容嘅插件/主題”呢份列表包括咗例如佢可能對 WP Rocket 嘅緩存/優化輸出緩衝機制造成嘅影響。

  • 如果你嘅網站裝咗好多插件同埋用緊一個笨重嘅主題,就當「效能優化」係一個細規模嘅部署項目:對每項改動(表單、登入、付款、多語言切換等等)做回歸測試。

1.3 WooCommerce/動態網站嘅特別注意事項

喺 WooCommerce 官方文件入面,關於配置緩存插件時嘅核心提示係:

點解?

  • 購物車、結帳同帳戶頁面高度依賴cookie/會話/一次性密碼
  • 一旦快取將呢啲頁面當成「靜態頁面」處理,最理想都係按鈕冇反應;最差就係價格、存貨數量同帳戶資料會被損毀。
  • 最慘嘅係,你嘅測試喺一個地區可能運作順暢,但因為CDN/快取命中嘅差異,喺另一個地區就會遇到問題。

1.4 緩存插件策略建議

第一層:基礎安全措施(幾乎所有網站都必須具備)

  • 啟用頁面緩存
  • 啟動緩存預載入(提升首次到訪穩定性)
  • 一個合理嘅瀏覽器緩存策略(可以喺任何層面實現:WP Rocket、伺服器或者 CDN)

第二級:中等回報、中等風險(適合大多數以內容為主嘅網站)

  • 懶載圖像 / iframe(更深入了解圖像優化)
  • 控制 CSS 大小(例如移除未用嘅 CSS)

第三級:回報高但風險高(必須有回歸測試檢查清單)

1.5 定價同授權

  • WP Rocket 採用付費授權模式運作,並根據網站數量提供不同許可。

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

關於 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……)

唔太適合:

  • 你唔肯定主機係邊種網頁伺服器,或者你要確認佢係 Nginx/Apache(除非你只係想用佢啲前端優化功能,但咁樣嘅性價比同複雜度可能唔值得)。
  • 你經營緊一個複雜嘅電子商務/會員制/多語言網站,但係冇任何測試流程(LSCWP功能強大,但亦更容易出現「緩存錯誤內容」嘅問題)。

2.2 佢嘅緩存機制:點解佢運作得更似「伺服器功能嘅一部分」“

你可以用一句話,以「工程解釋」嘅形式,總結 LiteSpeed Cache 嘅機制:

  • WP Rocket / WP Super Cache 呢啲措施主要係喺 WordPress/PHP 呢邊做緩存同優化;
  • 長期策略計劃 呢個係「WordPress 儀表板 + LiteSpeed 伺服器內置 LSCache」嘅結合:插件負責處理規則分發同清理訊號,而真正嘅高速度頁面緩存則喺伺服器內部進行。伺服器層。

呢樣嘢直接影響網站嘅用戶體驗:伺服器層面嘅緩存通常較輕量、較快,而且更能夠抵禦同時湧入嘅流量(特別係突發尖峰或者搜尋引擎爬蟲高頻次存取嗰陣)。

2.3 網站用戶情境中 LSCWP 的正確做法“

我哋將「正確嘅做法」分為四個層次:

第一層:頁面緩存策略(決定TTFB能否真正得到縮短)

  • 指定邊啲頁面可以被緩存(大多數公開內容頁面)
  • 識別咩頁面絕對唔可以緩存(登入、帳戶、購物車、結帳,以及高度依賴cookie進行語言/貨幣切換嘅頁面)
  • 為緩存設定一個合理嘅TTL(內容更新頻率越高,TTL就越短;相反,就應該越長)。
  • 制定清理政策:每次內容更新後清除相關標籤(而唔係對整個網站進行全面清理)。

如果呢一層實施得正確,網站就會即刻見到 TTFB 減少,首頁穩定性提升。

第二層:預熱/蠕蟲階段(決定首次瀏覽較不受歡迎頁面時是否會變慢)

喺瀏覽網站時常見嘅「體驗不一致」,係由緩存嘅「冷熱不一致」所致:

  • 熱門頁面持續被存取,緩存永遠保持活躍。
  • 冇人氣嘅頁面好耐冇人撳過,第一個撳佢嘅人會覺得好慢。

預先加載唔只係額外嘅好處,而係保持穩定網站存取體驗嘅基石。

第三層:動態內容安全解決方案(電子商務/會員制/多語言)

LSCWP嘅強項在於佢提供嘅眾多「先進工具」,例如:

  • 為已登入用戶、留言者同其他人制定分層緩存策略
  • Edge-Side Injection (ESI) 嘅核心概念係將網頁拆分成「可緩存嘅靜態內容」同「唔可緩存嘅動態片段」,分別處理之後喺邊緣節點重新組裝。

第4層:網上服務同可選增強功能

好多網站管理員都會喺 LSCWP 入面用到 QUIC.cloud 嘅網上服務(例如頁面優化工具)。QUIC.cloud 文件佢明確表示會為 LSCWP 提供網頁優化服務,包括 Critical CSS (CCSS)、Unique CSS (UCSS) 同 Viewport-Optimised Images (VPI)。

  • 呢啲服務係可揀嘅。你可以只開啟伺服器快取,而唔使開啟線上優化。
  • 一旦啟用網上服務,你嘅網站資源/頁面處理鏈會發生變化(呢項資訊對企業/重視私隱嘅客戶非常重要)。

2.4 LSCWP 嘅常見陷阱

  1. 伺服器唔係 LiteSpeed,但佢竟然當 LSCWP 係一個功能齊全嘅緩存插件。
    結果:緩存嘅效果比預期低,仲增加咗配置複雜度。 解決方案:首先驗證主機堆疊;如果佢唔係 輕量級速度考慮下WP Rocket或者WP Super Cache。
  2. 過度嘅前端優化導致咗功能異常。
    頁面優化(CSS/JS)經常比緩存本身更容易引起相容性問題。建議:首先確保頁面緩存可靠運行,然後逐步開啟優化,並建立回歸測試清單(表單、選單、付款、追蹤、語言切換等)。
  3. 動態頁面冇排除/分隔策略
    典型問題:購物車、結帳同帳戶頁面被緩存;或者多語言/多貨幣切換錯誤。電商網站必須將呢啲視為上線前檢查項目(WooCommerce 官方特別強調)。唔好緩存關鍵頁面）。

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

WP Super Cache 點解佢可以咁耐都咁受歡迎?因為佢解決問題嘅方式非常直接,非常「對伺服器友善」:
由動態 WordPress 頁面產生靜態 HTML 檔案…之後呢啲 HTML 檔案就會由網頁伺服器直接提供,從而繞過昂貴嘅 PHP 處理。

插件頁面亦提到,對絕大多數未經認證嘅用戶都會提供靜態 HTML,並以極其簡單直接嘅方式解釋:「99% 訪客將會獲提供靜態 HTML 檔案」,而單一緩存嘅檔案可被伺服數千次。

3.1 WP Super Cache 適合邊啲人用?

極力推薦:

  • 博客、媒體內容網站、文件網站、企業展示網站、落地頁面
  • 大部分訪客都係未註冊嘅用戶。
  • 你想要:免費、穩定、維護成本低

小心使用/需要更穩健嘅策略:

  • 高度動態嘅網站:大量個人化內容,頁面會因應用戶狀態而改變
  • 大型電商平台:可以使用,但要確保關鍵頁面唔被緩存,並符合你嘅測試程序。

3.2 佢嘅三種緩存方法:

WP Super Cache 插件描述列出三種緩存方法,按速度排序,並解釋佢哋嘅分別:

  • mod_rewrite (專家): 最快嘅方法,完全繞過 PHP,但要修改 .htaccess 檔案;如果設定錯誤,網站無法訪問嘅風險會更高
  • 簡單(建議方法)PHP 為靜態檔案提供「超級快取」,速度可媲美 mod_rewrite,但配置更簡單。
  • WP-Cache 緩存對已知用戶、參數化網址、Feed 等更靈活,但較慢。

建議選擇:

  • 初學者/追求穩定性:使用建議方法(簡單)
  • 你已經完全熟悉伺服器規則,並且願意承擔重寫它們的風險,那麼就考慮專家模式。
  • 你需要更靈活咁處理「已知用戶/帶參數」:了解 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,並會向 WP Super Cache 傳送資訊,確保「購物車」、「結帳」及「我的帳戶」頁面預設不被緩存。

  • 就算你係新手,WP Super Cache 同 WooCommerce 嘅組合都較少會觸發「關鍵頁面被緩存」嘅陷阱。
  • 不過,仍然建議喺上線前做回歸測試(包括付款、優惠券、運費、稅率、多種貨幣等等)。

插件4:W3 全能緩存 (W3TC)——最全面嘅「效能框架」,適合工程團隊

W3 全能緩存 喺 WordPress.org 上,佢唔係被定位成一個「單一緩存插件」,而係更似一個「網站效能優化框架」:透過同 CDN 同埋最佳實踐整合,強調改善 SEO、核心網絡生命指標同整體用戶體驗。

插件描述列出咗一系列廣泛嘅功能:頁面/文章緩存、CSS/JS 緩存、Feed 緩存、搜尋結果緩存、資料庫物件緩存、物件緩存、片段緩存,並支援多種緩存方式,包括 Redis/Memcached/APC。亦包括按用戶代理/推薦人分類嘅手機緩存、AMP 支援,以及反向代理(Nginx/Varnish)整合。

4.1 W3 Total Cache 適合邊啲人用?

非常適合:

  • 你有開發同運維能力,並且願意進行「逐步啟動 + 負載測試 + 回歸測試」。“
  • 你嘅網站好複雜:多語言、多次主題切換、手機版差異化,同埋複雜嘅內容結構。
  • 你唔止想做頁面緩存,仲想將物件緩存/片段緩存整合入系統(特別係動態網站)。

唔適合:

  • 你想安裝完即刻就快,又唔想理緩存分層。
  • 你冇測試流程,卻想一次過開啟高風險功能,例如壓縮同延遲腳本。

4.2 點解會形容佢「強大但複雜」?網站最重視「可控性」。“

W3TC嘅價值唔係話佢天生比其他人快,而係俾你足夠嘅控制參數,將效能策略工程化,並放入一個有系統嘅框架入面:

  • 頁面緩存:可以儲存在記憶體、硬碟,或者1TB或219TB嘅儲存空間
  • 資料庫物件緩存、物件緩存:可使用 Redis/Memcached 等。
  • 片段緩存:對半動態頁面非常有用
  • 手機支援:按轉介來源或用戶代理組別分別緩存頁面
  • CDN 管理:透明管理媒體庫、主題檔案等等。CDN 管理

呢啲功能對網站特別有用,因為全球存取經常會遇到:

  • 喺唔同裝置、地區同語言下同一頁嘅變體
  • 有啲內容可以緩存,而其他內容必須實時(例如價格、庫存、用戶狀態)。

4.3 W3TC嘅「建議啟動順序」“

建議順序:

  1. 一開始只開啟頁面緩存
    驗證:檢查 TTFB 是否已減少、內容是否一致,以及登入狀態/多語言/電子商務關鍵流程是否正常運作。
  2. 重新啟用瀏覽器緩存
    目標:加快重訪同靜態資源載入,盡量減少跨大洲嘅重複下載。
  3. 重新評估物件快取 / 資料庫物件快取
    適用於:動態網站(WooCommerce、會員系統、複雜查詢)。
    唔適用:純內容網站可能回報有限,甚至會增加資源消耗。
  4. 最終處理:壓縮/延遲腳本/前端優化
    由於呢一層最容易觸發功能異常,所以要制定回歸測試檢查清單(包括付款、表格、追蹤、彈出視窗、選單、語言切換等等)。

WooCommerce 緩存插件設定提示關鍵頁面唔應該緩存,而且建議避免壓縮 JavaScript 檔案。

四個插件比較矩陣

注意:呢度唔係講邊個比較勁,而係邊個更適合你嘅情況。

維度WP RocketLiteSpeed 緩存WP Super CacheW3 全能緩存
核心定位無痛整合 (緩存 + 優化)伺服器級緩存(利用 LSCache)靜態 HTML 緩存效能框架 (多層緩存 + CDN)
主機依賴低 (通用)高 (需要 LiteSpeed/OpenLiteSpeed 先可以用核心緩存)低 (通用)中度(通用,但更取決於環境/配置能力)
學習成本低中中低高
內容網站推薦評分好高非常高(只要符合條件)好高中至高(視乎球隊)
電子商務/會員網站可用,但要小心排除(WooCommerce 關鍵頁面唔會緩存)可用,但需要規則/分區策略可用,WooCommerce 表示佢原生相容,而且預設唔會緩存關鍵頁面。可用,適合用於工程控制
預算付款免費免費免費版 + 付費版

“緩存事故及預防檢查清單

1. 緩存導致「錯誤內容」嘅三大根本原因

A. 將有狀態嘅頁面當作無狀態嘅靜態頁面處理“

典型:帳戶頁面、購物車、結帳頁面都會被緩存。WooCommerce 當局一再強調 購物車/結帳/帳戶唔應該被緩存。

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

如果你嘅網站會根據cookie、查詢參數或者地理位置顯示唔同內容,咁緩存就要考慮「變量維度」。否則,喺A區產生嘅緩存可能會俾B區嘅用戶重用。

C. 前端優化(JS/CSS)重寫導致功能異常

特別係 JavaScript 嘅迷你化、合併同延遲執行。WooCommerce 甚至建議避免壓縮 JavaScript 檔案。

2. 推出前回歸測試檢查清單

  • 登入/登出功能運作正常嗎?
  • 表單提交(聯絡表單、訂閱、登入/註冊)運作正常。
  • 電商流程:加入購物車 → 兌換優惠券 → 運費/稅項 → 付款 → 訂單頁面
  • 多語言切換後,內容、URL、hreflang 同貨幣是否穩定?
  • 手機選單、彈出視窗、捲動同懶式載入有冇正常運作?
  • 監察追蹤腳本仲有冇觸發(Google Analytics、Meta Pixel、轉化事件)

常見問題

Q1: 點解我個網站就算裝咗緩存插件,對海外訪客都仲慢?

最常見嘅原因係你只係處理咗「來源伺服器重複渲染」,但未有解決「跨洲網絡延遲」。
緩存插件可以令伺服器更快地傳遞內容(減少首次字節時間),但靜態資源(圖片、CSS、JS、字體)同全球連結往返時間(RTT)仍然需要 CDN 嚟彌補呢個差距
👉 所以正確嘅路徑係:首先,穩定主伺服器嘅緩存。上載到 CDN 作全球分發。

Q2: 點解我修改咗內容之後,有咗緩存都唔更新?

因為你而家見到嘅係「舊緩存」。解決方法:

  • 建立清除緩存政策:更新文章/頁面後清除相應嘅緩存(而唔係對整個網站進行清除)。
  • 對於涉及預熱/爬行嘅解決方案:清理完之後,要再做一次預熱;否則第一次訪問會好慢。
  • 關於CDN:要考慮到CDN邊緣亦可能緩存咗舊資源。

Q3:WP Rocket 同 WP Super Cache 可以同時安裝咩?

唔建議咁做。對於頁面緩存插件,一次只用一個最穩定。雖然你可能會覺得「一個負責緩存,一個負責優化」係一種分工,但實際上佢哋喺頁面緩存同資源重寫呢啲範疇往往有重疊,好大機會會衝突。強烈建議揀一個主要緩存插件,其他需求就用更專門嘅單一用途工具嚟補充。

Q4:電商網站用緩存會唔會幾危險?

唔係危險;危險嘅係冇規則。對 WooCommerce 嘅建議好清楚:購物車/結帳/帳戶頁面唔會被緩存,並避免 JavaScript 最小化。
另外,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頁面講解)

適用於:

  • 你想要最少嘅設定、最快嘅結果同最低嘅風險。“
  • 主題/外掛太多,想盡量減少相容性問題。

需注意嘅事項:

  • 前端優化(特別係 JavaScript 延遲執行)要分階段實施,以免出現功能異常(例如選單、表單、追蹤等等)。
  • 經常重設計或更新內容嘅網站,應該實施「清理同預熱」策略,否則首次瀏覽人氣較低嘅頁面就會好慢。

1.2 自由同可靠嘅經典組合

  • WP Super Cache(靜態 HTML 緩存)由動態頁面產生靜態 HTML,主要供未註冊用戶使用。

適用於:

  • 注重預算又穩定
  • 訪客好少登入。
  • 內容更新的頻率可以控制。

需注意嘅事項:

  • 呢個係「頁面緩存優先」設定;唔好期望佢可以順帶解決晒所有 CSS/JS 嘅複雜性。

2. 公司網站 / 品牌網站 / 落地頁

目標: 速度固然重要,但更重要係「唔好畀優化打亂轉化路徑」。

2.1 穩健可控(建議用於全球部署/轉換網站)

  • WP Rocket
  • + (可選) 輕量級圖片優化(你有一頁「圖片優化」頁面)
    • CDN

點解適合用喺轉換站:

  • 轉化站最怕就係「表單/彈出視窗/追蹤腳本俾人優化到死」。“
  • WP Rocket 採用更整合嘅方法,令你可以喺同一個系統入面逐項啟用功能,並進行回歸測試。

企業網站嘅「啟動原則」:

  • 效能優化屬於「線上部署變更」,必須附上回歸測試檢查清單。
  • 任何涉及 JavaScript 延遲、合併或壓縮嘅設定,都應該先喺 staging 環境驗證好,先至部署到生產環境。

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

目標: 速度固然重要,但我哋亦必須確保購物車、結帳同帳戶等頁面完全正確。

WooCommerce 對緩存插件嘅官方立場好清晰:購物車/結帳/帳戶頁面唔應該被緩存亦建議避免壓縮 JavaScript 檔案,以盡量減少相容性問題。

3.1 一個更適合初學者嘅免費安全路徑

  • WP Super Cache + WooCommerce
    • CDN

點解會列為「更安全嘅入門點」?

  • WooCommerce 官方聲明,佢同 WP Super Cache 原生相容,並會預設通知 WP Super Cache 唔好緩存購物車、結帳同帳戶等關鍵頁面。
  • 對於啱啱起步嘅電商網站,「避免意外」比「發揮最高效能」更重要。

3.2 如果你使用 LiteSpeed 主機(免費但功能強大)

  • LiteSpeed Cache(需要 LiteSpeed/OpenLiteSpeed 主機先可以利用核心伺服器緩存功能)
  • + (可選) 物件快取 (Redis/Memcached,視乎主機能力同網站規模)
    • CDN

適用於:

  • 主機堆疊已經清晰定義,而且你願意建立緩存規則同排除政策。
  • 高訂單量同大量產品,需要更強勁嘅源伺服器先可以應付負荷。

3.3 工程團隊/複雜電子商務(多模組可控)

  • W3 Total Cache(效能框架,多層緩存結合CDN)
    • 物件緩存 (按需)
    • CDN

適用於:

  • 對於開發/運維團隊,部署可以採用「逐步模組啟動 + 負載測試 + 回歸測試」嘅方法。
  • 需要片段緩存/更精緻嘅變體策略(例如按裝置/地區/語言做細粒度緩存)

4.會員門戶/社群/線上課程(高度個人化,支援多種登入狀態)

目標: 確保公共內容能夠快速載入,同時保證已登入用戶嘅內容保持獨立。

4.1 無煩惱,但需要嚴格嘅排除策略

  • WP Rocket
  • + (可選) 物件快取 (如果動態查詢頻繁)
    • CDN

重點:

  • 你必須將根據用戶操作而更改嘅頁面排除出緩存:個人中心、訂單、學習進度、訊息、購物車等等。
  • 呢啲網站最容易出現「瀏覽他人內容/權限錯誤」;頁面必須清楚列明風險。

4.2 LiteSpeed 主機 + 進階策略

  • LiteSpeed Cache(伺服器端緩存 + 更先進嘅策略工具)
  • + (隨需) 物件快取
    • CDN

重點:

  • 會員網站通常需要採用「可緩存內容 + 不可緩存片段」嘅做法。
  • 預熱同清理策略要更加仔細咁優化,否則就會出現「用家更新之後仍然見到過時內容」嘅情況,而且會以驚人嘅頻率發生。

網站快取「排雷案例圖書館」“

案例一:安裝緩存插件後,速度幾乎冇乜改善。

現象:

  • 本地/同地區嘅速度測試都過得去,但海外(跨洲)連線依然好慢。
  • TTFB 有改善,但整體載入時間冇明顯縮短。

共同原因:

  • 你只係實行咗原始伺服器緩存(TTFB),但靜態資源(圖片/JS/CSS/字體)仍然要跨洲從原始伺服器載入。
  • 第三方腳本(廣告、聊天、分析)會減慢渲染同互動速度。
  • 圖片檔案太大,導致下載速度緩慢(緩存無法解決首次下載時檔案大小的問題)。

解決方法:

  • 呢個緩存插件主要處理「減少原始伺服器負載同命中率」。“
  • 透過CDN獲取靜態資源
  • 圖像對圖像優化
  • 第三方腳本用於延遲/拆分策略

閱讀:

案例2:啟用緩存後,頁面被修改,但前端冇更新。

現象:

  • 後端已經更新咗內容同埋樣式,但前端仍然顯示舊版本。
  • 或者只係有啲地區會更新,其他就保持唔變(喺全球網站度好常見)。

共同原因:

  • 頁面緩存未清除,或者清除操作嘅範圍唔正確。
  • 預熱/爬蟲程序未執行,清除完緩存後已經冷卻,導致首次訪問速度緩慢。同時,你誤以為它未有更新。
  • 如果你已啟用CDN邊緣快取,邊緣亦可能保留舊資源。

解決方法:

  • 制定「發佈/修訂後清理政策」:清除相關頁面,而非對整個網站進行硬重設。
  • 為關鍵頁面(首頁、核心落地頁)實施預載入策略,避免「清理 = 變慢」。“
  • 如有需要,請對層CDN進行邊緣清理。

案例3:多語言/多貨幣切換後內容中斷

現象:

  • 切換語言之後,頁面仍然顯示之前嘅語言。
  • 或者喺某啲地區嘅用戶可能會見到錯誤嘅貨幣或錯誤嘅內容。

共同原因:

  • 快取唔會將「變體維度」(cookie / 參數 / 語言前綴 / 子網域)區分開嚟。
  • 一次緩存命中向語言B用戶提供咗 intended for 語言A 嘅頁面。

解決方法:

  • 定義你嘅多語言策略:目錄/子網域/參數/cookie
  • 將「變體策略」應用於快取規則,或排除關鍵頁面
  • 某啲網站需要更進階嘅「分片緩存」方法(W3TC 更適合用嚟做工程層面嘅控制)。

案例4:在電商網站啟用緩存後,購物車/結帳出現問題

現象:

  • 購物車數量錯誤、價格錯誤,同埋結帳按鈕唔運作
  • 登入後,遇到唔屬於自己嘅內容(嚴重)

共同原因:

  • 例如購物車/結帳/我的帳戶等關鍵頁面會被緩存。
  • JavaScript 刨絲/合併導致付款/動態元件不兼容

解決方法:

  • WooCommerce 官方聲明:唔好對購物車、結帳或帳戶頁面做緩存,並建議避免對 JavaScript 檔案進行迷你化。
  • 首先穩定「頁面緩存 + 排除」設定,然後先考慮前端優化。
  • 如果使用 WP Super Cache,WooCommerce 表示原生相容,並會預設避開緩存關鍵頁面。

案例5:啟用「延遲JS/合併腳本」後,選單/表單/彈出視窗失靈。

現象:

  • 導航選單打唔開。
  • 表格驗證失敗或無法提交。
  • 彈出式/滑動卡片功能故障
  • 統計/轉化事件唔觸發(廣告投放最痛苦嘅問題)

共同原因:

  • 延遲 JavaScript 會改變腳本執行嘅時機:腳本唔會喺用戶互動之前執行,而且有啲組件係靠「頁面載入時初始化」運作。“
  • 合併/壓縮可能會更改腳本順序或破壞依賴關係。

WP Rocket 官方將「延遲 JS 執行」描述為其最強大的 JS 優化之一:腳本會延遲到用戶互動之後先執行,以優先渲染頁面。呢個功能非常強大,但同時亦帶嚟更高嘅相容性風險。

解決方法:

  • 分階段啟動:先緩存,再圖片,再CSS,最後JavaScript
  • 向關鍵腳本(付款、表單、菜單、追蹤)新增排除項目
  • 每次修改都要填寫回歸測試檢查清單。

案例6:只安裝咗 LiteSpeed Cache,但發現佢幾無效。

現象:

  • 已啟用 LiteSpeed Cache,但 TTFB 冇乜下降。
  • 命中率唔係特別高。

共同原因:

  • 你嘅伺服器唔係 LiteSpeed/OpenLiteSpeed,所以用唔到 LSCache 嘅核心功能。
  • 或者你已經啟用咗佢嗰套優化措施,但「頁面緩存策略/預熱/排除」仲未設定。

解決方法:

  • 首先,檢查伺服器堆疊係咪 LiteSpeed/OpenLiteSpeed(呢個係先決條件)。
  • 重新集中資源於「頁面緩存策略 + 預載入 + 排除 + 清除」“
  • 如果唔用 LiteSpeed 主機,可以考慮 WP Rocket 或 WP Super Cache。