快取 Cache 是什麼？清除設定一次學會

說不定你也遇過這種狀況：網站明明裝了快取外掛，測速分數也跑得很漂亮，但客人下單後才發現商品根本沒庫存。以一個 WooCommerce 甜點電商的示意情境來看，如果商品列表頁被全頁快取，過期的庫存狀態就可能繼續送給訪客。問題不在「有沒有快取」，而在設定者是否釐清什麼該存、什麼不該存。

快取（Cache）換句話說，就一句話：把算過一次的東西先抄一份放著，下次直接用抄本，不重算。聽起來很簡單，但一個網站從訪客按下 Enter 到畫面出現，可能涉及瀏覽器、CDN、頁面、物件與 Opcode 等快取層；不是每個網站都會同時使用全部五層。搞懂各層存在哪裡、保存多久、由誰失效，才知道為什麼改了內容卻看不到更新，也能避免只靠反覆「清除快取」碰運氣。

快速總覽：快取是把重複運算的結果先存一份，讓下一次請求直接命中、不再重算的機制。常見層級包括瀏覽器、CDN、頁面、物件與 Opcode 快取，每一層都有適用範圍和失效方式。裝對外掛只是起點，個人化或即時變動的頁面通常需要排除，或使用能正確區分使用者與參數的快取規則。

快取到底是什麼？用一個你每天都在用的場景講清楚

我比較不喜歡用「圖書館」或「倉庫」那種硬邦邦的比喻來解釋快取，因為那會讓人誤以為快取是一個固定的地方。其實它更像辦公室裡那張你貼在螢幕邊緣的便條紙。

想像一下：你是辦公室裡最資深的那個人，每個同事都跑來問你同一個問題「報表要交到哪個資料夾」。第一次你認真回答、還順便示範一次流程。第二次、第三次、第二十次，你開始煩了，於是把答案寫在便條紙上貼在螢幕旁邊。下次再有人問，你指一指那張紙就好，不用再從頭解釋。那張便條紙，就是快取。

網站做的事完全一樣。當一個訪客打開你的文章頁，伺服器要做的事可多了：去資料庫把文章內容撈出來、把作者資訊撈出來、把側邊欄的熱門文章撈出來、跑版型把這些東西組成完整的 HTML、再送到訪客的瀏覽器。這一整套流程，如果是 WordPress 這種動態產生的網站，單次可能要執行幾十到幾百次資料庫查詢。第二個訪客來、第三個訪客來、第一千個訪客來，全部都要重跑一遍。

快取做的事情就是：第一次組好的那份 HTML，先抄一份存起來。第二個訪客來的時候，伺服器直接把這份抄本丟出去，跳過資料庫查詢、跳過版型組裝、跳過 PHP 運算。結果就是回應時間從一兩秒壓縮到幾十毫秒，伺服器負載也跟著大幅下降。

這裡有一個關鍵觀念要先建立起來：快取的本質是用「可能過期」換取「速度」。那份抄本是某一個時間點的快照，它不會自動知道你後來改了內容。這就是為什麼快取永遠伴隨著「失效機制」這個課題，也為什麼清除快取會變成一種日常操作。沒有失效機制的快取，就像一張永遠撕不下來的便條紙，上面寫著過時的答案，卻被每個人當真。

速度慢等於生意跑掉：快取為什麼是網站的命根

你可能會想，慢一點有什麼關係，內容好就好了。這個想法在十年前或許成立，現在已經不適用了。Google 在 web.dev 上的研究很早就點出一個殘酷的事實：當頁面載入時間從一秒拉長到三秒，訪客離開的機率會大幅上升；拉長到五秒以上，彈出率更是直線上升。背後的道理很直白，沒有人願意在螢幕前面盯著轉圈圈發呆。

速度先影響的是使用體驗，Google 的排名系統也會使用 Core Web Vitals 等網頁體驗訊號，但它們只是眾多訊號的一部分，良好分數不保證取得較高排名。LCP（最大內容繪製）、INP（互動到下次繪製）、CLS（累計版面位移）可用來量化部分真實使用體驗；正確的網站快取設定則是 技術性 SEO 中常見的效能手段（見 Google 2018 年 1 月的行動搜尋速度公告與 Core Web Vitals 官方說明）。

