Cloudflare Workers™ – 在 Cloudflare Edge 中加入 Script 規則，實現流量過濾與提升網站快取加速能力

如果你正在經營一個 WordPress 網站，或多或少都聽過 Cloudflare 這個名字。它的免費 CDN 與 DNS 服務幾乎成了網站加速的標準配備，幫助全球數百萬個網站縮短載入時間、降低主機負擔。不過，光是啟用 CDN 還不夠，很多站長後來都會遇到一個共同的瓶頸：WordPress 產生的動態 HTML 頁面很難被 CDN 有效快取，每次有新訪客造訪還是得回源到主機重新渲染。

Cloudflare Workers 就是為了解決這個問題而生的工具。它讓你能在 Cloudflare 全球 300 多個邊緣節點上執行 JavaScript 程式碼，直接在距離訪客最近的伺服器上處理請求、快取 HTML、過濾惡意流量，甚至做到 A/B 測試和地理位置路由。對於想要把 WordPress 網站速度推到極限的站長來說，Workers 堪稱是一把瑞士刀。

這篇教學會從原理講到實作，涵蓋三種部署方式、HTML 邊緣快取的完整設定、進階的爬蟲阻擋規則、Workers KV 的應用場景，以及跟其他邊緣運算服務的比較。不管你是剛接觸 Cloudflare 的新手，還是已經在用 WordPress 虛擬主機架站的老手，看完這篇都能動手把 Workers 用起來。

Cloudflare Workers 是什麼？邊緣運算如何加速你的網站

Cloudflare Workers 是 Cloudflare 在 2017 年推出的無伺服器邊緣運算平台。簡單講，它讓你把 JavaScript 程式碼部署到 Cloudflare 全球 300 多個資料中心，在每個 HTTP 請求經過 Cloudflare 邊緣節點時，先執行你的自訂邏輯，再決定要把請求轉發到來源伺服器，還是直接從快取回應。

這跟傳統 CDN 的靜態快取有本質上的不同。CDN 只能快取靜態資源（圖片、CSS、JS），碰到 WordPress 產生的動態 HTML 頁面就沒轍了。Workers 不一樣，它能在邊緣節點上判斷這個頁面能不能快取、該不該快取，甚至動態修改回應標頭和內容。這就好比你在 Cloudflare 的每個節點都安排了一個智慧型管理員，而不是一個只會照抄答案的影印機。

邊緣運算 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 的自動快取清除機制能幫你徹底解決這個頭痛問題。遇到 伺服器暫時無法回應 或 閘道逾時 的情況，Workers 還可以提供快取的離線版本，讓訪客至少能看到頁面內容。

Cloudflare Workers 的運作原理與技術架構

Workers 的底層使用的是 Google Chrome 瀏覽器同款 V8 JavaScript 引擎。Cloudflare 不是用虛擬機器或容器來隔離每個 Worker，而是用 V8 的 isolate 技術。這意味著 Worker 的冷啟動時間只有不到 5 毫秒，比傳統的 serverless 函式快了好幾個數量級。

當一個 HTTP 請求進入 Cloudflare 的網路時，Cloudflare 會根據 Route 規則判斷這個請求是否需要經過 Worker 處理。如果需要，Worker 會接收到一個 fetch 事件，包含完整的請求資訊（URL、標頭、Cookie 等）。Worker 可以決定是要直接回應、從快取取回內容、還是把請求轉發到來源伺服器。

請求生命週期詳解

一個典型的 Workers 請求處理流程是這樣的：使用者在瀏覽器輸入網址，DNS 解析到 Cloudflare，Cloudflare 收到請求後先經過防火牆和 Turnstile 驗證碼 等安全層，然後把請求交給 Worker。Worker 檢查快取（Cache API），如果有快取且未過期就直接回應，沒有快取就 fetch 來源伺服器，拿到回應後存入快取，再回應給使用者。整個過程在幾毫秒內完成。

