WordPress快取設定：外掛選擇、排除規則與測速驗證

WordPress 快取是什麼？為什麼會影響網站速度？

WordPress 快取是把原本需要即時計算的頁面、檔案或資料暫存起來，讓訪客下次開啟時不用重新跑完整的 PHP 與資料庫流程，因此通常能降低 TTFB（伺服器第一個位元組回應時間）並改善載入速度。

WordPress 頁面多半由主題、外掛、資料庫查詢和 PHP 動態產生。沒有快取時，每一次訪客進站，伺服器都要重新組出同一個頁面；有快取後，系統可以直接交出已經產生好的版本。我的判斷是，只要是內容型網站、小型企業官網或流量穩定的部落格，頁面快取幾乎都應該列為基本設定。

WordPress 為什麼需要快取？

WordPress 需要快取，主因是它本來就是動態 CMS。文章頁、分類頁、首頁、選單、小工具與外掛輸出，都可能牽涉資料庫查詢。當流量變多時，重複查詢會讓主機負載升高，頁面反應變慢。

頁面快取可以把已產生的 HTML 暫存起來；瀏覽器快取可以讓訪客的瀏覽器保存 CSS、JavaScript、字型和圖片；Object Cache（物件快取）則偏向暫存資料庫查詢結果。三者處理的位置不同，不能混為一談。

快取主要改善哪些速度問題？

快取最直接改善的是 TTFB 與 LCP（最大內容繪製時間）。TTFB 變短，代表伺服器更快開始回應；LCP 變好，常見原因是主內容更早開始載入。對 SEO 負責人來說，這比只看 PageSpeed Insights 分數更實際。

快取也能降低尖峰時段的主機壓力，尤其是新聞站、活動頁、品牌官網首頁和有大量自然搜尋流量的文章頁。若快取預載設定得好，訪客不必當第一個產生快取的人，體感速度會更穩。

快取不會自動解決哪些問題？

快取不會自動修好過大的圖片、劣化的主題程式、過多第三方追蹤碼、版面位移或互動延遲。CLS（累計版面配置位移）通常要從圖片尺寸、廣告版位、字型載入處理；INP（與下一次繪製的互動延遲）則常和 JavaScript 執行量有關。

這也是很多站長踩雷的地方：快取外掛裝了，分數卻沒有大幅上升。問題不一定是快取無效，而是瓶頸根本不在快取層。快取應該先把伺服器回應穩住，再搭配前端與內容資源整理。

WordPress 快取外掛怎麼選？WP Rocket、W3 Total Cache 與其他外掛差在哪？

選 WordPress 快取外掛時，先看主機環境、網站類型與維護能力。新手或商業網站通常選 WP Rocket 較穩；需要細部控制的技術維護者可考慮 W3 Total Cache；LiteSpeed 主機則優先評估 LiteSpeed Cache。

快速決策表：不同網站該選哪一套

網站情境	優先選擇	設定策略	注意事項
一般部落格或企業官網	WP Rocket	建議開啟頁面快取、預載、瀏覽器快取，CSS / JS 功能逐項測試	不要一次打開所有檔案最佳化
LiteSpeed 主機	LiteSpeed Cache	建議搭配主機層快取使用	非 LiteSpeed 環境不一定能完整發揮
WooCommerce 商店	WP Rocket 或 W3 Total Cache	先排除購物車、結帳、我的帳戶，再測試檔案最佳化	交易流程不能盲目快取
會員站或課程站	W3 Total Cache 或主機快取方案	需測試登入狀態、會員內容與表單	登入後頁面通常要排除
新聞站或高流量內容站	W3 Total Cache、WP Rocket、主機快取	需搭配快取預載與清除規則	更新頻率高，快取壽命要保守
Elementor 網站	WP Rocket	頁面快取可開，CSS / JS 延遲需逐頁測試	前台互動元件較容易受影響

WP Rocket 適合誰？

WP Rocket 適合想要少踩雷的新手站長、接案架站者與一般商業網站。它的介面比較集中，常見功能包含 Cache、File Optimization、Preload、Media、Database、CDN 與 Advanced Rules。官方文件也清楚列出預載與排除規則，可參考 WP Rocket Preload 說明 與 排除快取文件。

我的實務建議是，WP Rocket 的強項不是功能最多，而是安全預設值比較容易管理。對沒有工程人員的網站來說，能穩定維護比多幾個進階開關更重要。

