如果把 WordPress 性能優化拆成三層:

  • 源站層:主機 / PHP / 數據庫 / 緩存插件 —— 決定 TTFB 和後端壓力
  • 資源層:圖片優化 —— 決定下載體積與首屏大圖速度
  • 交付層:CDN —— 決定資源離訪問者更近、命中更穩、源站更輕鬆

本文講 CDN 加速

  • 知道 CDN 能解決什麼、不能解決什麼
  • 選得出適合自己的 CDN 形態與服務商(並理解免費版/入門版邊界)
  • 按低風險順序上線,不把站點搞崩、不把電商/會員緩存出事故
  • 上線後能驗證“確實生效”,並能排查“為什麼沒更新/為什麼變慢/為什麼串內容”

1. 先把概念説清楚:CDN 解決什麼,不解決什麼

1.1 CDN 主要解決 3 件事

1.1.1 靜態資源更快交付
圖片 / CSS / JS / 字體 / 圖標等靜態資源更接近訪問者,下載更快,頁面渲染更穩。
對 WordPress 來説,尤其是主題與插件資源(wp-content/themes/wp-content/plugins/)以及媒體庫圖片(wp-content/uploads/)通常是“體積大户”。

1.1.2 減輕源站壓力
命中邊緣緩存後,請求不再頻繁回源,源站的帶寬、併發連接、磁盤 IO、CPU 波動都會更輕。
這對“活動頁、文章爆款、產品頁被大量訪問”這種波峯場景尤其明顯。

1.1.3 提升穩定性(更抗波動)
流量尖峯時,邊緣節點會吸收大量重複請求,源站更不容易被打爆。
你會看到“訪問更平滑”:就算源站瞬間壓力上升,邊緣緩存仍能持續輸出。


1.2 CDN 不會自動解決的 3 類問題

1.2.1 源站本身慢
數據庫慢、插件邏輯慢、PHP 計算慢 —— 這些屬於源站層問題。
CDN 能把靜態資源變快,但你如果連首頁 HTML 都生成得很慢,用户還是會覺得“打開就慢”。這時候優先回到:主機/緩存插件/數據庫優化。

1.2.2 圖片本身太大
CDN 不能把 3MB 的大圖“魔法變小”。
你要先做圖片優化:尺寸策略(別下載超大圖)、壓縮、WebP/AVIF、懶加載策略等。

1.2..3 第三方腳本慢
廣告、統計、客服、社媒組件等來自第三方域名。
CDN 通常無法幫它們“更快”,你只能通過減少/延後加載、替換供應商、或做腳本策略優化來處理。

建議

先把源站層和資源層做對,再做 CDN,效果會更明顯,問題也更少。

2. 30 秒選型:你需要哪一種 CDN 形態?

對 WordPress 來説,主流分兩類。你先選“形態”,再選“服務商”,思路會非常清晰。

2.1 一體化“反向代理型”(更省心,適合多數站點)

**特點:**它不僅是 CDN,還把 DNS / SSL / 基礎安全防護(如 DDoS/WAF) 一起打包。你接入後,它站在你的網站前面做代理。

你會得到什麼:

  • HTTPS 證書與 TLS 管理更簡單
  • 統一的安全防護入口(基礎 DDoS、訪問控制、WAF 等)
  • 邊緣緩存與規則引擎(可做更細的緩存策略、繞過策略)
  • “可擴展空間更大”:以後想加安全、限速、Bot 防護,通常都在同一套體系裏

**代表:**Cloudflare / 騰訊雲國際 EdgeOne / 阿里雲國際 ESA

如果你希望:

  • 你希望 HTTPS + CDN + 基礎安全 一次做完
  • 你願意把域名解析/代理層統一交給一個平台管理
  • 你更看重“整體體驗與後續擴展”,不想把 DNS、證書、CDN、安全分成多套

2.2 純“靜態 Pull CDN”(低風險起步,主要加速圖片/CSS/JS)

**特點:**你只把靜態資源放到 CDN 邊緣緩存;HTML 頁面仍由源站(以及源站緩存插件)負責。

你會得到什麼:

  • 很低的業務風險:不碰 HTML 的話,基本不會出現“串內容/串購物車”
  • 成本模型更直觀:常見是按流量/請求/區域計費
  • 結構更純粹:更像“靜態資源分發服務”

