Cloudflare Workers vs Vercel Functions: So sánh 2026

Dùng Cloudflare Workers nếu bạn đang xây dựng một API phân tán toàn cầu, thiên về I/O, và chi phí hoặc độ trễ p99 đang trở thành vấn đề thực sự của sản phẩm. Dùng Vercel Functions nếu bạn đang làm việc sâu với Next.js, cần hơn 128 MB bộ nhớ mỗi function, hoặc thời gian từ khi code đến lần deploy đầu tiên quan trọng hơn chi phí mỗi request.

Bức tranh so sánh đã thay đổi vào tháng 6 năm 2025. Vercel ngừng hỗ trợ sản phẩm Edge Functions — sản phẩm chạy trên V8 isolate mà hầu hết các benchmark trước đó đã đo. Bây giờ bạn đang chọn giữa Cloudflare Workers và Vercel Functions với Node.js runtime chạy trên Fluid Compute của Vercel. Nếu bạn đã đọc các bài so sánh Workers với “Vercel Edge,” bạn đang đọc về một sản phẩm không còn tồn tại.

Bài viết này dành cho ai

Các team dev đã quen với edge runtime, đang đưa ra quyết định chọn nền tảng cho một deployment production trong năm 2026. Nếu bạn vẫn đang phân vân giữa serverless và containers, hãy bắt đầu từ đó — bài viết này giả sử bạn đã chọn hướng serverless.

Điều gì đã thay đổi: Vercel ngừng hỗ trợ Edge Functions

Tháng 6 năm 2025, Vercel chuyển Edge Middleware và Edge Functions sang chạy trên Node.js runtime thông qua Fluid Compute, và ngừng hỗ trợ sản phẩm Edge Functions gốc. Sản phẩm gốc chạy trong V8 isolate với các ràng buộc WinterCG, chặn hầu hết npm package. Fluid Compute thay thế bằng Node.js API đầy đủ, bộ nhớ lên đến 2–4 GB tùy theo gói, và một mô hình triển khai đa vùng khác.

Đây là hai sản phẩm khác nhau về bản chất. Hành vi cold-start, mô hình bộ nhớ và đặc tính throughput của Fluid Compute không thể so sánh với Edge Functions cũ. Hầu hết các benchmark bên thứ ba đã được công bố đều chạy trên sản phẩm đã bị ngừng hỗ trợ.

Những số liệu Vercel trước tháng 6 năm 2025 mà tôi trích dẫn bên dưới, tôi đều ghi chú rằng sản phẩm được đo lúc đó không còn là thứ bạn sẽ deploy nữa.

Chúng tôi đã kiểm tra gì

Bài viết này rút ra từ ba benchmark đã được công bố:

Khảo sát độ trễ toàn cầu của OpenStatus, tháng 2 năm 2024 (Cloudflare Workers) và tháng 3 năm 2024 (Vercel Edge Functions — sản phẩm đã bị ngừng hỗ trợ): TTFB end-to-end từ 6 vị trí probe toàn cầu. Báo cáo CF / Báo cáo Vercel.
Benchmark server-rendering của Railway, tháng 10 năm 2025: Next.js, React SSR và các workload tính toán nặng trên Workers, Vercel và Railway. Bên thứ ba, không phải benchmark của vendor. Blog Railway.
Benchmark Fluid Compute của Vercel, tháng 10 năm 2025: Bài kiểm tra throughput do Vercel tự thực hiện, so sánh Fluid Compute với Workers. Tài nguyên được cấp không bằng nhau — xem phần CPU. Blog Vercel.

Các con số về giá sử dụng số liệu chính thức từ trang giá của Cloudflare và trang giá của Vercel tính đến tháng 5 năm 2026.

Không có benchmark nào trong số này là của chúng tôi. Khi một vendor tự chạy test, tôi ghi chú điều đó, vì các vendor tối ưu hóa cho các con số họ công bố.

Cold start và độ trễ