「網頁體驗」（page experience）不是一個單一綜合分數。Google 建議從 Core Web Vitals、安全連線、行動裝置呈現與干擾性插頁等面向整體檢查，而非只追求某一項工具分數。快取的角色，是縮短可重複使用資源與 HTML 的取得時間；它可能改善 LCP，但無法單獨解決版面位移、主執行緒阻塞等問題（見 Google 對頁面體驗的說明）。

如果你還沒接觸過 Core Web Vitals 的實戰優化，建議先讀過我們整理的 Core Web Vitals 完全攻略，再回來看快取這一塊會更有感。對速度優化本身有興趣的，可以一併參考 Core Web Vitals 實戰。

快取也能降低來源站負載，減少流量尖峰時回傳 5xx 的機率。對規模很大的網站，伺服器可用性與回應狀況可能影響 Googlebot 的抓取節奏；但快取不是多數網站需要優先操作的「爬取預算」槓桿。想進一步判斷網站規模與抓取需求，可延伸閱讀 爬取預算優化策略。

一張表看懂：五層快取各管什麼事

很多人以為「快取」就是裝一個外掛勾一勾就結束了，其實一個請求可能經過下面幾種快取層。每一層存的東西、存在哪裡、誰負責讓它失效都不同；只清其中一層，訪客仍可能拿到舊版本。

這五層是「疊加」的關係，不是二選一。一個請求可能同時被瀏覽器快取、CDN 快取、頁面快取三層同時命中。這也是為什麼當你改了內容卻看不到更新，常常是因為你只清了其中一層，剩下兩層還握著舊版本。我後面會講到怎麼系統性地處理這個問題。

多層快取打架的時候，先抓最靠近訪客的那一層

有一種常見的情況是這樣的：站長抱怨「改了首頁的橫幅圖，過了三天才看得到更新」。他已經清了 WP Rocket 的頁面快取、也清了瀏覽器快取，問題還在。後來才查出是 CDN 那一層握著舊的 HTML 沒放，因為他的 CDN 快取規則設成了「快取所有 HTML、過期時間七天」，而 WP Rocket 的自動清除根本通知不到 CDN。

遇到這種「清了還是舊的」的情況，排查的順序有一個原則：從最靠近訪客的那一層開始往回追。一個請求是先經過瀏覽器、再到 CDN、再到你的伺服器頁面快取、再到物件快取。任何一層握著舊版本，後面幾層清得再乾淨也沒用，因為請求根本走不到那裡。

實務上可以先用無痕視窗測試，再檢查回應標頭與 CDN 提供的快取狀態，例如 Age、Cache-Status 或供應商自訂標頭。網址後加查詢字串有時能協助辨識 cache key，但不同 CDN 與外掛可能忽略、包含或正規化查詢參數，不能只靠這個結果判定是哪一層出問題。

瀏覽器快取：免費、威力大，但受使用者端影響

瀏覽器快取是最底層的那一張。當訪客第一次打開你的網站，瀏覽器會把 CSS、JavaScript、圖片、字體這些靜態資源存到自己本機的硬碟裡。第二次造訪的時候，它就不重新下載這些檔案，直接用本機的那一份。這對回訪者來說是巨大的速度紅利，因為這些檔案通常佔了一個頁面整體傳輸量的大宗。

瀏覽器快取存在訪客的裝置上，但站方仍能透過 HTTP 回應標頭（Cache-Control、Expires、ETag）定義快取政策。瀏覽器設定、重新整理方式與中介快取仍會影響實際行為，因此改版時不能只依賴到期時間。

實務上可靠的做法，是透過建置流程或網站機制給靜態檔案加上內容版本（例如 style.a3f9b2.css）。檔案內容一改，網址就跟著變，瀏覽器會取得新版本，不必等待舊快取到期。

CDN 快取：把抄本推到離訪客最近的地方