**代表:**bunny.net(按量計費模型清晰)

如果你希望:

  • 你想先做“最穩的一步”——靜態資源加速
  • 你想快速拿到收益,再決定是否上代理型/全站緩存
  • 你希望成本更接近“用多少付多少”

3. 怎麼做

  • 第一層:一體化代理型(首選):Cloudflare / EdgeOne / ESA
  • 第二層:靜態 Pull CDN(穩妥起步):bunny.net / Cloudways CDN 等

4. 推薦的服務商

4.1 Cloudflare:反向代理一體化(免費起步、生態成熟)

它是什麼
你把域名接入後,它作為代理站在網站前面,提供 CDN、證書、基礎防護與緩存規則能力。

適合誰

  • 想省心:HTTPS + CDN + 基礎安全一條龍
  • 想要成熟生態:後續要加 WAF、限速、邊緣規則等,路徑很順

風險點

  • 更新不生效:上線 CDN 後緩存鏈路變長(瀏覽器緩存 + CDN 緩存 + 源站緩存),需要“版本策略”讓更新可控(後面有排查樹)
  • 緩存 HTML 要謹慎:如果緩存 HTML,電商/會員/個性化頁面必須嚴格繞過,否則容易出現嚴重事故(後面有場景清單)

説明

  • 定位:反向代理一體化(SSL + CDN + 基礎防護)
  • 適合:省心上線、後續擴展空間大
  • 核心價值:統一證書/安全/緩存入口
  • 風險:更新靠版本策略;HTML 緩存需嚴格繞過

4.2 騰訊雲國際 EdgeOne:反向代理一體化

它是什麼
形態同樣是“加速 + 安全 + 證書”的一體化平台,適合把站點放到統一代理層管理。

  • 和Cloudflare一樣擁有免費版,但通常會有 配額/功能上限(規則數量、日誌任務數量等),但不需要修改DNS,只需要cname接入即可,商業網站不推薦使用免費版
  • 同時免費計劃往往意味着 SLA 不保證
    能用,但不要當作“商用 SLA 套餐”。
  • 如果你希望在中國大陸自動切換中國大陸線路,通常需要先完成中國 ICP 備案;未備案時只能走國際線路。

説明:

  • 定位:反向代理一體化(加速 + 安全 + 證書)
  • 適合:希望一體化接入、並考慮中國大陸節點能力
  • 免費:存在免費計劃/免費版,但配額有限且 SLA 通常不保證
  • 風險:規則/日誌/子域名配額要提前規劃;HTML 緩存同樣要謹慎

4.3 阿里雲國際 ESA:反向代理一體化

  • 和Cloudflare一樣擁有免費版,但通常會有 配額/功能上限(規則數量、日誌任務數量等),但不需要修改DNS,只需要cname接入即可,商業網站不推薦使用免費版
  • 註冊國際站賬號即可使用
  • 進入 ESA 控制枱添加站點並選擇免費的 Entrance 套餐接入
  • 如果你希望在中國大陸自動切換中國大陸線路,通常需要先完成 ICP 備案;未備案時只能走國際線路。
  • 免費更適合開發/測試/評估,通常不等同於商用 SLA 套餐
  • 免費套餐往往會有限速/支持方式限制(例SLA 等)

關於中國大陸線路:

  • 想啓用中國大陸節點,通常需要滿足備案與區域條件
  • 免費 Entrance 默認走國際線路,希望走中國大陸線路必須完成中國ICP備案要求

説明:

  • 定位:反向代理一體化(站點加速 + 安全)
  • 免費:國際站賬號可用 Entrance 免費接入;默認不含中國大陸加速
  • 適合:評估/測試與輕量使用;或後續升級套餐
  • 風險:免費邊界要看清(SLA/限速/支持方式);區域與備案要提前規劃

4.4 bunny.net:靜態 Pull CDN(低風險起步,按量計費清晰)

如果你希望“先把最穩的收益拿到”,bunny 這種 Pull CDN 很適合:
它更像“資源分發服務”:你把靜態資源交給它分發,費用通常跟流量/請求/區域有關,模型清晰、可控。