Dữ liệu OpenStatus từ đầu năm 2024 cho thấy Workers có TTFB P75 138ms, P95 778ms, P99 991ms tổng hợp trên 6 vị trí probe toàn cầu (tổng hợp trên tất cả probe kết hợp). Vercel Edge Functions đã bị ngừng hỗ trợ ghi nhận P50 106ms, P95 178ms, P99 328ms theo cùng phương pháp.

Cần đặt vào ngữ cảnh. Đây là các con số TTFB — bao gồm cả thời gian truyền tải qua mạng từ mỗi probe đến PoP gần nhất, không chỉ là độ trễ cold-start riêng lẻ. Các con số này gộp cả yếu tố địa lý với hiệu năng runtime. Cloudflare vận hành hơn 330 PoP trên toàn cầu; một probe gần datacenter CF lớn sẽ cho kết quả rất khác so với một probe ở vùng thứ cấp.

Quan trọng hơn: phía Vercel trong benchmark này chạy trên sản phẩm đã bị ngừng hỗ trợ. Sản phẩm Fluid Compute hiện tại dùng bytecode caching và predictive warming để giảm cold start. Các phép đo TTFB độc lập từ bên thứ ba trên Fluid Compute với cùng phạm vi 6 probe của OpenStatus vẫn còn hiếm tính đến giữa năm 2026.

Cloudflare tuyên bố cold start dưới 5ms cho Workers. Điều này xuất hiện trong tài liệu marketing của họ. Tôi không tìm được phép đo trung lập từ bên thứ ba về độ trễ cold-start thuần túy để xác nhận — tôi trích dẫn đây là con số họ tuyên bố, không phải benchmark đã được kiểm chứng.

Các spike độ trễ P99 của Workers là mối lo ngại chính đáng mà developer đề cập nhiều nhất. Nguyên nhân là isolate eviction dưới áp lực bộ nhớ và GC pause — Cloudflare đã giải quyết một phần vấn đề này với V8 GC tuning trong bản phát hành tháng 10 năm 2025, nhưng P99 không ổn định trên Workers vẫn là đặc tính vận hành thực tế, không phải tin đồn thất thiệt.

Nhận định thực tế: TTFB P50 của Workers có tính cạnh tranh trong tập dữ liệu đó, và hơn 330 PoP có nghĩa là hầu hết người dùng toàn cầu đều đến được một edge node gần đó. Với các workload có yêu cầu P99 chặt chẽ, hãy kiểm tra function cụ thể của bạn trên các failure mode đã được ghi lại — round-trip I/O đến file, cache miss và Durable Object interaction đều có tác động khác nhau so với một response đơn giản.

Hiệu năng CPU

Đây là nơi so sánh trở nên phức tạp, vì benchmark chính được vendor chạy với tài nguyên không bằng nhau.

Vercel công bố kết quả benchmark vào tháng 10 năm 2025, tuyên bố Fluid Compute chạy nhanh hơn Workers 2–3.5 lần trên Next.js SSR và các workload throughput. Phương pháp: Vercel Functions được cấp 2 vCPU và 4 GB RAM; Workers chạy trên CPU dùng chung với 128 MB bộ nhớ. Đó không phải là so sánh kiểm soát được — tất nhiên một runtime với 4 GB và vCPU riêng sẽ vượt trội so với runtime với 128 MB và CPU dùng chung. Tốc độ tăng là có thực trong cấu hình đó; còn nó chứng minh điều gì về bản thân các runtime thì không.

Cloudflare công bố phản hồi vào tháng 10 năm 2025. Họ thừa nhận có khoảng cách hiệu năng CPU trên các workload đặc thù Next.js, cho rằng một phần là do tích hợp sâu giữa Next.js runtime của Vercel và Fluid Compute, đồng thời tung ra V8 GC tuning và các tối ưu hóa OpenNext — tuyên bố cải thiện khoảng 25% hiệu năng trên các workload không phải Next.js.

Benchmark của Railway từ tháng 10 năm 2025 — từ bên thứ ba — cho tín hiệu rõ ràng hơn:

Workload	Nền tảng nhanh nhất	Thời gian
React SSR	Cloudflare Workers	163ms
Tính toán nặng	Cloudflare Workers	550ms
Next.js SSR	Vercel	1089ms

Workers dẫn đầu trên SSR thông thường và tính toán. Vercel dẫn đầu trên Next.js SSR. Pattern này có lý: Fluid Compute có các tối ưu hóa gắn chặt với mô hình rendering của Next.js. Ngoài bối cảnh đó, lợi thế thu hẹp hoặc đảo chiều.

Ràng buộc nằm ở bộ nhớ. Workers có giới hạn cứng 128 MB trên tất cả các gói — free và trả phí đều như nhau. Điều này loại trừ xử lý ảnh, payload JSON lớn, tạo PDF và bất cứ thứ gì cần buffer lượng dữ liệu đáng kể trong bộ nhớ. Vercel Functions trên gói Pro cho phép lên đến 2–4 GB tùy cấu hình function. Nếu function của bạn cần hơn 128 MB, Workers không phải lựa chọn, bất kể runtime nào nhanh hơn.

Giá cả

Đây là yếu tố quyết định rõ ràng nhất với các team ở quy mô đáng kể.

Số request/tháng	Cloudflare Workers (trả phí)	Vercel Pro
1 triệu	$5	~$20
10 triệu	$5	~$20
100 triệu	$32	~$200+

Nguồn: Giá Cloudflare và Giá Vercel, tháng 5 năm 2026. Số liệu Vercel là ước tính cho edge request; chi phí CPU time được tính riêng.

Gói trả phí của Cloudflare bắt đầu từ $5/tháng và bao gồm 10 triệu request. Tăng từ 10 triệu lên 100 triệu chỉ thêm khoảng $27. Vercel Pro là $20/user/tháng tối thiểu — chỉ riêng tiền seat, chưa tính phí request hay compute. Ở mức 100 triệu request/tháng, bạn đang nhìn vào $200+ chỉ cho request, chưa kể CPU time trên đó.

Phí egress là yếu tố nhân thêm. Cloudflare không thu phí egress từ Workers. Vercel tính $0.15/GB sau 1 TB đầu tiên. Với các trường hợp có băng thông cao — streaming response lớn, API gateway, serving asset — sự chênh lệch này tích lũy nhanh ở quy mô lớn.

So sánh gói miễn phí:

Cloudflare Workers free: 100K request/ngày, giới hạn 10ms CPU mỗi request
Vercel Hobby: Serverless Functions có sẵn, compute hours bị giới hạn, không có SLA

Các team đã qua giai đoạn prototype nhưng chưa đến cỡ enterprise sẽ thấy Workers rẻ hơn đáng kể. Điểm hòa vốn mà ở đó phần bù DX của Vercel đáng bỏ tiền phụ thuộc vào bao nhiêu thời gian của team bạn được tiết kiệm — đó là yếu tố thực, nhưng là phép tính chi phí con người, không phải chi phí mỗi request.

Nếu chi phí ở quy mô lớn là yếu tố quyết định, bài phân tích hóa đơn thực tế Cloudflare vs AWS của chúng tôi bao gồm con số cho Workers, R2 và D1 tại các mốc 15M, 100M và 1 tỷ request.

API surface và hệ sinh thái

Cloudflare và Vercel có triết lý hệ sinh thái khác nhau, và cái nào phù hợp với bạn phụ thuộc vào những gì ứng dụng cần ở tầng storage và coordination.

Cloudflare Workers đi kèm một bộ primitive tích hợp sẵn: KV cho key-value storage, D1 cho SQLite tại edge, R2 cho object storage, Durable Objects cho stateful coordination nhất quán cao, Queues cho async processing, Vectorize cho vector search, và Workers AI cho model inference. Bạn không cần vendor bên thứ ba cho hầu hết các tính năng này. Đánh đổi: đây là các API đặc thù của Cloudflare. Nếu bạn dùng Durable Objects nhiều và cần migrate khỏi Cloudflare, bạn đang phải thiết kế lại tầng state, không chỉ đơn giản là redeploy compute.