CDN（Content Delivery Network）的快取邏輯跟頁面快取很像，差別在於它把那份抄本存到全世界各地的邊緣節點上。訪客在東京，就由東京的節點回應他；訪客在聖保羅，就由南美的節點回應。這對跨國流量來說是決定性的速度差，因為光速就是那麼快，資料中心離訪客越遠，延遲就越高。以 Cloudflare 為例，它的邊緣節點遍佈全球三百多個城市，這是單一主機再怎麼加速也追不上的物理限制。

想搞懂 CDN 跟快取外掛怎麼搭配、誰先誰後，可以參考我們的 CDN 網站加速完整解析。CDN 快取跟頁面快取常常會重疊，這也是多層快取衝突最常見的來源之一，後面我會專門講怎麼排查這類問題，不讓你陷入「清了又清還是舊的」鬼打牆。

頁面快取：WordPress 站長最常接觸的那一層

頁面快取就是快取外掛（像 WP Rocket、WP Fastest Cache、W3 Total Cache）最主要在做的事。它把 PHP 組好的完整 HTML 存成一份靜態檔案，放在伺服器的硬碟或記憶體裡。下一個訪客來的時候，伺服器直接吐這份檔案，連 PHP 和資料庫都不用啟動。

頁面快取能跳過多數 PHP 與資料庫運算，通常可明顯降低伺服器回應時間與尖峰負載。不過改善幅度取決於原始程式、主機、快取命中率與測試地點，不能用固定的毫秒數或倍數預估。對動態 WordPress 站而言，設定一套與主機架構相容的頁面快取，通常是值得優先評估的效能措施。

物件快取與 Opcode 快取：你看不到但分數有感

持久物件快取可把 WordPress 中可重複使用的物件與資料存進 Redis 或 Memcached，降低部分重複查詢與運算。它對動態頁面或後台可能有幫助，但改善幅度取決於外掛、資料存取模式與命中率，設定上也通常需要主機層級支援。

判斷是否需要物件快取，應用 Query Monitor、APM 或主機監控比較啟用前後的資料庫時間、後端回應與快取命中率；WordPress「網站健康狀態」不會提供每頁完整的查詢次數分析，也沒有通用的查詢數門檻。先確認主機是否提供 Redis 或 Memcached，再於測試環境啟用相容的橋接外掛，觀察成效與資料一致性。

Opcode 快取則是更底層的東西，存的是 PHP 程式碼編譯成的字節碼。PHP 每次執行都要把原始碼編譯成字節碼才能跑，Opcode 快取把這個編譯結果存起來，省掉重複編譯的時間。從 PHP 7 之後 OPcache 已經內建，大部分正規主機都會預設開啟，你通常不需要自己管它。知道有這一層存在就好，這樣你才理解為什麼有些主機換了之後速度差很多，不全然是快取外掛的功勞。

「清除快取」被當萬靈丹，但它其實是症狀不是解藥

你在網路上一定看過這種回答：「網站怪怪的？先清除快取試試看。」這四個字已經變成客服跟技術支援的口頭禪，但很少有人真的解釋為什麼。我得老實說，多數時候清除快取之所以有效，是因為你的快取設定本身有問題，讓舊版本被留得太久。如果你每次改內容都要手動清快取才看得到更新，那表示你的自動失效機制沒有設好。

先釐清「清除快取」到底清的是哪一層。一般人講的清除快取，通常有兩種情境。

第一種是訪客端：清除自己瀏覽器裡的快取。Chrome 的官方做法是從設定裡進入「清除瀏覽資料」（見 Google 的說明），可以選擇要清哪些時間範圍、哪些類型的資料。這對解決「我自己看不到改動」的問題通常立刻見效，因為瓶頸就卡在訪客端的瀏覽器快取那一層。

第二種是站長端：清除伺服器上的頁面快取、物件快取、CDN 快取。這要透過你的快取外掛後台、CDN 服務的 purge 功能、或主機的控制台來做。你改了文章內容、調了版型、更新了商品價格之後，理論上對應的頁面快取應該要自動失效，讓下一次請求重新組裝一份新的 HTML。

自動失效才是正解，手動清除只是救急