W3 Total Cache 適合誰？

W3 Total Cache 適合需要控制 Page Cache、Minify、Browser Cache、Object Cache、Database Cache、CDN 等細節的維護者。它的彈性高，但設定頁也更複雜，適合懂得分段測試的人使用。外掛官方支援文件可從 W3 Total Cache Documentation 查到各模組說明。

如果站上有 WooCommerce、會員系統、客製化 AJAX、搜尋頁或複雜表單，W3 Total Cache 可以調得很細，但也代表更需要測試紀錄。沒有測試流程時，功能越多反而越容易出錯。

LiteSpeed Cache、WP Fastest Cache、Breeze 什麼情況可考慮？

LiteSpeed Cache 適合使用 LiteSpeed Web Server 或 OpenLiteSpeed 的主機；WP Fastest Cache 適合想要簡化設定的小型網站；Breeze 常見於 Cloudways 類型主機環境。這些外掛可以考慮，但本文主軸仍放在 WP Rocket 與 W3 Total Cache 的設定。

Autoptimize 則要特別分清楚，它偏向前端最佳化外掛，常用於 CSS、JavaScript、HTML 最佳化，不是傳統頁面快取外掛。若和快取外掛一起用，請避免兩邊同時壓縮同一類 CSS / JS。

WP Rocket 設定教學：新手最穩的快取設定流程

WP Rocket 設定的穩定做法是先開頁面快取與預載，再逐項測試 CSS / JS、Lazy Load、資料庫清理與 CDN。每開一項高風險功能，就要用無痕視窗檢查首頁、文章頁、表單頁與手機版。

Cache 設定

Cache 頁籤是 WP Rocket 的基本盤。一般網站建議開啟行動裝置快取；如果網站沒有針對手機輸出完全不同的 HTML，通常可以讓手機與桌機使用一致的快取策略。

WP Rocket 設定項目	建議狀態	適用情境	測試重點
Enable caching for mobile devices	適合開啟	大多數響應式網站	手機版選單與版面是否正常
Separate cache files for mobile devices	需測試後再開	手機與桌機輸出差異大的網站	手機版是否看到正確內容
User Cache	暫時不要開	會員站需進階測試時才考慮	登入後內容是否混到其他使用者狀態

File Optimization 設定

File Optimization 是最容易讓網站壞版的區域。Minify CSS files、Optimize CSS delivery、Minify JavaScript files、Load JavaScript deferred、Delay JavaScript execution 都不應一次全開。

建議先備份，再依序測試：先開 CSS 壓縮，檢查版面；再測 JavaScript 延遲，檢查選單、輪播、表單、購物車、追蹤碼與彈窗。我的判斷是，商業站寧可少拿幾分測速分數，也不要讓轉換元件失效。

Preload 設定

Preload（快取預載）建議開啟，因為它能主動建立快取，不必等第一位訪客觸發。WP Rocket 可依 Sitemap 或 WordPress 預設 Sitemap 進行預載，官方文件也說明清除快取後可重新預載。

Sitemap 網址本身不建議被頁面快取長時間卡住，但可用於協助預載。若網站每天大量更新，預載會消耗主機資源，應觀察 CPU 與後台反應，不要把過期時間設得過短。

Media 與 Lazy Load 設定

Media 設定中的 Lazy Load（延遲載入）適合圖片較多的文章站與部落格，但首屏主圖、Logo、重要橫幅不一定適合延遲載入。若 LCP 元素被延遲載入，PageSpeed Insights 反而可能變差。

建議開啟圖片與 iframe 延遲載入後，檢查首頁、文章頁與產品頁首屏。若上方主圖晚出現，就要排除該圖片或關閉相關設定。

Database 與 CDN 設定

Database 清理適合定期處理文章修訂版、垃圾留言、暫存資料與過期 transients，但第一次操作前要備份資料庫。這類清理不等於快取本身，屬於輔助維護。

CDN 設定只有在你真的使用 CDN 時才需要設定。若同時使用 Cloudflare，清除 WP Rocket 快取不代表 Cloudflare Edge Cache 一定同步清掉，兩層要分開理解。

WP Rocket 設定後檢查清單