適合:

  • 先做 圖片 / CSS / JS / 字體 的靜態加速
  • 你想先拿到“低風險且穩定的收益”,不急着把整站交給代理型平台(DNS/SSL/WAF 一體化)
  • 你希望成本模型更接近“用多少付多少”,而不是一開始就進入更復雜的套餐體系

風險點

靜態資源“更新不生效”幾乎都不是 CDN 的 bug,而是緩存系統的正常表現:
當你在後台更新了 CSS/JS/圖片,但資源 URL 沒變(同一個地址/文件名/路徑),CDN 和瀏覽器都會合理地繼續命中舊緩存,於是你就看到“怎麼沒更新”。

一個明確、可執行的原則:

版本號優先,Purge 兜底。

為什麼這樣最穩:

  • 版本號/文件名變化 → URL 變化 → CDN 當作新資源緩存 → 新版本幾乎立刻生效
  • **Purge(清緩存)**需要你主動觸發,容易範圍不準、節點傳播有延遲;頻繁 Purge 還會導致命中率下降、回源增加、波動變大

容易看懂的例子:

  • style.css 內容改了,但 URL 還是 style.css → CDN 繼續給舊緩存(合理)
  • URL 變成 style.css?ver=20260103style.abc123.css → CDN 認為是新資源 → 新版本立刻生效

bunny 作為“第一步 CDN”的最佳實踐

  1. 先只覆蓋靜態資源(圖片/CSS/JS/字體),不要一上來就緩存 HTML
    • 好處:幾乎不會出現“用户看到別人的內容/購物車串號”這種嚴重事故
    • 你也更容易驗證收益:靜態資源更快、源站更輕
  2. 把更新策略設計好
    • CSS/JS:儘量用版本號/文件名變更
    • 圖片:儘量避免長期“同名覆蓋”,更推薦新文件名/路徑變化(尤其是首頁 banner、活動圖)
  3. 上線後用驗證清單確認命中
    • 靜態資源是否來自 CDN
    • 命中率是否逐步上升、源站帶寬/請求是否更平穩(後面有驗證清單)

注意

如果你的業務涉及中國大陸,或者你希望在中國大陸能更快的訪問你的網站。

阿里雲中國和騰訊雲中國均值得你選選擇,如果你的域名已經在中國大陸進行ICP備案,使用EdgeOne或ESA時,中國大陸訪問時會自動切換中國大陸線路

使用中國大陸節點”通常涉及 ICP 備案

參考

網站跨境訪問體驗優化”可能是另一種單獨能力,通常不等同於“免費就有中國大陸節點”

5. 上線路線圖:按 3 個階段推進(從穩到強)

CDN 上線最容易“搞亂”的原因,是一上來想把所有能力都開滿。

階段 1:只做靜態資源 CDN(強烈建議先做)

目標:圖片/CSS/JS/字體先走 CDN;HTML 不在 CDN 緩存(或暫時不動)。

為什麼先做這個最穩

  • 風險最低:靜態資源緩存錯了,最多是“樣式/圖片不更新”,可控
  • 不會觸碰登錄態、電商流程、賬户信息正確性
  • 你能清晰看見收益:靜態資源下載更快,源站更平穩

這個階段常見問題(後面會給排查樹)

  • 混合內容(HTTPS 頁面加載 HTTP 資源)
  • 靜態資源更新不生效(URL 沒變)

階段 2:刷新策略(版本號優先,Purge/失效兜底)

這是“CDN 做得專業不專業”的分水嶺。

一條硬規則:

能用版本號/文件名變化解決的更新,不要依賴 Purge。

為什麼緩存鏈路變長後會變玄學:

  • 瀏覽器緩存:你本地可能緩存了舊 CSS/JS
  • CDN 緩存:邊緣節點可能緩存了舊資源
  • 源站緩存:緩存插件/服務器緩存可能還在輸出舊內容

如果你沒有版本策略,發佈就會變成:
“改了東西 → 刷新 → 不行 → 再清緩存 → 還不行 → 再清另一層緩存”
這就是很多人對 CDN 的最大痛點。


階段 3(進階):是否緩存 HTML(收益高,但風險最高)

HTML 緩存(全站緩存/邊緣緩存)能顯著降低 TTFB,但 WordPress 場景裏也是事故高發區。

不確定就不要緩存 HTML。先靜態 CDN + 源站緩存插件。