Workers 的執行限制與記憶體配置

項目	免費方案	付費方案（$5/月起）
每日請求數	100,000 次	1,000 萬次/月（超出每百萬次 $0.50）
CPU 時間	10ms/次	50ms/次
記憶體	128MB	128MB
腳本大小	1MB	10MB
Worker 腳本數	10 個	無限制
Cron Triggers	5 個	無限制

這些限制對大多數 WordPress 網站來說非常寬裕。一個典型的 HTML 快取 Worker 處理一次請求只需 1-2ms CPU 時間，遠低於 10ms 的上限。如果你的 Worker 會做複雜的字串處理或大量的 KV 讀寫，才需要留意 CPU 時間限制。在搭配 GZIP 壓縮 的情況下，Worker 處理後的回應體積更小，傳輸速度也更快。

Cloudflare Workers 免費方案與付費方案完整比較

Cloudflare Workers 的免費方案對個人站長來說其實相當夠用。每天 10 萬次請求聽起來不多，但換算下來等於一個月 300 萬次請求，對於日均 5,000 到 8,000 頁面瀏覽量的網站綽綽有餘。真正需要付費方案的場景，通常是日均超過 3 萬 PV 的中大型網站，或者需要 Workers KV 大量讀寫的應用。

付費方案 $5 美元一個月，包含每月 1,000 萬次請求。超出的部分每百萬次 $0.50，計費方式跟 Kinsta 這類高階主機的按流量計費邏輯類似。如果你正在用 A2 Hosting 或 SiteGround 這類共享主機，搭配 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 請求（HTML + 靜態資源可能經過 Worker 處理）。如果你的 Route 設定只讓 Worker 處理 HTML 頁面，請求量還會更低。對於使用 DreamHost 或 FastComet 等主機的站長，Workers 免費方案幾乎一定能滿足需求。想看看各家的完整比較，可以參考我們整理的 WordPress 虛擬主機推薦懶人包。

使用 Cloudflare Workers 前的準備工作

在開始設定 Workers 之前，有幾件事要確認。你的網站必須已經透過 Cloudflare 進行 DNS 代管。如果你的網域還沒有接入 Cloudflare，可以先到我們之前的 Cloudflare 教學文章，裡面有從註冊到設定的完整流程。還沒買網域的話，先看看 如何申請註冊網域 和 選擇網域名稱的技巧，選一個好網域是一切的起點。

你也需要準備三個資訊：Cloudflare 帳號的註冊 Email、Global API Key（在 Cloudflare 帳號的 My Profile 頁面下方可以找到），以及你要啟用 Workers 的網站的 Zone ID（在 Cloudflare 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 & Pages」，點擊「Create Application」，選擇「Create Worker」。系統會自動產生一個預設的 Worker 腳本，你可以在線上編輯器裡把預設程式碼替換成你需要的邏輯。編輯完成後點「Save and Deploy」。

部署完成後，Worker 還不會對你的網站生效，因為你還沒設定 Route。到「Workers & 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 工具，建議有 Node.js 環境的開發者使用。安裝方式很簡單：npm install -g wrangler。安裝完成後先執行 wrangler login 讓 CLI 取得 Cloudflare 帳號授權，然後用 wrangler init my-worker 建立新專案。Wrangler 會產生基本的檔案結構，包含 src/index.js（Worker 主程式）和 wrangler.toml（設定檔）。

在本地開發時，執行 wrangler dev 會啟動一個本地開發伺服器，可以直接在瀏覽器測試 Worker 的行為。確認邏輯正確後，執行 wrangler deploy 就會把腳本部署到 Cloudflare 全球網路。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）。根據 Cloudflare 官方的說明，Workers 的設計理念是在邊緣執行程式碼，提供強大的網路延展能力，讓你的應用程式更快速也更安全。

驗證快取是否生效