Durable Objects nói riêng không có tương đương trực tiếp trên Vercel. Chúng cung cấp state nhất quán cao, đặt cạnh compute tại edge — single-instance object theo mô hình actor xử lý WebSocket connection, rate limiting với shared counter, hoặc trạng thái chỉnh sửa cộng tác. Liveblocks xử lý lên đến 500 triệu WebSocket message mỗi ngày trên Durable Objects. Nếu use case của bạn cần real-time coordination, Workers cho bạn primitive nguyên bản; Vercel sẽ hướng bạn đến dịch vụ bên thứ ba như Ably, Upstash hay Partykit.

Nếu bạn cũng đang cân nhắc Workers so với Lambda — đặc biệt cho các function CPU-nặng hoặc chạy lâu — bài so sánh Cloudflare Workers vs AWS Lambda của chúng tôi phân tích chi tiết giới hạn của từng serverless runtime.

Khả năng tương thích Node.js trên Workers đã cải thiện đều đặn. Compat flag cho phép hầu hết npm package tính đến năm 2025. Một số khoảng trống vẫn còn — một số crypto API, một số stream behavior, native addon. Nếu code của bạn phụ thuộc nhiều vào Node.js API, hãy test các dependency trước khi commit với Workers.

Vercel Functions sử dụng tích hợp bên thứ ba cho storage: Vercel KV qua Upstash, Vercel Postgres qua Neon, Vercel Blob cho object storage. Đây là các managed proxy đến các vendor được đánh giá cao. Bạn nhận được primitive đã được kiểm chứng trong production với API quen thuộc, cộng thêm vendor support ở tầng storage. Nhược điểm là thêm một dependency, và với các function gọi storage trên mỗi request, có độ trễ của một round-trip function-to-provider có thể không được đặt cạnh edge.

Thế mạnh của Vercel là tích hợp với hệ sinh thái Next.js và frontend. ISR, preview deploy theo từng branch, edge middleware và image optimization đều hoạt động cùng nhau mà không cần cấu hình. Toolchain được thiết kế xoay quanh use case này.

Trải nghiệm developer

Vercel thắng hạng mục này, và không phải sít sao — trừ khi bạn đang xây dựng API thay vì full-stack application.

Zero-config CI/CD, tự động preview deployment theo từng branch, tích hợp ISR sâu và mô hình deployment loại bỏ cả một nhóm quyết định về infrastructure: đó là câu chuyện DX của Vercel. Với một team Next.js, khoảng thời gian từ git push đến một preview URL hoạt động đầy đủ với hành vi tương đương production rất khó vượt qua. Lee Robinson tóm tắt workflow trong một tweet tháng 4 năm 2024 — điểm mấu chốt là tooling loại bỏ hoàn toàn một lớp quyết định.

DX của Cloudflare đã cải thiện. Wrangler là một CLI ổn, trải nghiệm dev local với miniflare hợp lý, và docs của Cloudflare khá chi tiết. Nhưng cấu hình Workers, KV namespace, D1 database và routing rule đòi hỏi tường minh hơn so với setup theo convention của Vercel. Các team xây dựng API backend trên Workers báo cáo trải nghiệm tốt. Các team migrate Next.js application sang Workers thường báo cáo gặp trở ngại — OpenNext thu hẹp khoảng cách, nhưng nó là một shim trên nền tảng không được thiết kế cho Next.js, không phải tích hợp nguyên bản.

Pattern migration của indie developer cho thấy điều gì đó rõ ràng: các developer chuyển từ Vercel sang Workers thường dẫn lý do chi phí và hệ sinh thái Workers, không phải cải thiện DX. Họ đang chủ động chấp nhận DX kém hơn để đổi lấy giá cả.

Để hiểu rõ hơn về giá trị thực tế của Vercel theo quy mô team, xem bài đánh giá Vercel 2026 của chúng tôi.

Lock-in và tính linh hoạt

Cả hai nền tảng đều có lock-in. Cơ chế khác nhau.