• 首頁、文章頁、分類頁以無痕視窗檢查一次。
• 手機版選單、搜尋、表單、留言功能可正常操作。
• WooCommerce 的購物車、結帳、我的帳戶沒有被快取。
• CSS / JS 最佳化每次只新增一項，測完再開下一項。
• 更新文章後，清除快取並確認前台內容有更新。
• 使用 PageSpeed Insights 前後測同一組網址，不比較不同頁型。

W3 Total Cache 設定教學：進階站點的快取設定流程

W3 Total Cache 設定應從 Page Cache 與 Browser Cache 開始，Minify、Object Cache、Database Cache、CDN 都要依主機與網站功能測試後再開。它適合需要細部控制的人，不適合盲目套用別人的完整設定。

Page Cache 設定

Page Cache 是 W3 Total Cache 最核心的功能，一般 WordPress 內容站建議開啟。Cache Method 若在一般共享主機或普通 VPS，可從 Disk 類型開始；若主機商有提供特定方案，應依主機文件設定。

啟用後請排除後台、登入頁、搜尋結果頁、交易流程頁與會員動態頁。若網站有高頻更新首頁，快取壽命要比長青文章更保守。

Minify 設定

Minify 可以壓縮 HTML、CSS、JavaScript，但這是 W3 Total Cache 最需要小心的設定之一。建議先不要開自動合併所有檔案，先從 CSS 或 HTML 壓縮測試，再看 JavaScript 是否能延遲或合併。

若網站使用 Elementor、Slider、表單外掛、廣告外掛或多組追蹤碼，JavaScript Minify 應列為需測試後再開。按鈕無法點、選單無法展開、表單無法送出，常常都和這一層有關。

Browser Cache 設定

Browser Cache 建議開啟，讓瀏覽器保存靜態資源。常見設定包含 GZIP 壓縮、Cache-Control Header、Expires Header 與 ETag 管理。這一層通常風險較低，但仍要檢查 CSS 與 JavaScript 更新後是否能正確刷新。

若前台一直看到舊樣式，問題可能是瀏覽器快取期限太長，也可能是 CDN 還沒清除。不要只在 WordPress 後台按清除快取就判定問題已解決。

Object Cache 設定

Object Cache 適合資料庫查詢頻繁的網站，但不是每個站都應該開。若主機沒有 Redis 或 Memcached 支援，只用磁碟型 Object Cache，有時反而增加負擔。

WooCommerce、會員站、論壇和高查詢量網站可以評估 Redis 快取，但要先確認主機支援。一般小型內容站若沒有明顯資料庫瓶頸，可以先不要開 Object Cache。

CDN 與進階設定

W3 Total Cache 可串接 CDN，把靜態檔案交給 CDN 發送。這適合跨區流量、圖片與靜態資源多的網站，但不等於所有 HTML 都應交給 CDN 快取。

若你同時使用 Cloudflare，要確認 Cloudflare 快取規則、W3 Total Cache CDN 設定與 WordPress 外掛清除機制是否互相衝突。Cloudflare 的清除和 WordPress 外掛清除是不同層級。

W3 Total Cache 設定後檢查清單

檢查項目	建議狀態	檢查方式
Page Cache	適合開啟	無痕視窗檢查頁面是否正常載入
Minify	需測試後再開	檢查 CSS、選單、表單、購物流程
Browser Cache	適合開啟	用 Chrome DevTools 檢查 Header
Object Cache	視情況開啟	確認 Redis 或 Memcached 支援
Database Cache	一般站暫時不要開	觀察後台與前台是否變慢
CDN	有使用 CDN 才開	檢查靜態資源網址與清除流程

WordPress 快取類型一次看懂

WordPress 快取不是只有一種，常見層級包含 Browser Cache、Page Cache、Object Cache、Fragment Cache、Edge Cache、OPcache、Redis 與 Memcached。設定前先分清楚層級，才不會重複啟用同一類快取。

Browser Cache、Page Cache、Object Cache 的差異

Browser Cache 是存在訪客瀏覽器端，處理 CSS、JavaScript、圖片、字型等靜態資源。Page Cache 是把 WordPress 產出的頁面 HTML 暫存起來。Object Cache 是暫存資料庫查詢或物件結果，常搭配 Redis 或 Memcached。

對大多數網站，優先順序是 Page Cache，再來 Browser Cache，最後才評估 Object Cache。這個順序比較符合實務風險，因為頁面快取最容易看到速度差異，也比較好驗證。

Fragment Cache、Edge Cache、OPcache 是什麼？

