The short answer
Cloudflare sells you a network; Vercel sells you a workflow. If your team is comfortable operating closer to the platform — Workers, adapters, wrangler configuration — Cloudflare’s economics are hard to beat: bandwidth is effectively free, compute is priced per request, and you’re building on one of the largest networks in the world. If what you’re buying is velocity — first-party Next.js machinery and preview deployments as the stakeholder review process — Vercel earns its premium. The choice is less about capability than about where you want to spend: engineering time or platform fees.
One thing to know before you compare: “Cloudflare Pages” is no longer the product to evaluate. Cloudflare has consolidated static hosting into the Workers platform — static assets are served by Workers directly, and Workers is where Cloudflare’s investment and roadmap live. Treat Cloudflare hosting as Workers with static assets, and read older Pages-era comparisons accordingly.
Where they differ
| Cloudflare | Vercel | |
|---|---|---|
| Model | A network you build on: CDN, Workers runtime, storage primitives (KV, R2, D1, Durable Objects) | A platform you deploy to: builds, delivery, compute, and framework machinery handled for you |
| Framework support | Framework-agnostic via adapters; Next.js runs through the community-driven OpenNext adapter, which trails first-party support | First-party Next.js — ISR, RSC, image optimisation on release day; strong Astro, Nuxt, SvelteKit support |
| Compute | Workers: V8 isolates with near-zero cold starts, running at the edge by default, priced per request | Fluid Compute: serverless and edge unified, scales to zero, usage-billed |
| Bandwidth & pricing shape | Workers Paid starts at $5 per account per month, then usage; no egress charges for standard delivery | Pro combines developer-seat pricing with metered bandwidth, image optimisation, and compute |
| Pay per user | No for Workers. Billing is account-level plus usage, not per member | Yes for developers. Pro is $20 per developer per month; viewer seats are unlimited and free |
| Preview workflow | Preview deployments exist, but the review-and-comment workflow around them is thinner | Preview deployments per branch/PR with collaboration tooling built around stakeholder sign-off |
| Operational ownership | Your team owns more configuration and platform decisions (routing, caching, adapters) | The platform owns the defaults; less to configure, less to tune, less to get wrong |
| Governance & compliance | Enterprise contracts, SSO, audit logging, and a mature security portfolio (WAF, DDoS, bot management) on the same network | Enterprise tier: SOC 2, SSO/SAML, audit logs, EU regions, contractual SLAs |
| Lock-in & portability | Workers code targets Cloudflare's runtime and storage APIs — portable in logic, not in platform bindings | Standard framework code ports; platform config and ISR/image behaviour need rework elsewhere |
Global CDN Performance
Response times measured from 15 global locations for static content delivery (HTML, images, and other assets). These measurements reflect how quickly content reaches users through each provider's CDN.
| Location |  Cloudflare |  Vercel | ||
|---|---|---|---|---|
| TTFB | Total Load Time | TTFB | Total Load Time | |
 us-west-1 | 93ms | 105ms | 53ms | 59ms |
| us-east-1 | 168ms | 225ms | 29ms | 40ms |
 ca-central-1 | 40ms | 49ms | 31ms | 33ms |
 sa-east-1 | 85ms | 116ms | 34ms | 43ms |
 eu-central-1 | 72ms | 85ms | 27ms | 33ms |
 eu-west-2 | 59ms | 77ms | 30ms | 39ms |
 eu-west-3 | 58ms | 68ms | 27ms | 31ms |
 eu-north-1 | 66ms | 86ms | 40ms | 45ms |
 eu-south-1 | 47ms | 81ms | 52ms | 54ms |
 af-south-1 | 79ms | 175ms | 26ms | 29ms |
 ap-southeast-1 | 105ms | 117ms | 29ms | 32ms |
 ap-northeast-1 | 92ms | 104ms | 34ms | 38ms |
 ap-east-1 | 123ms | 149ms | 28ms | 31ms |
 ap-southeast-2 | 79ms | 88ms | 29ms | 32ms |
 ap-northeast-2 | 110ms | 122ms | 32ms | 35ms |