Lock-in của Cloudflare tập trung ở tầng storage và coordination. Bản thân Workers tuân thủ WinterCG — logic compute có thể chạy trên bất kỳ WinterCG runtime nào (Deno Deploy, Fastly Compute). Thực tế, tính di động của compute mà không có storage chỉ là một phần. Nếu ứng dụng của bạn được xây dựng trên D1 và Durable Objects, migration nghĩa là phải reimplementing tầng data.

Lock-in của Vercel ở tầng tích hợp framework. Các tính năng phụ thuộc vào infrastructure của Vercel — hành vi ISR, ngữ nghĩa edge middleware, image optimization — không chuyển sang host khác mà không cần thay đổi code. Migration khỏi Vercel đòi hỏi kiểm tra lại các tính năng Next.js bạn đã dựa vào và cái nào có self-hostable equivalent.

Bản thân Vercel đã chuyển các sản phẩm của mình khỏi Cloudflare Workers vào năm 2024. Lý do được nêu: hiệu năng CPU trên các workload của họ, độ trễ không ổn định, và round-trip latency từ các dịch vụ AWS-hosted của Vercel đến mạng của Cloudflare. Đây là dữ liệu hữu ích — đó là một tổ chức thực tế với workload production thực tế đưa ra quyết định đánh đổi có cân nhắc, không phải benchmark tổng hợp.

Kết luận: Cloudflare Workers hay Vercel Functions?

Chọn Cloudflare Workers nếu:

Workload của bạn được phân tán toàn cầu và thiên về I/O — API gateway, edge auth, geo-routing, nội dung động tại edge
Bạn cần real-time coordination state — WebSocket, collaborative editing, rate limiting với shared counter — và Durable Objects phù hợp với mô hình
Bạn đang chạy stack không phụ thuộc framework hoặc API-only backend, không phải Next.js application
Chi phí và phí egress là ràng buộc thực sự ở quy mô của bạn
Function của bạn thoải mái dưới 128 MB bộ nhớ

Chọn Vercel Functions nếu:

Bạn đang chạy Next.js application và muốn DX tích hợp đầy đủ — ISR, preview deploy theo từng branch, edge middleware và image optimization không cần cấu hình
Function của bạn cần hơn 128 MB bộ nhớ (giới hạn cứng của Workers, không thể override dù trả thêm tiền)
Workflow deployment của team và thời gian từ khi code đến lần deploy đầu tiên quan trọng hơn chi phí mỗi request
Bạn muốn tích hợp storage được quản lý bởi các vendor bên thứ ba uy tín

Tuyên bố “nhanh hơn 2–3.5 lần CPU” của Vercel cần thêm dấu hoa thị: được đo với tài nguyên không bằng nhau (2 vCPU/4 GB so với dùng chung/128 MB) và áp dụng mạnh nhất trên các workload đặc thù Next.js. Benchmark của Railway từ bên thứ ba cho thấy Workers vượt trội trên React SSR thông thường và tính toán nặng.

Lưu ý

Benchmark TTFB của OpenStatus cho cả hai nền tảng là từ đầu năm 2024. Phía Vercel đo sản phẩm Edge Functions đã bị ngừng hỗ trợ, không phải Fluid Compute. Độ trễ end-to-end của Vercel Fluid Compute chưa được benchmark độc lập với phạm vi tương đương tính đến giữa năm 2026.

Benchmark của Railway có trước khi Cloudflare tung ra GC tuning và tối ưu hóa OpenNext vào tháng 10 năm 2025. Hiệu năng CPU của Workers trên các workload thông thường đã cải thiện kể từ đó; một benchmark bên thứ ba được cập nhật sẽ rất hữu ích.

Không có Cloudflare hay Vercel nào có quan hệ affiliate với toolchew tại thời điểm viết bài. Trong brief nghiên cứu có ghi chú rằng database affiliate link không thể truy cập; nếu affiliate link được thêm vào trước khi xuất bản, cờ frontmatter affiliate và khối disclosure chuẩn phải được cập nhật trước khi bài lên live.