Fragment Cache 是針對頁面中某些區塊快取，例如商品推薦、選單區塊或特定短碼輸出。Edge Cache 是在 CDN 節點上快取內容，Cloudflare 就屬於常見 Edge 層級。OPcache 則是 PHP 層級的快取，通常由主機環境管理。

這些快取不一定都要由 WordPress 外掛處理。主機、CDN、外掛各管一層時，要記錄清楚誰負責什麼，否則壞版時會不知道該清哪一層。

Redis 快取與 Memcached 什麼時候需要？

Redis 與 Memcached 常用於 Object Cache。當網站有大量登入使用者、商品查詢、會員權限判斷或複雜資料查詢時，才比較有評估價值。

小型內容站一開始不用急著開 Redis。若主機支援良好，可以測試；若主機資源有限或設定不完整，開了 Object Cache 反而可能讓後台變慢。

哪些頁面與檔案不該被快取？

不該被快取的頁面通常包含交易頁、會員頁、登入頁、搜尋頁、Sitemap、REST API、動態表單與依使用者狀態變化的內容。這些頁面快取錯，可能顯示舊資料或別人的狀態。

WooCommerce 必排除頁面

WooCommerce 的 cart、checkout、my-account 頁面應排除快取。WP Rocket 官方文件也提到，部分電商外掛的購物車、結帳與我的帳戶頁會自動排除，但實務上仍建議自己檢查規則是否存在。

類型	常見路徑	建議狀態	原因
購物車	/cart/	必須排除	內容依使用者購物狀態變化
結帳頁	/checkout/	必須排除	牽涉付款、運送、訂單資訊
我的帳戶	/my-account/	必須排除	登入後顯示個人訂單與資料
加入購物車參數	?add-to-cart=	必須排除或特殊處理	會影響購物車狀態

會員站與登入頁排除

會員登入頁、註冊頁、忘記密碼頁、會員中心、課程進度頁與付費內容頁，通常都不適合一般頁面快取。若每個會員看到的內容不同，更要排除。

若會員站真的需要快取，應採用更細的規則，例如只快取公開頁面，不快取登入後頁面。不要為了 PageSpeed 分數犧牲會員權限正確性。

Sitemap、搜尋頁、API 與動態表單

Sitemap 可以用來協助快取預載，但 sitemap.xml 本身不建議被長時間頁面快取，避免搜尋引擎讀到過舊的網址清單。搜尋結果頁也不建議盲目快取，因為查詢參數變化多。

REST API、AJAX 請求、聯絡表單、篩選器、即時報名表、庫存查詢和匯率類資料，都要視情況排除。只要內容會依使用者、時間或查詢條件變動，就不應直接套用一般頁面快取。

排除規則寫錯會發生什麼事？

排除規則寫錯時，可能會出現購物車顯示別人的商品、會員看到錯誤權限、表單送不出去、搜尋結果固定不變、Sitemap 長時間不更新。這些問題不一定會立刻被發現，常常是使用者回報後才浮出來。

我的做法是，每次修改快取排除規則，都要保留一份紀錄：修改時間、修改項目、測試頁面、是否清除 CDN。這比事後猜問題來源有效得多。

快取預載怎麼設定才有效？

快取預載要有效，必須讓外掛根據 Sitemap 或指定網址提前建立快取，並搭配合理的過期時間與清除規則。預載不是開了就好，還要避免過度消耗主機資源。

Preload、Sitemap 與快取壽命

WP Rocket 可透過預載功能主動建立頁面快取；W3 Total Cache 也可透過相關設定或排程思路管理快取生成。內容站可用 Sitemap 當預載來源，讓重要文章、分類頁與首頁先有快取。

快取壽命不需要一律越短越好。更新頻率低的文章頁可以保留較久；首頁、活動頁、庫存頁、新聞分類頁則要更保守。設定太短會一直重建快取，設定太長會讓前台看到舊內容。

什麼網站更需要預載？

自然搜尋流量分散到大量文章頁的網站，很需要預載。因為長尾頁面可能久久才有人開一次，若沒有預載，第一位訪客可能會承受未快取的慢速度。

新聞站、活動站和大量分類頁網站也適合預載，但要避免在主機資源不足時高頻爬全站。若後台變慢或主機 CPU 飆高，應降低預載頻率或縮小預載範圍。

設定完 WordPress 快取後，怎麼測速與驗證？

