Cloudflare Pages vs Vercel：靜態網站免費託管與 CI/CD 部署評測
Cloudflare Pages 於 2020 年底正式推出，定位是「為前端開發者設計的全端平台」。它不是獨立存在的產品，而是整個 Cloudflare 開發者生態的一環，與 Workers、KV、D1、R2、Durable Objects 等服務緊密相連。
核心架構：以 Workers 為骨幹的邊緣運算
Pages 的底層其實就是 Cloudflare Workers——一套執行在 V8 隔離沙箱（Isolate）中的邊緣運算環境。當你部署一個靜態網站，Pages 會把編譯產物上傳到 Cloudflare 的全球網路；當你需要動態邏輯，則可以透過 /functions 目錄撰寫 Pages Functions，它們會被編譯成 Workers 並在邊緣節點執行。
這個架構的最大優勢是延遲極低且冷啟動極快。傳統 Serverless 平台（例如 AWS Lambda）採用容器模型，冷啟動動輒數百毫秒；Workers 的 Isolate 模型冷啟動通常在 5 毫秒以內，對 API 路由或簡單的 SSR 場景來說體感差異非常明顯。
另一個關鍵是 Cloudflare 自家的 Anycast 網路。使用者的請求會被路由到最近的節點，而 Cloudflare 在台灣（台北）與亞洲主要城市都有節點，對本地使用者來說，這意味著相當穩定的回應時間。
免費額度與硬性限制一覽
Cloudflare Pages 免費方案的慷慨程度，是它在社群中最常被稱讚的一點。以下是重點整理：
網站數量：無限。每個專案都可以獨立設定網域與環境變數。
並行建置數：1（免費方案）。同一時間只能跑一個建置。
商業使用：允許。這點非常重要，免費方案並沒有禁止商業用途。
值得注意的是，Pages 的建置環境規格相對樸素（約 2 vCPU、8 GB 記憶體等級），而且官方對建置時間有 20 分鐘的上限。對於使用大型框架、需要跑複雜建置流程的專案來說，這可能是個瓶頸。
CI/CD 部署流程實測
Pages 的部署流程相當直覺。連結 GitHub 或 GitLab 帳號後，選擇儲存庫，設定建置指令（例如 npm run build）與輸出目錄（例如 dist），之後每次推送就會自動觸發建置與部署。
它的分支預覽機制值得一提。任何非正式分支的推送都會產生一個獨立的預覽網址，格式類似 <branch>.<project>.pages.dev，方便團隊在合併前檢查。此外，Pages 也支援直接透過 Wrangler CLI 進行「Direct Upload」，跳過 Git 整合，適合已經有自己 CI 流程的團隊。
實測上，一個中型 Astro 網站的建置時間約在 40 秒到 1 分半之間，部署到全球節點的時間通常在 10 秒內完成。整體而言體驗流暢，但在「建置日誌的可讀性」上略遜於 Vercel，錯誤訊息有時不夠直白。
進階能力：Functions、KV、D1、R2 與 AI Gateway
Pages 真正的威力在於它與 Cloudflare 生態的整合。你可以直接在 Pages 專案中呼叫：
KV：全球分散的鍵值儲存，適合存設定檔或快取。
AI Gateway：統一管理對外 AI 模型的呼叫與快取。
這套組合讓 Pages 從「靜態託管」升級為「全端平台」，而且多數服務都有免費額度。如果你的專案本來就打算走 Cloudflare 全家桶，整合成本會非常低。
三、Vercel 完整解析
Vercel 成立於 2015 年（前身為 ZEIT），是 Next.js 框架的創造者。它的產品哲學很清楚：讓前端開發者從寫完程式碼到上線，中間不需要思考任何基礎設施。
核心定位：為前端框架而生的部署平台
Vercel 對 Next.js 的支援是原生等級的——不只是「能部署」，而是把 App Router、Server Components、Server Actions、Incremental Static Regeneration（ISR）、Middleware 等特性都做成平台的一等公民。當 Next.js 推出新功能時，Vercel 通常是最快支援的地方，有時甚至是唯一支援的地方。
除了 Next.js，Vercel 也支援 Astro、SvelteKit、Nuxt、Remix 等主流框架，並且會自動偵測框架類型、套用對應的建置設定。這種「零設定」體驗對新手非常友善。
Vercel 的邊緣網路同樣是自建的，但規模與 Cloudflare 相比較小。近年來它持續擴充節點，在亞洲的東京、香港、新加坡、首爾都有佈點，台灣本地則有台北節點（部分方案可用）。
免費（Hobby）方案額度與限制
Vercel 的 Hobby 方案是個人開發者的入門選擇，但它的限制比 Cloudflare Pages 明顯許多：
Edge Function 呼叫：每月 100 萬次。
部署次數：每日 100 次。
單次建置最長時間：45 分鐘。
團隊協作：不支援。Hobby 是單人方案，無法邀請成員。
換句話說，Vercel 的免費方案更接近「試用版」而非「長期免費方案」。如果你的專案有任何營利意圖，成本會立刻浮現。
CI/CD 與預覽部署的開發者體驗
如果說 Cloudflare Pages 的部署體驗是「順暢」，Vercel 的體驗可以形容為「享受」。它的幾個亮點：
建置日誌極度清晰：錯誤訊息會直接指出檔案與行號，甚至提供修復建議。
這些功能對個人開發者或許可有可無，但對有規模的前端團隊來說，它們節省的時間是真金白銀。
進階能力：Edge Functions、ISR、Analytics、AI SDK
Vercel 的進階功能大多圍繞在「讓 Next.js 更好用」這個核心：
這些服務設計得很精緻，但幾乎每一項都與 Vercel 平台本身綁定。一旦深度使用，遷移成本會相當可觀。
四、正面對決：八大關鍵指標橫向評測
前面兩節分別介紹了兩個平台的特色，接下來我們直接把它們放在同一張桌子上比較。以下八個指標，是筆者認為在做選擇時最該優先考慮的。
指標一：免費額度與費用結構
這是最直觀的差異。Cloudflare Pages 在免費方案上幾乎沒有懸念地勝出：無限頻寬、允許商業使用、無限網站數。Vercel 的 Hobby 則限制在 100 GB 流量、禁止商業用途。
但這裡有個細節值得注意。Vercel 的 100 GB 是「Fast Data Transfer」，計算的是從網路邊緣傳出的資料量，靜態資產快取命中時不重複計費。對一般流量不大的個人部落格來說，100 GB 其實不太容易用完。真正的風險在於「爆紅」——一篇貼文上了熱門，流量瞬間衝高，帳單就跟著跳。Cloudflare 在這個情境下完全沒有後顧之憂。
項目
Cloudflare Pages（免費）
Vercel Hobby（免費）
頻寬
無限
100 GB / 月
建置次數
500 次 / 月
100 次 / 日
商業使用
允許
禁止
團隊成員
可多人（依帳號權限）
不支援
超量處理
靜態資源不受影響
需升級或服務受限
付費起價
Workers Paid 約 $5/月起
Pro 約 $20/人/月起
指標二：全球存取效能與台灣節點實測
就全球覆蓋率而言，Cloudflare 的節點數量明顯多於 Vercel。根據 Cloudflare 官方資料，其網路覆蓋超過 330 個城市、120 個以上國家；Vercel 的邊緣網路雖然持續擴張，但在南美洲、非洲與部分亞洲地區的節點密度仍有差距。
對台灣使用者來說，兩者都有本地或鄰近節點可用。實際測試上，Cloudflare 的 TTFB（Time To First Byte）通常能壓在 30–60 毫秒之間，Vercel 在台北節點可用時表現接近，但若請求被路由到香港或東京，延遲會拉高到 80–120 毫秒。這種差異對一般網站使用者幾乎無感，但對 API 密集的應用或 SEO 爬蟲評分可能有些微影響。
值得一提的是，Vercel 的 ISR 與邊緣快取策略設計得相當聰明，對於內容更新頻繁的網站，能在「快取命中率」與「內容新鮮度」之間取得不錯的平衡；Cloudflare 則偏向「快取久一點、必要時手動清除」的策略。
指標三：建置速度與 CI/CD 體驗
建置環境方面，Vercel 的付費方案提供更強的機器規格與更長的建置上限，Hobby 方案也有 45 分鐘的單次上限，對大型專案較友善。Cloudflare Pages 的建置環境相對固定，且官方限制 20 分鐘，遇到相依套件龐大或需要跑影像優化的專案，可能會碰到瓶頸。
不過在 CI/CD 的「順手感」上，Vercel 明顯領先。從建置日誌的排版、錯誤提示的精準度，到預覽環境的註解功能，Vercel 的每一個細節都在降低開發者的認知負擔。Cloudflare Pages 的介面較為樸素，功能齊全但驚喜不多。
如果你的團隊重視「部署這件事本身的體驗」，Vercel 值得那筆錢；如果你只想要「推上去、能跑就好」，Cloudflare 完全夠用。
指標四：框架支援與生態系成熟度
這一點沒有懸念：Next.js 專案請用 Vercel。原因是 Vercel 就是 Next.js 的開發者，許多新特性在 Vercel 平台上會第一時間支援，甚至有部分是平台獨佔。雖然 Cloudflare 透過 @cloudflare/next-on-pages 與 OpenNext 專案努力追趕，但相容性與邊界案例的處理仍有落差，尤其是涉及 Node.js 原生模組、影像優化、或複雜的 Middleware 邏輯時。
反過來說，如果你用的是 Astro、Hugo、Eleventy、Jekyll 這類純靜態產生器，或是 SvelteKit、Nuxt 的靜態輸出模式，兩個平台都支援得很好，Cloudflare 甚至因為部署成本低而更適合。Astro 官方文件就把 Cloudflare 列為推薦的部署目標之一。
指標五：自訂網域、DNS 與 SSL
Cloudflare 在這方面有先天優勢。如果你的網域本來就託管在 Cloudflare DNS，新增自訂網域到 Pages 幾乎是即時生效，SSL 憑證自動簽發，還能順便享有 Cloudflare 的 DDoS 防護、WAF、Bot 管理等安全功能。整個流程一氣呵成。
Vercel 的網域設定同樣簡單，並且支援自動處理 DNS 記錄，但如果你想把 DNS 繼續放在其他供應商，就需要手動設定 CNAME 或 A 記錄，稍微繁瑣一些。SSL 憑證由 Vercel 自動管理，同樣免費。
整體而言兩者都好用，但 Cloudflare 的整合深度更勝一籌，尤其當你本來就是 Cloudflare 使用者時。
指標六：可觀測性與日誌
Vercel 在這項目表現更好。它的部署日誌、執行日誌、函式調用追蹤都整合在同一個儀表板中，並且提供即時日誌串流（Runtime Logs），除錯體驗相當現代化。
Cloudflare Pages 的日誌則相對分散。Functions 的日誌需要透過 wrangler tail 指令或 Workers 儀表板查看，Pages 與 Workers 兩套系統之間存在一些概念重疊，新手容易混淆。Cloudflare 近年在這方面持續改善，但就「開箱即用的可觀測性」而言，Vercel 仍佔上風。
指標七：商業使用授權與合規
這是一條很多人忽略、但可能致命的紅線。Vercel Hobby 方案明確禁止商業用途。官方條款寫得很清楚：Hobby 方案僅限個人、非商業用途。什麼算商業？放 Google AdSense、接受贊助、替客戶做網站、導購連結——都算。一旦被檢舉或系統偵測到，Vercel 有權暫停你的專案。
Cloudflare Pages 免費方案則沒有這項限制，商業網站、接案作品、小型電商都能合法使用。對自由接案者與小型工作室來說，這是個不小的成本差異：一個十人團隊用 Vercel，每月就要多出 200 美元的支出。
指標八：鎖定風險與長期可持續性
最後一個指標最抽象，卻也最關鍵：你把東西放上去之後，還搬得走嗎？
Cloudflare Pages 的靜態輸出本質上是純檔案，隨時可以用 Wrangler 下載或重新部署到其他地方。Functions 使用的是標準的 Web API（Request / Response），雖然部分 API（如 KV、D1）有平台綁定，但核心邏輯通常可以移植。
Vercel 的鎖定則更深。一旦你使用了 ISR、Edge Config、Vercel KV、Vercel Postgres、AI SDK 的特定功能，要離開就得重寫相當一部分程式碼。這不是缺點——它換來的是極致的便利性——但選擇之前必須清楚自己在交換什麼。
另一個要考慮的是平台的長期策略。Cloudflare 近年將重心逐漸移向 Workers，Pages 的更新節奏相對放緩，官方文件也開始建議「新專案可以考慮直接用 Workers」。這不代表 Pages 會被廢棄，但開發者應該留意生態演進的方向。Vercel 則持續把資源集中在 Next.js 與 AI 相關產品上，方向相對明確。
五、實際情境選擇建議
看完八個指標，你可能還是想問：那我到底該選哪個？答案取決於你的具體情境。以下提供幾個典型判斷點。
選擇 Cloudflare Pages 的五種情境
選擇 Vercel 的五種情境
你重視除錯與可觀測性：清晰的建置日誌與執行追蹤能省下大量時間。
如果只能給一句建議：個人、內容型、預算敏感、有商業色彩 → Cloudflare Pages；團隊、Next.js、重視 DX、有預算 → Vercel。
六、常見問題與實務踩雷
規格比較是一回事，實際操作又是另一回事。以下整理幾個筆者與社群中最常遇到的問題。
建置失敗的常見原因與排查
在 Cloudflare Pages 上，最常見的建置失敗原因包括：Node.js 版本不符（Pages 預設版本可能與本地不同，需透過 .nvmrc 或環境變數指定）、輸出目錄設定錯誤、相依套件在 CI 環境中安裝失敗、以及檔案數量超過 20,000 個限制。排查時建議先在本機用乾淨的 node_modules 重跑一次建置指令，確認不是環境問題。
在 Vercel 上，常見問題則包括：環境變數未正確設定到對應環境（Production / Preview / Development 是分開的）、Next.js 版本與平台支援版本不符、以及建置記憶體不足（大型專案可能需要升級方案）。Vercel 的錯誤訊息通常會直接指向問題，排查效率較高。
快取與重新部署的陷阱
兩個平台都會對靜態資產進行積極快取，這在正常情況下是優點，但遇到「明明重新部署了，使用者卻還看到舊版」的情況就很惱人。常見原因是 HTML 檔案被 CDN 快取，或是 Service Worker 沒有正確更新。
建議做法是：在建置產物中為靜態資源加上內容雜湊（content hash）檔名，HTML 則設定較短或零快取。Cloudflare Pages 可透過 _headers 檔案自訂快取策略，Vercel 則可透過 vercel.json 設定。
從 Vercel 搬到 Cloudflare 的注意事項
如果你決定從 Vercel 遷移到 Cloudflare Pages，以下幾點務必先確認：
環境變數的重新設定：兩個平台的環境變數不共通，需要逐一搬移。
七、總結：沒有最好，只有最適合
回到最初的問題：Cloudflare Pages 還是 Vercel？
如果我們把時間軸拉長來看，這兩個平台其實代表了兩種不同的產品哲學。Cloudflare Pages 走的是「基礎設施優先」路線——用龐大的網路、寬鬆的額度、開放的標準，吸引你把更多東西搬進它的生態。它的免費方案是真的免費，代價是你的開發體驗相對樸素，某些功能需要自己動手。Vercel 走的是「開發者體驗優先」路線——用精緻的工具鏈、原生框架支援、絲滑的部署流程，讓你把注意力全部放在產品上。它的代價是較貴的付費門檻與較深的平台鎖定。
對絕大多數個人開發者與內容創作者來說，Cloudflare Pages 的性價比難以超越。無限頻寬加上允許商業使用，意味著你可以在上面安心經營一個會成長的網站，而不用擔心某天帳單爆炸。對使用 Next.js 的專業團隊來說，Vercel 提供的效率提升通常足以合理化它的費用，尤其是當團隊規模與協作需求上升之後。
最後提醒一句：兩個平台都不是不能換的終身伴侶。多數靜態網站的核心資產就是那一份原始碼，換平台往往只是改幾個設定、切一次 DNS 的事。真正該避免的，是在架構設計上把自己綁死——例如過度依賴某個平台獨有的 API，卻沒有留下抽象層。保持程式碼的可移植性，你就能在任何時候，選擇當下最適合自己的那個平台。