Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
Cloudflare Workers 教學：邊緣運算加速 WordPress 的完整指南
CloudFlare 的 CDN 服務原理是將網站的檔案內容快取在 Cloudflare 的全球節點當中來實現網站加速，而近期 Cloudflare 提供了另外一項新的功能 —「 Cloudflare Workers」。
今天就要來教大家如何在 CloudFlare 當中實作「Workers」的功能，來加快 WordPress 網站的速度。
Cloudflare Workers 讓你在 Cloudflare 全球邊緣節點上執行 JavaScript，直接從距離訪客最近的伺服器回應請求，把 WordPress 的 TTFB 從數百毫秒壓到 50ms 以下。
如果你正在用 Cloudflare 做 CDN 和 DNS 代管，Workers 是把網站速度推到下一個層級的最直接方式。它不只是快取靜態檔案，而是在邊緣節點上執行你的自訂邏輯：快取動態 HTML、過濾惡意爬蟲、根據訪客國家導向不同頁面，甚至做到 A/B 測試。免費方案每天 10 萬次請求，對大多數個人站長來說完全夠用。
這篇教學會從原理講到實作，涵蓋三種部署方式、WordPress HTML 邊緣快取的完整設定、進階的爬蟲阻擋與安全規則，以及跟其他邊緣運算服務的比較。不管你是剛接觸 Cloudflare 的新手，還是已經在用 WordPress 虛擬主機架站的老手，看完都能動手把 Workers 用起來。
目錄
Cloudflare Workers 是什麼？
Cloudflare Workers 是 Cloudflare 在 2017 年推出的無伺服器邊緣運算平台。它讓你把 JavaScript（或透過 WebAssembly 編譯的 Rust、C++）部署到 Cloudflare 全球 300 多個資料中心。當一個 HTTP 請求經過 Cloudflare 邊緣節點時，Worker 會先攔截這個請求，執行你的自訂邏輯，再決定要從快取直接回應，還是把請求轉發到來源伺服器。
跟傳統 CDN 的靜態快取相比，Workers 最大的差異在於「可程式化」。CDN 只能快取圖片、CSS、JS 這類靜態資源，碰到 WordPress 即時渲染出來的 HTML 頁面就沒轍了。Workers 能在邊緣節點上判斷每個頁面能不能快取、該不該快取，甚至動態修改回應標頭和內容。這就好比你在 Cloudflare 的每個節點都安排了一個會判斷情境的管理員，而不是一台只會複製貼上的影印機。
Workers 的底層使用 Google Chrome 同款 V8 JavaScript 引擎，搭配 V8 Isolate 技術做隔離。這代表冷啟動時間不到 5 毫秒，比傳統 serverless 函式快了好幾個數量級。對於 WordPress 網站速度最佳化來說，Workers 堪稱是除了主機升級之外，投資報酬率最高的加速手段。
邊緣運算 vs 傳統伺服器：為什麼距離很重要
假設你的主機放在美國西岸，一個台灣訪客打開你的網頁，光纖再快也得繞過半個地球。單趟延遲大概 150ms，一個完整的 HTTP 請求（TCP 握手加 TLS 加回應）動輒 500ms 起跳。如果你的伺服器因為 500 Internal Server Error 或 502 Bad Gateway 出問題，訪客看到的就是空白頁面。
邊緣運算把運算資源推到距離使用者最近的節點。台灣的訪客打開網頁時，請求由台北或附近的 Cloudflare 節點處理，延遲降到 10-20ms。如果 Worker 判定快取可用，甚至完全不用回源。這對 WordPress 網站 的 Core Web Vitals 分數有直接且明顯的幫助。
WordPress 站長為什麼需要 Workers
WordPress 的頁面是由 PHP 即時渲染出來的 HTML。每次有人造訪，伺服器都要執行 PHP、查詢資料庫、組裝 HTML，過程很耗資源。傳統做法是用 快取外掛 把渲染好的頁面存在主機上，但快取外掛的快取位置就在主機上，訪客離主機遠的話，延遲問題依然存在。
Workers 能在 Cloudflare 邊緣快取已經渲染好的 HTML，讓全球各地的訪客都從最近的節點取得頁面。它還能自動偵測 WordPress 的更新，不需要手動清除快取。遇到 伺服器暫時無法回應 或 閘道逾時 的情況，Workers 可以提供快取的離線版本，讓訪客至少能看到頁面內容。
Cloudflare Workers 免費方案與付費方案比較
截至 2026 年 5 月，Cloudflare Workers 的計費結構如下（資料來源：Cloudflare 官方定價頁面）。免費方案對個人站長來說相當夠用，每天 10 萬次請求換算下來等於一個月 300 萬次，對日均 5,000 到 8,000 頁面瀏覽量的網站綽綽有餘。真正需要付費方案的場景，通常是日均超過 3 萬 PV 的中大型網站，或者需要 Workers KV 大量讀寫的應用。
| 項目 | 免費方案 | 付費方案（Standard，$5/月起） |
|---|---|---|
| 請求數 | 100,000 次/天 | 1,000 萬次/月（超出每百萬次 $0.30） |
| CPU 時間 | 10ms/次請求 | 預設最長 30 秒，上限 5 分鐘；每月含 3,000 萬 CPU 毫秒 |
| 記憶體 | 128MB | 128MB |
| 腳本大小（壓縮後） | 1MB | 10MB |
| Workers KV 讀取 | 100,000 次/天 | 1,000 萬次/月（超出每百萬次 $0.50） |
| Workers KV 寫入 | 1,000 次/天 | 100 萬次/月（超出每百萬次 $5.00） |
| 靜態資產請求 | 免費且無限 | 免費且無限 |
| 資料傳輸（egress） | 不額外收費 | 不額外收費 |
付費方案最低 $5 美元一個月，包含 Workers、Pages Functions、Workers KV、Hyperdrive 和 Durable Objects 的用量。超出的部分按使用量計費，沒有頻寬費用。如果你正在用 Kinsta 或 A2 Hosting 這類主機，搭配 Workers 免費方案能大幅減少回源次數，等同於幫主機省下大量 PHP 運算資源。
用量估算：你的網站需要哪個方案
| 日均頁面瀏覽量 | 每日 Worker 請求估計 | 建議方案 |
|---|---|---|
| 500 PV | 約 2,000 次 | 免費方案 |
| 2,000 PV | 約 8,000 次 | 免費方案 |
| 10,000 PV | 約 40,000 次 | 免費方案（接近上限） |
| 50,000 PV | 約 200,000 次 | 付費方案 |
| 200,000+ PV | 約 800,000+ 次 | 付費方案 + 用量監控 |
上面的估算基於每個頁面瀏覽觸發約 4 次 Worker 請求。如果你的 Route 設定只讓 Worker 處理 HTML 頁面，請求量還會更低。對於使用 DreamHost、FastComet 或 SiteGround 等主機的站長，Workers 免費方案幾乎一定能滿足需求。
使用 Cloudflare Workers 前的準備工作
在開始設定 Workers 之前，確認三件事。第一，你的網站必須已經透過 Cloudflare 進行 DNS 代管。如果還沒有接入，先看我們之前的 Cloudflare 教學，裡面有從註冊到設定的完整流程。還沒買網域的話，先看看 如何申請註冊網域 和 選擇網域名稱的技巧。
第二，準備好 Cloudflare 帳號的註冊 Email、Global API Key（在 Cloudflare 帳號的 My Profile 頁面下方），以及你要啟用 Workers 的網站的 Zone ID（在 Dashboard 的 Overview 頁面右下方）。如果你是從 Namecheap 買的網域，設定 DNS 代管到 Cloudflare 只需要幾分鐘。之前經歷過 DNS Flag Day 的站長對 DNS 設定應該不陌生，Cloudflare 的 1.1.1.1 DNS 服務 也跟 Workers 屬於同一個生態系。
第三，建議先備份你在 Cloudflare 裡設定的 Page Rules、Transform Rules 和 Firewall Rules。雖然 Workers 不會直接覆蓋這些規則，但如果有衝突（例如 Page Rules 和 Worker 同時嘗試修改快取行為），優先順序會影響最終結果。可以先在 InstaWP 測試環境 或 DemosWP 上建立一個測試站，確認 Workers 設定無誤後再套用到正式站。
Cloudflare Workers 教學：三種部署方式
Workers 有三種主要的部署方式，各有適合的使用情境。第一種是透過 Cloudflare Dashboard 手動建立，操作最直覺，適合不想碰命令列的站長。第二種是用 Wrangler CLI 在本地開發後部署，適合有程式基礎的開發者。第三種是 Cloudflare Pages Functions，適合靜態網站或 Headless WordPress 架構。三種方式的底層技術完全一樣，差別只在開發流程。
方式一：Cloudflare Dashboard 手動建立 Worker
登入 Cloudflare Dashboard 後，在左側選單找到「Workers and Pages」，點擊「Create Application」，選擇「Create Worker」。系統會自動產生一個預設的 Worker 腳本，你可以在 Dashboard 內建的編輯器裡把預設程式碼替換成你需要的邏輯。編輯完成後點「Save and Deploy」。
部署完成後，Worker 還不會對你的網站生效，因為你還沒設定 Route。到「Workers and Pages」裡選擇你剛剛建立的 Worker，點「Triggers」標籤，在「Routes」區塊點「Add Route」。Route 的格式是 你的網域/*，例如 example.com/*，選擇對應的 Zone。儲存後 Worker 就會開始處理所有匹配的請求。
如果你使用的是 Bluehost 主機架設的 WordPress，記得確認 Cloudflare 的 SSL 模式設定為「Full (Strict)」，避免 SSL 驗證失敗。使用 Hostinger 或 SiteGround 主機的站長也一樣，SSL 模式不正確會導致無限 redirect 迴圈。
方式二：Wrangler CLI 本地開發與部署
Wrangler 是 Cloudflare 官方的 CLI 工具，目前最新版本是 v4（2025 年 3 月釋出），建議有 Node.js 環境的開發者使用。安裝方式：npm install -g wrangler。安裝完成後先執行 wrangler login 讓 CLI 取得帳號授權，然後用 wrangler init my-worker 建立新專案。Wrangler 會產生基本的檔案結構，包含 src/index.js（Worker 主程式）和 wrangler.toml（設定檔）。
在本地開發時，執行 wrangler dev 會啟動一個本地開發伺服器，可以直接在瀏覽器測試 Worker 的行為。確認邏輯正確後，執行 wrangler deploy 就會把腳本部署到 Cloudflare 全球網路。從 Wrangler v4.68.0（2026 年 2 月）開始，wrangler deploy 還會自動偵測你的框架並設定所需依賴，部署流程更簡化了。Wrangler 也支援 wrangler tail 指令，可以即時查看 Worker 的執行日誌，對於除錯非常有用。
方式三：Cloudflare Pages Functions
如果你的 WordPress 網站採用 Headless 架構（前端用 React/Vue 等靜態框架），可以考慮使用 Cloudflare Pages Functions。只要在專案根目錄建立一個 functions 資料夾，裡面的 .js 檔案就會自動被辨識為 Serverless Function。跟 EasyEngine 部署 WordPress 的傳統方式不同，Pages Functions 是完全無伺服器的，搭配 Git 儲存庫可以做到推送即部署。
WordPress 整合 Cloudflare Workers：HTML 邊緣快取實戰
前面講了原理和部署方式，接下來進入實戰。這裡要教你如何用 Workers 實現 WordPress HTML 頁面的邊緣快取。這是 Workers 最常見也最實用的應用場景，效果立竿見影。
安裝 Cloudflare Page Cache 外掛
第一步，在你的 WordPress 網站安裝「SW Cloudflare Page Cache」外掛（在 WordPress 外掛庫搜尋「Cloudflare Page Cache」即可找到）。這個外掛的作用是在每個 HTML 頁面的 HTTP 回應標頭中加入 x-HTML-Edge-Cache 標記，告訴 Worker 這個頁面可以被快取，以及快取的狀態（cache 或 bypass）。
為什麼需要這個外掛？因為 Worker 需要一個明確的訊號來判斷頁面是否應該快取。WordPress 預設不會告訴 CDN 動態頁面能不能快取，這個外掛補足了這個缺口。如果你已經在使用其他的 WordPress 快取外掛，這個外掛可以跟它們並存，不會衝突。搭配 網站速度最佳化 的全套工具一起使用，效果會更好。
Worker 腳本的核心邏輯
Worker 腳本的核心邏輯可以拆成三個步驟。收到請求時，先檢查 Cloudflare Cache API 裡有沒有快取。如果快取命中且未過期，直接回應快取內容。如果快取未命中，把請求轉發到來源伺服器，取得回應後，檢查回應標頭裡的 x-HTML-Edge-Cache 值。如果值為 cache，就把回應存入快取；如果值為 bypass，就不快取。
判斷 bypass 的常見條件包括：使用者已登入（Cookie 裡有 wordpress_logged_in）、頁面包含 WooCommerce 購物車、或是 POST 請求。這些條件確保每位使用者看到的都是正確的個人化內容，而不是別人的快取。
Cloudflare 官方提供了一個參考的 Worker 腳本，你可以在 GitHub 上找到完整的程式碼。把這個腳本貼到你的 Worker 裡，然後修改三個變數：email（你的 Cloudflare 帳號 Email）、key（Global API Key）、zone（Zone ID）。
驗證快取是否生效
設定完成後，用 Chrome 瀏覽器打開你的網站，按 F12 開啟開發者工具，切換到「Network」分頁，重新整理頁面。點選第一個請求（通常是頁面的 HTML 文件），在回應標頭裡找 cf-cache-status。如果顯示 HIT，表示 Cloudflare 快取成功命中。找 x-html-edge-cache-status，如果也顯示 HIT，表示 Worker 的 HTML 邊緣快取也正常運作。
你也可以用 curl 指令快速驗證：
curl -sI https://你的網域 | grep -i cache
如果看到 cf-cache-status: HIT 和 x-html-edge-cache-status: HIT，快取已經生效。使用 Fast or Slow 測速工具 或 GiftofSpeed 從全球不同地點測試你的網站，TTFB 應該會大幅降低。搭配 Imagify 圖片壓縮 和 instant.page 預載入，整體載入速度還能再提升一個檔次。
進階應用：流量過濾與安全防護
Workers 不只能做快取，它也是一個靈活的流量管理工具。你可以用它來阻擋惡意爬蟲、限制存取頻率、根據地理位置封鎖流量，甚至自訂安全規則。這些功能跟 WordPress 安全強化 的基本方法互補，讓你的網站多了一層在邊緣就開始過濾的防線。
識別與阻擋惡意爬蟲
惡意爬蟲是很多站長的噩夢。它們會瘋狂抓取你的內容、消耗伺服器資源，甚至嘗試暴力登入後台。Workers 可以根據 User-Agent、請求路徑和行為模式來識別並阻擋這些爬蟲。一個簡單的做法是在 Worker 裡維護一個 User-Agent 黑名單：
const blockedBots = ['SemrushBot', 'AhrefsBot', 'MJ12bot', 'DotBot', 'Semrush'];
當 Worker 收到請求時，檢查 request.headers.get('User-Agent') 是否匹配黑名單中的任何一項。如果匹配，直接回應 403 Forbidden。要注意的是，有些搜尋引擎的爬蟲（Googlebot、Bingbot）是你希望放行的，設定黑名單時要小心不要誤擋。更進階的做法是搭配 Cloudflare Turnstile 驗證碼，對可疑流量顯示驗證挑戰，而不是直接封鎖。
自訂 Rate Limiting 規則
Cloudflare 內建的 Rate Limiting 功能需要付費方案，但你可以用 Workers 搭配 Workers KV 自己實作免費版本。原理是：用 KV 記錄每個 IP 的請求次數和時間戳，如果在滑動窗口內超過設定的閾值，就暫時阻擋該 IP。
這個做法的好處是完全免費（使用 Workers KV 免費額度），而且你可以根據自己的需求調整規則。例如，對於 經常被攻擊的 WordPress 後台 路徑（/wp-login.php、/wp-admin/）設定更嚴格的限制，一般的前端頁面則放寬。搭配 Security Header Scanner 檢查你的安全標頭設定，可以建立更完整的防護網。定期用 WordPress 網站狀態檢查工具 檢查網站健康度，確保安全設定都正常運作。
Workers KV 與進階功能：A/B 測試、地理位置路由
Workers KV 是 Cloudflare 提供的全球分佈式鍵值儲存服務。它把資料複製到 Cloudflare 的每個邊緣節點，讀取延遲極低（通常在 10ms 以內）。免費方案提供每天 100,000 次讀取和 1,000 次寫入，付費方案則是每月 1,000 萬次讀取和 100 萬次寫入。KV 的資料最終一致性保證在 60 秒內全球同步。
A/B 測試實作範例
用 Workers 做 A/B 測試的好處是不需要在 WordPress 端安裝任何外掛，所有邏輯都在邊緣處理。做法是：Worker 收到請求時，檢查 Cookie 裡有沒有 A/B 測試的分組標記。如果沒有，隨機分配到 A 組或 B 組（各 50%），並透過 Set-Cookie 標頭把分組記錄下來。A 組看到原始頁面，B 組看到修改後的頁面（可以透過修改 HTML、替換圖片、或導向不同 URL 來實現）。
這種方式對 SEO 非常友善，因為搜尋引擎爬蟲看到的是一致的內容（沒有 Cookie 的訪客預設看到 A 組）。測試結果可以搭配 On-page SEO 優化 的數據一起分析。記得用 結構化資料測試工具 確認兩個版本的結構化資料都正確。
地理位置路由設定
Workers 可以透過 request.cf.country 屬性取得訪客的國家代碼。你可以根據這個資訊做很多事情：把台灣訪客導向繁體中文版，美國訪客導向英文版；或者把歐洲訪客導向 GDPR 合規的頁面。這對於使用 WordPress SEO 外掛 管理多語系網站的站長來說，是一個很好的補充方案。搭配 Detailed SEO Extension 可以快速檢查每個地區版本的 SEO 設定是否正確。
Cloudflare Workers 對 Core Web Vitals 的影響
Core Web Vitals 是 Google 用來評估頁面體驗的三個核心指標：LCP（最大內容繪製）、INP（互動到下一次繪製的延遲）、CLS（累計版面配置位移）。Workers 對這些指標的影響程度不盡相同，但對 TTFB 的改善最為顯著。
當 Worker 從邊緣快取直接回應 HTML 時，TTFB 可以從原本的 200-500ms 降到 50ms 以下。瀏覽器能更早開始解析 HTML 和載入子資源，LCP 也會跟著下降。CLS 基本不受影響，因為 Workers 處理的是傳輸層，不會改變頁面的版面配置。
| 指標 | Workers 啟用前（參考值） | Workers 啟用後（參考值） | 改善幅度 |
|---|---|---|---|
| TTFB | 200-500ms | 30-80ms | 60-85% |
| LCP | 2.5-4s | 1.5-2.5s | 30-50% |
| FCP | 1.5-3s | 0.8-1.5s | 40-60% |
| CLS | 視網站而定 | 基本不變 | 0% |
上面的數據是參考值，實際效果取決於你的主機位置、網站架構和快取設定。用 網站速度測試工具 或 Speedcheck 分別測試啟用 Workers 前後的數據，就能看到具體的改善幅度。搭配 Cloudflare Speed Test 還能測試網路層面的延遲變化。
常見錯誤排除與除錯工具
快取命中率偏低的排查清單
快取命中率偏低是最常見的問題。如果 Worker 明明在運作，但 cf-cache-status 一直顯示 MISS，可能的原因有：WordPress 外掛沒有正確輸出 x-HTML-Edge-Cache: cache 標頭、Cookie 裡有 wordpress_logged_in 導致 Worker 判定為已登入用戶而 bypass 快取、或者是 Route 規則沒有正確套用到所有頁面。逐一檢查這些條件，通常能找到原因。
另一個容易被忽略的問題是 WordPress 資料庫連線錯誤 導致的 5xx 回應。如果來源伺服器回應 500 錯誤，Worker 預設不會把 5xx 回應存入快取。這時候你會看到快取命中率突然下降，但其實是後端出了問題。
Worker 執行錯誤的處理方式
如果 Worker 拋出「Exceeded CPU Limit」錯誤，代表你的 Worker 腳本在單次請求中消耗了超過方案限制的 CPU 時間。常見原因是過多的字串處理、正則表達式匹配、或是 KV 的同步讀寫。最佳化方式包括：減少不必要的字串操作、把 KV 讀取改為非同步（await 放在 event.waitUntil 裡）、以及避免在 Worker 裡做 JSON 的深層解析。
除錯工具方面，wrangler tail 可以即時查看 Worker 的 console.log 輸出。Cloudflare Dashboard 的 Workers Analytics 頁面則提供了請求量、錯誤率、CPU 使用時間等關鍵指標。如果遇到 503 或 504 的問題，先確認是 Worker 還是來源伺服器導致的，Dashboard 裡的 Analytics 可以幫你區分。
Cloudflare Workers 與其他邊緣運算服務比較
邊緣運算不是 Cloudflare 獨有的概念。AWS 有 Lambda@Edge，Vercel 有 Edge Functions，Deno 有 Deno Deploy。這些服務的核心概念都差不多，但在功能、計費和生態系上有明顯差異。
| 功能 | Cloudflare Workers | AWS Lambda@Edge | Vercel Edge Functions | Deno Deploy |
|---|---|---|---|---|
| 免費方案 | 10 萬次/天 | 無 | 有限 | 有限 |
| 全球節點數 | 300+ | 600+（僅限 CloudFront） | 100+ | 30+ |
| 冷啟動時間 | 約 5ms | 100-500ms | 約 5ms | 約 5ms |
| 支援語言 | JS/WASM | JS/Python | JS/TS | JS/TS/WASM |
| KV 儲存 | Workers KV | S3/DynamoDB | Vercel KV | Deno KV |
| 適合場景 | 已用 Cloudflare 的站長 | AWS 生態系用戶 | Next.js 用戶 | Deno 愛好者 |
對於已經在用 Cloudflare CDN 的 WordPress 站長來說，Workers 是最自然的選擇。不需要額外註冊帳號、不需要綁定特定的雲端平台、計費方式簡單透明。如果你的網站是架在 A2 Hosting 或 SiteGround 這類已經跟 Cloudflare 有合作的主機上，啟用 Workers 只需要幾分鐘。即使是使用 Hostinger 或 DreamHost 的站長，只要把 DNS 代管到 Cloudflare 就能用 Workers。想知道你的網站託管在哪裡，可以用 Hosting Checker 快速查一下。更多主機選擇可以看看 WPX Hosting 和 HostPapa 的評價。
誰適合用 Cloudflare Workers，誰先不要
Workers 不是每個人都需要。如果你的 WordPress 網站日均不到 1,000 PV，主機又在亞洲地區（例如 Kinsta 的 Google Cloud 台灣節點），單靠主機端的快取外掛和 GZIP 壓縮 可能就夠了，Workers 的邊際效益不明顯。
以下情況適合用 Workers：你的主機不在亞洲（美國或歐洲的共享主機很常見）、你的網站有全球讀者、你想減少主機的 PHP 運算負擔、你需要免費的 Rate Limiting 或爬蟲阻擋功能、你想做 A/B 測試或地理位置路由。
以下情況可以先不用：你的網站流量很小（日均不到 500 PV）、你已經用了高階主機（Kinsta、WP Engine 等）且快取命中率很高、你不願意碰任何程式碼（雖然有範本可用，但基本除錯還是需要一點 JavaScript 概念）。
三個可以立即執行的下一步
1. 確認你的網站是否已經透過 Cloudflare 做 DNS 代管。登入 Cloudflare Dashboard，如果看到你的網域且狀態為「Active」，就可以直接進入 Workers 設定。如果還沒有，先完成 Cloudflare CDN 與 DNS 設定教學再回來。
2. 用 Dashboard 建立 Hello World Worker 測試連通性。到 Workers and Pages 點「Create Worker」，用預設腳本部署，然後設定一個 Route 指向你的網域的一個測試路徑（例如 example.com/test-worker/*）。用瀏覽器訪問這個路徑，如果看到 Worker 的回應，表示基礎設定沒問題。預期結果是瀏覽器顯示 Worker 的預設回應頁面。
3. 安裝 Cloudflare Page Cache 外掛，套用官方的 HTML 邊緣快取腳本。完成後用 curl 檢查 cf-cache-status 和 x-html-edge-cache-status，連續兩次請求都看到 HIT 就算成功。用 Fast or Slow 測速工具測試前後的 TTFB 差異，你應該能看到明顯的改善。
Cloudflare Workers 常見問題 FAQ
Cloudflare Workers 免費方案每天 10 萬次請求夠用嗎？
對於日均 10,000 頁面瀏覽量以下的網站，免費方案通常綽綽有餘。每個頁面瀏覽大約會觸發 1-4 次 Worker 請求（取決於你的 Route 設定），所以 10 萬次請求大約對應 25,000 到 100,000 PV。你可以在 Cloudflare Dashboard 的 Workers Analytics 頁面查看實際用量。
使用 Cloudflare Workers 會影響 SEO 嗎？
正確設定的 Workers 不會影響 SEO，反而能提升排名。原因是 Workers 加快了頁面載入速度，而速度是 Google 排名因子之一。快取命中時搜尋引擎爬蟲也能拿到更快的回應。唯一要注意的是，如果你用 Workers 修改了頁面內容（例如 A/B 測試），要確保搜尋引擎爬蟲看到的是一致的版本。
如何確認 Cloudflare Worker 是否正常運作？
最簡單的方法是用瀏覽器的開發者工具（F12）查看回應標頭。找到 cf-cache-status 和 x-html-edge-cache-status，如果都顯示 HIT，表示 Worker 和快取都正常。你也可以在 Cloudflare Dashboard 的 Workers Analytics 頁面查看請求量、錯誤率和 CPU 使用時間。
Workers 能用來做圖片最佳化嗎？
Workers 可以做簡單的圖片處理（例如根據 User-Agent 回傳不同尺寸），但不建議用 Workers 做複雜的圖片壓縮或格式轉換，因為這些操作很容易超過 CPU 時間限制。圖片最佳化建議使用 Cloudflare Images 服務，或者在 WordPress 端用 Imagify 這類專門的圖片壓縮工具。Worker 負責快取和路由，圖片處理交給更合適的工具。
不會寫程式可以使用 Workers 嗎？
可以。Cloudflare 有提供 Workers 的範本庫（Templates），裡面有現成的 HTML 快取、重新導向、安全標頭等常見場景的腳本。你只需要複製貼上，修改幾個變數就能用。不過，如果你想要自訂更複雜的邏輯（例如 Rate Limiting 或 A/B 測試），還是建議具備基本的 JavaScript 知識。也可以先看看 WordPress 佈景主題推薦 和 如何挑選 WordPress 主題，從網站基礎架構開始熟悉。
如果你覺得這篇 Cloudflare Workers 教學對你有幫助，歡迎分享給其他有需要的站長。想了解更多 WordPress 網站加速與安全的主題，可以看看我們的 Cloudflare 完整教學和 Cloudflare Email Routing 介紹，把 Cloudflare 的免費功能都善用起來。如果你正在挑選主機，別忘了看看 Bluehost 和 Kinsta 的評價，一個好的主機加上 Cloudflare Workers，WordPress 網站速度就能達到水準之上的表現。