What the measurements show
In this 9 August 2026 snapshot, Vercel recorded the lower median CDN TTFB across the 15 monitored locations: 30ms versus 79ms for Cloudflare. It returned the faster TTFB in 14 of 15 locations; median total load time was 35ms versus 104ms.
Method: Checkly requests the test endpoints from 15 locations every 60 minutes; the table reports averages from recent checks. Lower is better. These results describe the monitored endpoints, not every project or workload—application code, cache state, region configuration, and traffic patterns can change production performance.
Serverless Node.js Function Performance
Serverless Functions (Node) timings measure the performance of backend operations executed in serverless environments.
Note
We test endpoints every 60 minutes, so these measurements predominantly capture cold-start performance. This represents a worst-case scenario; production applications with more frequent requests often keep functions warm.
| Location | Cloudflare | Vercel | ||
|---|---|---|---|---|
| TTFB | E2E Latency | TTFB | E2E Latency | |
| us-west-1 | N/A | N/A | 44ms | 56ms |
| us-east-1 | N/A | N/A | 22ms | 33ms |
| ca-central-1 | N/A | N/A | 15ms | 16ms |
| sa-east-1 | N/A | N/A | 22ms | 28ms |
| eu-central-1 | N/A | N/A | 17ms | 22ms |
| eu-west-2 | N/A | N/A | 17ms | 29ms |
| eu-west-3 | N/A | N/A | 16ms | 18ms |
| eu-north-1 | N/A | N/A | 29ms | 33ms |
| eu-south-1 | N/A | N/A | 45ms | 48ms |
| af-south-1 | N/A | N/A | 16ms | 18ms |
| ap-southeast-1 | N/A | N/A | 17ms | 21ms |
| ap-northeast-1 | N/A | N/A | 22ms | 26ms |
| ap-east-1 | N/A | N/A | 15ms | 17ms |
| ap-southeast-2 | N/A | N/A | 15ms | 18ms |
| ap-northeast-2 | N/A | N/A | 32ms | 35ms |
What the measurements show
A direct Node.js comparison is not available in this 9 August 2026 snapshot. Vercel's median TTFB across the 15 monitored locations was 17ms, while Cloudflare has no comparable Node.js endpoint: Cloudflare runs this workload in its edge runtime rather than a Node.js serverless function, so there is no like-for-like Node.js endpoint in this benchmark.
Method: Checkly requests the test endpoints from 15 locations every 60 minutes; the table reports averages from recent checks. Lower is better. These results describe the monitored endpoints, not every project or workload—application code, cache state, region configuration, and traffic patterns can change production performance.
Choose Cloudflare when
- Traffic is high and bandwidth is a real line item — the no-egress-metering model changes the economics at scale.
- You have engineering ownership: a team happy to run adapters, wrangler config, and edge logic as part of the job.
- You’re already on Cloudflare for DNS, CDN, or security, and consolidating onto one vendor simplifies procurement.
- Your dynamic needs fit the Workers model — personalisation, redirects, A/B logic at the edge rather than heavy server rendering.
Choose Vercel when
- The estate is Next.js and you want framework features working as designed without adapter lag.
- Preview-driven review is how your marketing organisation ships — sign-off on real URLs, many contributors, weekly campaign pages.
- You’d rather pay the platform than staff the platform: fewer infrastructure decisions owned in-house.
If you’re switching
Moving from Vercel to Cloudflare (usually chasing the economics) means adopting the adapter path for Next.js — test ISR, image optimisation, and middleware behaviour early, because they’re the areas where first-party and adapter support diverge — and rebuilding redirects and caching rules in Cloudflare’s model. Moving from Cloudflare to Vercel (usually chasing the workflow) means untangling any Workers-specific bindings — KV, Durable Objects, HTMLRewriter logic — into portable code or Vercel equivalents. In both directions: map every redirect, re-model the bill under the other pricing shape, and run the two in parallel long enough to compare real traffic before cutting over.
The Bejamas take
We deploy to both, and the pattern is consistent: Cloudflare wins where there’s engineering ownership and traffic scale; Vercel wins where the workflow is the product and the team’s time is the scarce resource. They also coexist well — Cloudflare in front for DNS and security, Vercel behind it for the application — which is often the answer for organisations already contracted with Cloudflare. In an audit we model your traffic, team, and compliance requirements against both — and against your own cloud — and recommend the split the numbers support.