一個設定良好的快取系統，應該在你發佈文章、更新商品、改了選單的時候，自動把相關頁面的快取清掉，根本不需要你手動介入。WP Rocket 這類成熟的外掛都內建這個機制：你一發佈新文章，首頁、分類頁、相關頁面的快取就會被自動清除。問題通常出在你用了某些非標準的方式更新內容（例如直接改資料庫、用第三方外掛批次改商品），這時候自動失效的觸發點就漏掉了。

所以與其把「清除快取」當成例行公事，不如把目標放在「讓快取該失效的時候自動失效」。具體做法後面的排除清單那段會講。

快取預熱：別讓第一個訪客當白老鼠

快取被清除後，每個尚未建立快取的 key 或節點，都可能由第一個請求重新產生 HTML；不是所有「第一波」訪客都一定變慢。若在流量尖峰前清掉全站快取，仍可能同時增加來源站負載，因此要控制清除範圍與時機。

這就是「快取預熱」（cache preloading）要解決的問題。它的邏輯是：在你需要快取之前，先用程式或外掛主動去把每一個頁面都跑過一遍，讓伺服器提前把 HTML 抄本準備好。等真實訪客進來的時候，每一頁都已經是命中快取的狀態。WP Rocket 有內建預熱功能，會在你清除快取之後自動開始預先產生重要頁面的快取版本。如果你的站流量大、或是有固定的發文時間表，這個功能很值得打開。

預熱也不是越多越好。如果你的站有上萬個頁面，一次預熱全部會把伺服器資源吃光，反而讓真實訪客的請求被卡住。實務上的做法是只預熱重要的頁面：首頁、分類頁、流量最高的那幾篇文章。長尾頁面就讓它們自然被第一個訪客觸發就好，反正長尾頁的流量本來就稀疏，慢一次的影響有限。

動態內容被快取住的災難：一個最常見的坑

前面那個甜點電商示意情境值得拆開看，因為這是快取設定最容易出事的地方。

假設站長為了追求速度分數，把幾乎所有頁面都設成全頁快取，包括含即時庫存狀態的商品列表頁。一旦這個頁面被存成靜態 HTML，而庫存更新又沒有觸發正確失效，訪客就可能看到過期狀態。

結果就是：商品明明已經賣完了，列表頁上還顯示「有貨」，客人點進去下單，結帳的時候才跳出「庫存不足」的錯誤。客訴、退款、負評跟著來。最慘的是，站長根本不知道問題出在哪，因為他自己測試的時候看的是最新版本（他登入了後台，快取外掛會跳過登入者的快取），所以他從來沒看過那個顯示錯誤庫存的版本。

這個案例帶來的教訓很明確：快取最大的風險不是存太少，而是存了不該存的東西。任何會即時變動、會因使用者身分不同而不同的內容，都不該被頁面快取帶住。這聽起來是常識，但當你急著衝分數、看到快取外掛的勾選項目一排排擺在面前，很容易就把「快取全部頁面」這種選項打勾，沒意識到裡面藏著會爆炸的動態內容。

實務上，我一直強調，速度優化不能只看分數。如果你的網站跑 WooCommerce 或任何會員系統，建議你同時回頭檢視 WooCommerce 的會員與電商流程，把快取排除設定一次搞對。

哪些頁面通常不該共用快取？排除清單這樣開

下面整理的是常見的頁面類型。設定快取外掛時，不要直接複製路徑就結束，而要確認網站實際使用的端點、Cookie、登入狀態與 cache key。個人化內容通常應排除共用頁面快取，或交由具備正確變體規則的架構處理。