設定完 WordPress 快取後，應用同一組網址做前後測，搭配 PageSpeed Insights、GTmetrix、WebPageTest、Chrome DevTools、HTTP Header 與無痕視窗驗證。不要只看單次分數。

PageSpeed Insights、GTmetrix、WebPageTest 怎麼看？

PageSpeed Insights 會同時提供實驗室資料與真實使用者資料，Google 官方說明可參考 PageSpeed Insights 文件。Core Web Vitals 的主要指標包含 LCP、INP、CLS，Google Search Central 也有 Core Web Vitals 說明。

GTmetrix 適合看瀑布圖與資源載入順序；WebPageTest 適合更細地看 TTFB、重複載入與不同地區測試。SEO 負責人要比較的是同一頁在快取前後的趨勢，不是今天首頁 95 分、明天文章頁 82 分這種不對等比較。

HTTP Header 與無痕視窗檢查

HTTP Header 可以看快取是否命中，常見線索包含 cache-control、age、x-cache、cf-cache-status 等欄位。不同主機和 CDN 顯示名稱不同，不必要求每個網站都一樣。

無痕視窗可以排除一部分登入狀態干擾。測試時應檢查首頁、文章頁、分類頁、重要轉換頁、手機版頁面。若有 Cloudflare，還要分開測 WordPress 快取與 Cloudflare 快取。

Core Web Vitals 對應快取該怎麼判斷？

快取主要有機會改善 TTFB 與 LCP。若 LCP 元素是文字或首屏圖片，頁面回應變快通常有幫助；但如果首屏圖片太大或被 Lazy Load 誤傷，LCP 仍可能不理想。

CLS 多半不是快取能處理的問題，應回到版面空間、圖片尺寸、字型與廣告插入。INP 則常和 JavaScript 有關，延遲載入 JS 可能改善，也可能讓互動元件變慢，所以一定要測前台操作。

快取造成網站壞版或舊內容怎麼辦？

快取造成壞版或舊內容時，先分辨是外掛快取、瀏覽器快取、CDN 快取，還是 CSS / JS 最佳化造成。不要一開始就停用所有外掛，應按層級清除與回復設定。

更新文章後前台沒有變

先清 WordPress 快取外掛，再用無痕視窗打開文章頁。如果仍然是舊內容，清瀏覽器快取或換裝置測試。若使用 Cloudflare，再清 Cloudflare 快取。

若只有部分頁面沒更新，檢查是否有預載或快取壽命設定過長。若 Sitemap 更新了但前台沒變，問題通常不在 Sitemap，而是在頁面快取或 CDN。

CSS 亂掉或版面跑掉

CSS 壞版時，先關閉最近開啟的 CSS Minify、Combine CSS、Remove Unused CSS 或 Optimize CSS Delivery。回復後清快取，再檢查前台。

如果只有手機版壞掉，要檢查是否啟用了手機分離快取，或主題對手機載入不同 CSS。我的經驗是，版面跑掉最常不是頁面快取本身，而是 CSS 最佳化設定太貪心。

按鈕、選單、表單失效

按鈕、選單、表單失效時，優先檢查 JavaScript Minify、Defer JavaScript、Delay JavaScript Execution。這些功能對速度分數有吸引力，但也最容易破壞互動。

測試順序建議從全關 JS 最佳化開始，確認功能恢復後，再逐項打開。每次只開一項，才知道是哪一個設定造成問題。

手機版和桌機版不同步

手機版和桌機版不同步時，檢查是否使用 Separate mobile cache、AMP、手機版主題或 CDN 裝置快取規則。若手機與桌機 HTML 不同，不能用同一套快取邏輯硬套。

測試時請用真實手機或瀏覽器裝置模式各看一次，並清掉外掛與 CDN 快取。只在桌機瀏覽器縮小視窗，有時看不到真正的手機輸出問題。

外掛快取、瀏覽器快取、Cloudflare 快取要清哪一個？

問題現象	先清哪一層	下一步
文章內容沒更新	WordPress 外掛快取	再清 CDN 快取並用無痕視窗測試
只有自己電腦看到舊樣式	瀏覽器快取	換瀏覽器或無痕視窗確認
所有人都看到舊版靜態檔	CDN 快取	檢查檔案版本與 CDN 規則
互動功能失效	CSS / JS 最佳化設定	停用最近新增的 Minify、Defer、Delay