設定完成後，用 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（首次位元組時間），雖然 TTFB 不在 Core Web Vitals 裡面，但它直接影響 LCP 和 FCP。當 Worker 從邊緣快取直接回應 HTML 時，TTFB 可以從原本的 200-500ms 降到 50ms 以下。這代表瀏覽器能更早開始解析 HTML 和載入子資源，LCP 也會跟著下降。

指標	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 還能測試網路層面的延遲變化。

常見錯誤排除與除錯工具

Workers 雖然好用，但設定過程中難免會遇到問題。以下列出幾個最常見的狀況和對應的解決方式。

快取命中率偏低的排查清單

快取命中率偏低是最常見的問題。如果 Worker 明明在運作，但 cf-cache-status 一直顯示 MISS，可能的原因有幾個：WordPress 外掛沒有正確輸出 x-HTML-Edge-Cache: cache 標頭、Cookie 裡有 wordpress_logged_in 導致 Worker 判定為已登入用戶而 bypass 快取、或者是 Route 規則沒有正確套用到所有頁面。逐一檢查這些條件，通常能找到原因。

另一個容易被忽略的問題是 WordPress 資料庫連線錯誤 導致的 5xx 回應。如果來源伺服器回應 500 錯誤，Worker 預設不會把 5xx 回應存入快取。這時候你會看到快取命中率突然下降，但其實是後端出了問題。定期監控 500 錯誤 和 502 錯誤 的發生頻率，可以及早發現主機層面的異常。

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 Service Unavailable 或 504 Gateway Timeout 的問題，先確認是 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+
CPU 時間限制	10-50ms	5-50ms	依方案	依方案
冷啟動時間	~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 常見問題 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 測試），要確保搜尋引擎爬蟲看到的是一致的版本。搭配 WordPress SEO 外掛 和 Detailed SEO Extension 可以幫你監控 SEO 表現。

如何確認 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 Page Rules 有什麼不同？

Page Rules 是宣告式的規則，你只能設定 Cloudflare 預先定義好的行為（例如「快取所有內容」、「強制 HTTPS」）。Workers 是程式化的，你可以用 JavaScript 寫任何自訂邏輯。Page Rules 適合簡單的場景，Workers 適合需要條件判斷和動態處理的場景。兩者可以並存，但要注意優先順序。

不會寫程式可以使用 Workers 嗎？

可以。Cloudflare 有提供 Workers 的範本庫（Templates），裡面有現成的 HTML 快取、重新導向、安全標頭等常見場景的腳本。你只需要複製貼上，修改幾個變數就能用。不過，如果你想要自訂更複雜的邏輯（例如 Rate Limiting 或 A/B 測試），還是建議具備基本的 JavaScript 知識。也可以參考 WordPress 佈景主題推薦 和 如何挑選 WordPress 主題 的文章，先從網站基礎架構開始熟悉。

Workers 支援哪些程式語言？

Workers 原生支援 JavaScript 和 TypeScript。透過 WebAssembly（WASM），你也可以執行 C、C++、Rust 等語言編譯出來的程式碼。不過大多數 WordPress 快取和流量管理的場景，JavaScript 就完全夠用了。如果你對 WordPress 開發有興趣，可以看看 Gutenberg 編輯器 和 Filester 檔案管理工具 的介紹，這些都是 WordPress 開發者常用的工具。碰到 WordPress 自動儲存 或 更新程序卡住 的問題，我們也有對應的解決方案教學。

如果你覺得這篇 Cloudflare Workers 教學對你有幫助，歡迎分享給其他有需要的站長。想了解更多 WordPress 網站加速與安全相關的主題，可以看看我們的 Cloudflare 完整教學 和 Cloudflare Email Routing 介紹，把 Cloudflare 的免費功能都善用起來。如果你正在挑選主機，別忘了看看 Bluehost 和 Kinsta 的評價，一個好的主機加上 Cloudflare Workers，你的 WordPress 網站速度就能達到水準之上的表現。