• 購物車頁面（/cart 或 /checkout/cart）：購物車內容每個使用者都不一樣，快取會讓 A 看到B 的購物車。
• 結帳頁面（/checkout）：牽涉到金流、訂單建立、個人資料，被快取等於訂單錯亂。
• 會員中心（/my-account 以及下面的所有端點：訂單、下載、地址、付款方式）：全部是個人化資料。
• 登入後的使用者頁面：登入者看到的版面（例如導覽列會顯示使用者名稱、會員專屬選單）跟訪客不同，快取會讓登入者看到訪客版。
• 搜尋結果頁（/?s= 或 /search/）：若 cache key 沒有包含搜尋參數，可能把錯誤結果送給其他人。搜尋頁也可能因大量參數造成快取基數膨脹，因此多數中小網站會直接排除；若要快取，必須正確區分參數並設定較短 TTL。
• 含 AJAX 動態更新的區塊：例如商品列表頁的「庫存狀態」、即時報價、購物車數量小工具。這些要嘛整頁不快取，要嘛用 AJAX 動態載入這一小塊、頁面其他部分照常快取。
• 帶有查詢字串的個人化網址：例如 utm 追蹤碼可以快取（內容不變），但帶有 session id、使用者特定參數的網址不行。

這份清單不是死規矩，而是思考框架。判斷的原則只有一條：這個頁面的內容會不會因為「誰在看」、「什麼時候看」而不同？如果會，就該排除。如果不會（例如一篇寫好就很少動的文章），就放心快取。

實務上 WP Rocket 跟多數成熟的快取外掛都會自動排除 /cart、/checkout、/my-account 這些 WooCommerce 標準路徑。但你自己加的功能頁、客製的會員外掛、第三方預約系統產生的頁面，外掛不見得認得，這些就要你手動加進排除清單。實務上，我會建議，每次裝新外掛的時候，順手檢查它產生的頁面有沒有被快取外掛正確排除。

快取救不了的四個速度瓶頸

我得提醒一個容易被漏掉的事實：快取很強，但它不是萬能。有一類速度問題，你再怎麼調快取都解決不了，因為瓶頸根本不在快取這一層。當你發現裝了快取分數還是上不去，先懷疑接下來講的這四個地方。

第一個瓶頸：圖片太大

圖片常是頁面傳輸量的重要來源。一張沒壓縮過的手機直拍照片可能有數 MB，若它又是首屏主圖，就可能拖慢 LCP。快取無法讓檔案本身變小；仍要依顯示尺寸輸出合適解析度、壓縮檔案、選用 WebP 等支援格式，並只對非首屏圖片使用適當的延遲載入。關於這塊，我們有完整的 圖片壓縮工具實測 跟 Lazy Loading 延遲載入指南 可以參考。

第二個瓶頸：主機太慢

快取外掛只能在請求進來之後加速回應，但如果你的主機本身 CPU 慢、記憶體少、硬碟是老舊的機械碟，PHP 啟動的那一瞬間就已經慢半拍了。快取命中率再高，第一次請求、快取過期後的第一次回應，還是得靠主機硬體撐。挑一台好的 WordPress 主機，是速度優化的地基。我們實測過幾家主流主機，值得你單獨花時間研究。

第三個瓶頸：JavaScript 與 CSS 過載

一個頁面載入了十幾個外掛各自的 JavaScript，每一段都在搶主執行緒，畫面就會卡。INP 這個指標量的就是使用者點了按鈕到畫面有反應的時間，它跟快取關係不大，跟你的前端程式碼肥胖程度關係很大。你得做的是精簡外掛、合併壓縮腳本、把不急用的 JavaScript 延後載入。這部分如果不知道從哪裡下手，先去補一下網頁速度優化的基礎觀念會有頭緒。

第四個瓶頸：資料庫查詢失控

有些頁面天生就不能快取（例如會員中心、搜尋結果、報表頁），這時候它的速度就完全取決於資料庫查詢有多快。如果某個外掛寫了一個沒有加索引的複雜查詢，或是迴圈裡面又包查詢（所謂的 N+1 查詢問題），那一個頁面可能跑出上千次資料庫查詢，再快的主機也扛不住。這種問題要從程式碼或外掛層面解決，快取幫不上忙。

如果你的網站已經慢到一個誇張的程度，那很可能不是單一原因，建議照著 網站速度診斷流程 一步一步抓瓶頸，別無腦裝快取外掛。

WordPress 快取外掛：免費跟付費的真正差別在哪

挑外掛時，免費或付費不是第一個判斷。先確認主機是否已有頁面快取、網站是否含會員或電商流程、團隊能否維護規則，再比較外掛整合範圍與支援成本。