只裝快取外掛夠嗎？WordPress 速度優化的正確順序

只裝快取外掛通常不夠。正確順序是先確認主機與 PHP 版本，再處理圖片、頁面快取、CSS / JS、Lazy Load、Core Web Vitals 與 CDN。快取是基礎，不是全部。

先處理主機、PHP 版本與基本資源

如果主機本身回應很慢，WordPress 快取只能緩解，不能根治。建議先確認主機穩定性、PHP 版本、HTTPS、資料庫負載與外掛數量。需要評估主機選擇時，可延伸閱讀 雲端主機選擇指南。

圖片也要先控制尺寸與格式。快取可以讓檔案更快被送出，但不會把過大的圖片自動變合理。這部分和 Core Web Vitals 優化、CLS 修正 都有關。

再處理快取、Lazy Load、CSS / JS

頁面快取穩定後，再測 Lazy Load 與 CSS / JS 最佳化。這些功能對分數有幫助，但也可能影響版面與互動，所以一定要分段開啟。

若網站還在選 CMS 或規劃架構階段，可以先看 2026 CMS 選擇指南。架構選錯後，再靠快取外掛補救，成本會高很多。

WordPress 快取是什麼？

WordPress 快取是把動態產生的頁面或資源暫存起來，減少 PHP 與資料庫重複處理。常見類型包含頁面快取、瀏覽器快取、物件快取與 CDN 快取。

WordPress 一定要裝快取外掛嗎？

多數 WordPress 網站建議使用快取，但不一定都要靠外掛。如果主機已提供完整伺服器快取，外掛可能只負責清除、預載或前端最佳化。不要同時啟用多個外掛處理同一層頁面快取。

WP Rocket 和 W3 Total Cache 哪個比較適合新手？

WP Rocket 較適合新手，設定介面集中，安全預設值比較容易管理。W3 Total Cache 功能更細，適合懂得分段測試、需要控制快取層級的維護者。

可以同時安裝兩個 WordPress 快取外掛嗎？

不建議同時安裝兩個處理同一層快取的外掛，例如兩個頁面快取外掛一起開。若要搭配前端最佳化外掛，必須確認 CSS / JS 壓縮、延遲載入與合併功能沒有重複。

為什麼清快取後，前台還是看到舊內容？

可能是瀏覽器快取、CDN 快取、主機快取或外掛快取其中一層還沒清除。建議先清 WordPress 外掛快取，再用無痕視窗檢查；若有 Cloudflare，再清 Cloudflare 快取。

CSS / JS 壓縮開啟後網站壞版怎麼辦？

先關閉最近啟用的 CSS / JS 壓縮、合併、延遲或移除未使用 CSS 功能，清除快取後重新檢查前台。恢復正常後，再一次只開一項設定測試。

WooCommerce 購物車和結帳頁可以快取嗎？

不建議快取 WooCommerce 購物車、結帳頁與我的帳戶頁。這些頁面會依使用者狀態變化，快取錯可能造成購物車內容、訂單資料或會員資訊顯示異常。

Sitemap 需要排除快取嗎？

Sitemap 可用於快取預載來源，但 sitemap.xml 本身不建議被長時間頁面快取。網站更新頻繁時，過舊的 Sitemap 可能讓搜尋引擎讀到不準確的網址清單。

Autoptimize 是快取外掛嗎？可以和快取外掛一起用嗎？

Autoptimize 主要偏向前端最佳化，常用於 CSS、JavaScript、HTML 最佳化，不是傳統頁面快取外掛。可以和快取外掛搭配，但要避免兩邊同時壓縮或延遲同一類檔案。

WordPress 快取會改善 Core Web Vitals 嗎？

WordPress 快取通常有助於 TTFB 與 LCP，但不一定改善 CLS 或 INP。CLS 多半要處理版面穩定性，INP 則常和 JavaScript 執行與互動反應有關。

W3 Total Cache 的 Object Cache 一定要開嗎？

不一定。Object Cache 適合資料庫查詢頻繁、且主機支援 Redis 或 Memcached 的網站。一般小型內容站若沒有明顯資料庫瓶頸，可以先不要開。

設定快取後要用什麼工具測速？

建議使用 PageSpeed Insights、GTmetrix、WebPageTest、Chrome DevTools 與無痕視窗交叉檢查。測試時使用同一組網址做前後比較，不要只看單次分數高低。