如果要緩存 HTML,兩條原則:

  1. 只從“訪客態”開始:只緩存未登錄訪客頁面
  2. 先寫繞過清單:正確性優先,再談命中率

6. 場景規則清單:不同站點類型怎麼做才不出事故

6.1 內容站 / 博客(文章為主、訪客多)

推薦

  • 靜態資源:全緩存
  • HTML:可考慮緩存“未登錄訪客頁面”

通常需要繞過

  • 後台與登錄:/wp-admin/*/wp-login.php
  • 預覽/草稿(preview)
  • 搜索結果頁(參數變化大,先不緩存最省事)
  • 表單提交/評論提交的 POST 請求

緩存鍵(Cache Key)最少要區分

  • 是否登錄(cookie 維度)
  • 語言(多語言站)

6.2 企業站 / 營銷落地頁(表單、活動多)

推薦

  • 靜態資源:全緩存
  • HTML:公開落地頁可緩存(訪客態),但要謹慎處理表單結果頁

最容易踩的坑:追蹤參數導致緩存碎裂
落地頁常見 utm_* 參數:

  • 全部參與緩存鍵 → 緩存被切碎,命中率差
  • 全部忽略 → 少數依賴參數渲染的頁面可能不符合預期

6.3 會員站 / 課程站 / 社區(登錄態佔比高)

結論:HTML 緩存要非常謹慎。
穩妥做法通常是:靜態 CDN + 源站緩存/對象緩存;HTML 只緩存訪客態。

必須繞過

  • 登錄/註冊/找回密碼
  • 賬户中心、訂單/訂閲、個人資料
  • 任何“用户態強相關”的頁面與接口

6.4 電商站(WooCommerce)

最重要的繞過清單

  • 購物車、結算、賬户頁
  • 訂單確認、支付回調相關頁面
  • 登錄/註冊、優惠券/積分等用户態相關入口

為什麼電商更容易出事故

  • 一旦用户有購物車、會話、登錄態,頁面就高度個性化
  • HTML 緩存如果沒繞過/沒區分狀態,最典型後果就是:購物車錯亂、賬户串號、價格顯示異常
    正確性優先,不要為了命中率犧牲正確性。

6.5 多語言 / 多幣種站點

推薦

  • 靜態資源:全緩存
  • HTML:可緩存訪客態,但緩存鍵必須明確區分語言/幣種變體

Cache Key 必須考慮

  • 語言(路徑 /en/ /zh/ 或子域 en.
  • 是否登錄(cookie)
  • 幣種/税率(若影響展示)

7. 風險提示

風險 1:緩存錯內容(最嚴重)

  • 靜態資源緩存錯:多是樣式/圖片舊
  • HTML 緩存錯:可能串內容、串購物車、串賬户 —— 這是嚴重事故

風險 2:更新不生效(最常見)

緩存鏈路變長後,“改了沒生效”會更常見:

  • 版本號/文件名變更優先
  • Purge/失效兜底
  • 發佈流程要可復現(知道每次發佈改了哪些 URL)

風險 3:免費版/入門版的承諾邊界

  • 免費方案常見特點:配額有限、部分能力不含、SLA/支持方式不等同正式商用

風險 4:中國大陸相關能力容易被誤解

  • ESA :希望走中國大陸線路必須進行中國ICP備案
  • EdgeOne :希望走中國大陸線路必須進行中國ICP備案

8 驗證清單:上線後怎麼確認“真的生效”

8.1 靜態資源是否真的走了 CDN?

  • 圖片/CSS/JS 是否來自 CDN 域名/邊緣節點
  • 是否能看到明顯的緩存命中跡象(不同平台的標識不同)

8.2 源站壓力是否下降?

  • 源站帶寬是否更平穩
  • 源站請求數/連接數是否下降(特別是重複資源的請求)

8.3 更新是否可控?

  • 改一次 CSS/JS 或替換一張圖片
  • 新版本是否能通過“版本號變化/文件名變化”快速生效
  • 如果只能靠 Purge 才能更新,説明版本策略還沒做好(優先補策略,不要把 Purge 當日常)

8.4 動態關鍵頁是否正確?

(電商/會員站必做)

  • 登錄/退出後的頁面內容是否正確
  • 購物車/結算/賬户相關頁面是否始終正確
  • 有沒有出現“不同用户看到相同用户態內容”的異常(高危)

8.5 錯誤率是否上升?

  • 回源超時、5xx、間歇性打不開
  • 這些通常意味着:源站承載不足、規則有誤、限速觸發、或回源鏈路問題

9. 更新不生效排查樹(把“玄學”變成步驟)

先判斷你遇到的是哪一類問題:

9.1 靜態資源沒更新(CSS/JS/圖片還是舊的)

情況 A:只有你自己看到舊,隱身/換設備是新的
優先懷疑:瀏覽器緩存

  • 解決方向:版本號/文件名變化發佈新資源

情況 B:所有人都看到舊(隱身/不同設備也舊)
優先懷疑:CDN 仍命中舊緩存

  • 99% 原因:資源 URL 沒變
  • 優先解:版本策略
  • 兜底:Purge(臨時手段)

情況 C:圖片同名覆蓋後一直顯示舊圖
這是瀏覽器緩存 + CDN 緩存疊加的經典問題

  • 實用建議:儘量避免長期“同名覆蓋”,用新文件名/路徑或版本號

9.2 HTML 沒更新(頁面內容/模塊還是舊的)

情況 A:後台/登錄後是新的,訪客看到舊的
優先懷疑:訪客態 HTML 被緩存住了

  • 先確認:這類頁面是否應該緩存 HTML
  • 如果應該緩存:需要可控刷新策略,否則發佈不可控

情況 B:只有部分地區/部分網絡反饋舊內容
優先懷疑:不同邊緣節點緩存狀態不同

  • 解決方向:用版本/刷新策略收斂差異;必要時做更明確的失效

情況 C:登錄用户/購物車出現異常
高危信號:可能緩存錯內容了

  • 立即檢查是否緩存了用户態頁面(購物車/結算/賬户等)
  • 檢查 Cache Key 是否把“用户態 cookie/語言/幣種”等關鍵變體忽略了

10. 推薦

Cloudflare

  • 反向代理一體化
  • 適合:省心起步
  • 重點:版本策略解決更新;HTML 緩存從訪客態做
  • 風險:動態頁面必須繞過

騰訊雲國際 EdgeOne

  • 反向代理一體化
  • 適合:考慮中國大陸節點能力與一體化接入
  • 免費:有免費計劃/免費版,但配額與承諾邊界要看清
  • 風險:規則/日誌/子域名配額要規劃;HTML 緩存謹慎

阿里雲國際 ESA

  • 反向代理一體化
  • 免費:國際站賬號可用 Entrance 免費接入
  • 風險:免費邊界(SLA/支持/限速)與區域/備案條件要提前確認
  • 適合:評估/測試與輕量接入;或後續升級套餐,或考慮中國大陸節點能力與一體化接入

bunny.net

  • 靜態 Pull CDN
  • 適合:先做低風險靜態加速
  • 重點:版本號優先,Purge 兜底;避免同名覆蓋
  • 風險:更新策略沒做好會頻繁遇到“舊資源”

11. 行動建議

  1. 先選形態:反向代理一體化(Cloudflare/EdgeOne/ESA)還是靜態 Pull CDN(bunny)
  2. 按階段上線:先靜態 → 再版本策略 → 最後再考慮 HTML 緩存
  3. 上線後按驗證清單檢查:命中/回源/更新/動態繞過/錯誤率
  4. 需要更快:回到“緩存插件”“圖片優化”,把源站層與資源層再壓一輪

WordPress CDN 常見問題

1. 用了 CDN 為什麼還是慢?

最常見原因不是 CDN 沒用,而是瓶頸不在“交付層”。

你可以按這個順序判斷:

  • TTFB 仍然很高:説明源站生成 HTML 慢(數據庫/插件/緩存插件配置/主機性能)→ 回到源站層優化
  • 首屏大圖很慢:説明圖片體積、尺寸或格式不對 → 先做圖片優化(壓縮、WebP/AVIF、尺寸策略)
  • 第三方腳本拖慢:廣告/統計/客服腳本常見 → CDN 通常幫不上,需要減少或延後加載
  • 只有某些地區慢:可能是節點覆蓋、回源線路、或緩存沒命中(命中率低)→ 看命中率與回源情況

CDN 負責把“已優化好的資源”送得更快;源站慢、圖片大、腳本慢要分別處理。


2. 為什麼我更新了 CSS/JS/圖片,但用户還是看到舊版本?

這是 CDN 場景最常見的問題,核心原因通常是:資源 URL 沒變,緩存系統會合理繼續命中舊緩存。

最穩的處理原則:

  • 版本號優先:讓資源 URL 變化(例如 style.css?ver=xxxx 或文件名 hash)
  • Purge 兜底:當你還沒建立版本策略時,才用清緩存做臨時手段

如果你經常替換首頁 banner / 活動圖,建議避免“同名覆蓋”,優先用新文件名/新路徑(更可控)。


3. 我需要緩存 HTML 嗎?不緩存會不會就沒有意義?

不一定需要。

對很多站點來説,CDN 的最大價值來自:

  • 靜態資源(圖片/CSS/JS/字體)更快
  • 源站壓力下降與穩定性提升

緩存 HTML 的收益確實可能更大(TTFB 會更低),但風險也最大:電商、會員、個性化內容、多語言/多幣種都容易緩存錯內容。

穩妥路線:

  1. 先做靜態 CDN(低風險高回報)
  2. 把版本策略和驗證清單跑通
  3. 再評估是否緩存 HTML(從“訪客態”開始)

4. 電商站能不能上 CDN?會不會把購物車搞亂?

能上,而且應該上(至少靜態資源),但要避免緩存用户態頁面。

  • 靜態資源可以緩存:圖片、CSS、JS
  • 用户態頁面必須繞過:購物車、結算、賬户相關頁面不要緩存 HTML
  • 只要你不對這些頁面做 HTML 緩存,發生“串購物車/串賬户”的風險就會大幅降低

5. 多語言/多幣種站點怎麼做 CDN 才不會串語言/價格?

核心在於 Cache Key(緩存鍵) 是否正確。

  • 語言(路徑或子域)
  • 幣種(如果影響價格展示)
  • 是否登錄(cookie)
  • 地區/税率(如果頁面會因地區變化)

如果這些維度不進入緩存邏輯,就很容易出現:A 語言用户看到 B 語言內容,或價格不一致。


6. 我該選反向代理一體化(Cloudflare/EdgeOne/ESA)還是靜態 Pull CDN(bunny)?

你可以按“目標”和“風險偏好”選:

  • 想一次搞定 HTTPS + CDN + 基礎安全、後續還能擴展規則/WAF:反向代理一體化
  • 想先做最穩的第一步(靜態資源更快),不想動整站代理:靜態 Pull CDN(例如 bunny)

如果你猶豫,默認建議:先靜態 CDN → 跑通版本策略與驗證清單 → 再決定是否上代理型/HTML 緩存。


7. 免費版能不能直接用在正式網站?

可以用,但要把“免費”當成“起步/評估/輕量使用”,不要把它當成“帶商用 SLA 的正式方案”。

  • 你是否能接受免費方案的配額上限、功能缺失、支持方式差異、以及可能沒有 SLA 承諾
  • 如果不能,就應該把免費當作試用,後續升級到更適合的套餐

8. 我怎麼確認 CDN 真的生效了,而不是心理安慰?

用這三步確認(不需要任何複雜工具):

  1. 看靜態資源是否從 CDN 返回(圖片/CSS/JS 的來源是否變化)
  2. 看命中率與回源是否改善(命中上升、回源下降才算真收益)
  3. 改一次 CSS/圖片驗證更新策略(版本號生效,説明鏈路可控)

如果你做不到第 3 條,後面越優化越容易被“更新不生效”折磨,建議優先補齊版本策略。


9. 啓用中國大陸加速為什麼經常會卡住?

最常見原因是:區域選擇與備案條件不匹配

  • 若你要選擇包含中國大陸的加速區域,通常需要先完成 ICP 備案;未備案只能選不含中國大陸的區域。

10. 我該先裝緩存插件還是先上 CDN?

一般建議順序是:

  1. 源站層:緩存插件/主機基礎先穩定(TTFB 下降、後台壓力下降)
  2. 資源層:圖片優化把體積壓下來
  3. 交付層:CDN 把資源送得更快、更穩

如果你現在只想做一件事、又怕翻車:先上靜態 CDN(階段 1),收益穩定,風險最低。