免費的 WP Fastest Cache 就是個很實在的選擇，它把頁面快取的基本功做得簡單清楚，設定介面對新手友善，勾一勾就能啟用，不需要懂太多技術。如果你的站流量普通、內容以文章為主、沒有複雜的會員或電商流程，免費外掛就能讓你拿到不錯的分數。

WP Rocket 以付費方式整合頁面快取、部分靜態檔案優化、延遲載入與資料庫工具。預設值不可能適合所有主題、外掛與主機，啟用壓縮、延後載入或移除未使用 CSS 等功能後仍要逐頁測試。費用以官方當期定價為準。

到底該選哪個，應先看主機是否已有伺服器端快取、網站是否含會員或電商流程，以及團隊能否維護排除與失效規則。免費或付費不直接等於效果好壞；一次只保留一套主要頁面快取，並在測試環境驗證相容性。我們整理的 WordPress 快取外掛完整比較 可用來對照需求，WP Rocket 的具體設定流程則可參考 WP Rocket 設定教學。

順帶一提，快取外掛不是裝越多越好。同時裝兩個頁面快取外掛，它們會互相打架，規則衝突的結果常常是快取根本沒生效，甚至讓網站掛掉。挑一個用就好，這也是我們反覆強調給站長的原則。

六步把快取設定到位

講了這麼多觀念，最後給你一套可以照著做的行動清單。不管你用的是哪一個快取外掛，這六步的邏輯都適用。

1. 確認主機環境：先確認你的主機有沒有支援 Redis 或 Memcached（物件快取）、有沒有開啟 OPcache。這些是地基，地基沒打好，上面裝什麼外掛都會打折扣。如果不確定，直接問主機商。
2. 選一套相容的頁面快取並啟用：先確認主機是否已有內建快取，再依網站功能與維護需求選擇外掛。一次只保留一套主要頁面快取，啟用前後都要記錄同一組測試條件。
3. 開好排除清單：把前面那份「永遠不該被快取」的頁面路徑（購物車、結帳、會員中心、搜尋頁、含動態內容的頁面）加進外掛的排除規則。WooCommerce 標準路徑多數外掛會自動排除，但客製頁面要自己加。
4. 設定靜態資源的瀏覽器快取與壓縮：啟用 Gzip 或 Brotli 壓縮；只有具備版本化檔名或內容 hash 的靜態資源，才適合設定很長的快取期限，否則更新後容易留下舊檔。
5. 驗證自動失效機制：發佈一篇測試文章，確認首頁跟分類頁的快取有自動更新。如果沒有，回去檢查外掛的自動清除設定，或看看你是不是用了非標準的更新方式。
6. 用無痕視窗做最終驗證：登出網站、開無痕視窗、用訪客身分瀏覽一遍。重點檢查購物車數量、會員選單、商品庫存這些動態內容有沒有顯示錯誤。這一步是抓那個烘焙甜點電商災難的關鍵，你自己登入看的永遠是對的版本。記得用手機實機再測一次，因為桌機跟手機的快取行為有時會走不同的規則，特別是你啟用了行動版專屬快取的時候。

做完這六步，你的快取設定就具備了基本防護。剩下的是持續觀察：每隔一段時間用測速工具跑一次，留意分數有沒有突然下滑，通常那代表某個新裝的外掛或某次改動打破了原本的快取規則。

快取這件事，說難不難，說簡單也真的不簡單。它考驗的不是你會不會勾選項，而是你懂不懂得把「速度」跟「正確性」放在同一個天平上衡量。一個只追求分數的站長，會把所有頁面都快取起來、拿到漂亮的測速成績，然後在客訴信裡發現自己的庫存數字從上週就錯了。一個真正懂快取的人，會先想清楚什麼該存、什麼不該存，再追求速度。

把快取當成一套需要設計的系統，而不是一個裝了就好的開關，網站才有機會兼顧速度與正確性。現在就打開快取設定，核對排除規則、失效機制與訪客端實際結果；這比只看測速分數更能抓到真正的風險。