Edge Computing for Your Own Site: Cloudflare Workers and Vercel Edge Use Cases and Performance
1. What edge computing actually is, and how it relates to CDN
A traditional CDN only caches static files and returns the cached copy when a request comes in. Edge computing runs a small piece of JavaScript on the CDN node, so it can make logic decisions before returning the response: route users to different pages based on location, pick which version to show based on a cookie, verify whether a JWT is valid. That logic runs on a node a few dozen milliseconds from the user, with no trip back to the origin.
How it differs from server-side rendering (SSR): SSR runs on your own server, so users worldwide cross oceans to reach that one machine. Edge functions run simultaneously on 300+ nodes worldwide, so each user connects to the nearest one. For a cross-border B2B site, that distance is the difference between a 100 ms and an 800 ms TTFB. For how CDN and edge fit together, see CDN global acceleration.
A counterintuitive rule: edge computing isn’t a faster server, it’s a smaller one. Every edge function has a hard CPU time cap and can’t handle heavy computation. Move a 200 ms database query to the edge and it will run more than 3x slower than on your origin, because the edge node sits farther from the database.
| Execution environment | Where it runs | CPU time cap | Cold Start | Database access | Cost model |
|---|---|---|---|---|---|
| Traditional server (VPS) | Single data center | No hard limit | None (always on) | Local/intranet, fast | Monthly flat fee |
| Cloudflare Workers | 300+ nodes worldwide | 10 ms free/30 ms paid | Near zero (V8 isolates) | Must connect to an external database, slow | Billed per request |
| Vercel Edge Functions | 25+ nodes worldwide | Up to 30 seconds | 10 to 50 ms | Supports Edge DB | Billed per invocation duration |
| AWS Lambda@Edge | CloudFront nodes worldwide | Up to 5 seconds | 10 to 100 ms | Must reach RDS over the public internet | Per request + duration |
2. Three scenarios where edge computing is actually worth it
Scenario 1: Redirect by location and language. On a site going global, German visitors land on the /de/ German version automatically, Middle East visitors on the /ar/ Arabic version. The traditional way is to read an IP database on the server and decide, which means every request goes back to the origin. With Cloudflare Workers you can write 10 lines of code to return a 301 at the edge based on IP country, cutting TTFB from 400 ms to 50 ms. For how to set up hreflang on a multilingual site, see Hreflang for multilingual sites.
Scenario 2: A/B test splitting. Say you want two versions of your homepage, with 50% of users seeing version A and 50% seeing version B. The traditional way is to read a cookie on the server and decide which version to render. The edge approach is simpler: Workers hash the cookie and either rewrite asset paths in the HTML or inject different variables, with the origin completely unaware. The split itself takes under 10 ms and doesn’t affect TTFB.
Scenario 3: Lightweight auth and bot blocking. For requests sent after a user logs in, validate the JWT at the edge first. If it’s invalid, return 401 without hitting the origin. That way the origin only handles legitimate requests, saving both bandwidth and CPU. Bot blocking works at the edge too: if a suspicious user agent or an unusually high request rate is detected, return a challenge page and keep the request away from the origin.
| Scenario | How it works at the edge | Performance gain | Development effort | Suggested priority |
|---|---|---|---|---|
| Geo redirect | Workers read request.cf.country | TTFB down 50 to 150 ms | Half a day | High |
| A/B test splitting | Workers split by cookie hash | No added TTFB | 1 to 2 days | Medium |
| JWT auth at the edge | Validate token at the edge, reject invalid ones | Origin load down 20% to 40% | 2 days | High |
| Bot blocking / rate limiting | Detect user agent and rate at the edge | Malicious requests never reach the origin | 1 day | High |
| Personalized page rendering | Assemble HTML fragments at the edge | Only works for repeated fragments | 3 to 5 days | Low |
Three: two pitfalls to avoid with edge computing
Pitfall 1: Moving database queries to the edge. Many people think “edge computing is advanced” and move their user center’s query logic up there too. The result: the edge node connects to a remote database, and a single query’s network round trip takes 200 ms, five times slower than a local query at the origin. Edge functions are good for logic that is “stateless, light on compute, and cache-driven” — not for logic that “needs to query a database.”
Pitfall 2: Moving all of SSR to the edge. Next.js’s Edge Runtime mode can indeed run React rendering on Vercel edge nodes, but rendering a complex page can take over 100 ms of CPU time, hitting free-tier limits, or cold starts can make first-time visitors wait an extra 50 ms. Complex server-side rendering should still run at the origin, with the edge handling only a lightweight middle layer. For how to manage third-party scripts, see Managing third-party scripts.
Real-world example: a SaaS product going global needed its user dashboard to query a database and render. The team excitedly rewrote the page with Vercel Edge Runtime, only to find that edge nodes were 80ms away from their AWS RDS database. Add rendering time, and TTFB actually rose from 250ms to 450ms. They moved the dashboard back to the origin server and left only login validation and routing at the edge. TTFB dropped back to 250ms.
| Pitfall | The apparent benefit | What actually happens | The right way |
|---|---|---|---|
| Move database queries to the edge | “Closer to users” | Edge-to-DB network is far, latency rises 3-5x | Keep DB queries at origin, edge only handles cache reads |
| Run full-site SSR at the edge | “Global acceleration” | CPU limits and slow cold starts actually increase TTFB | Edge as middleware only, rendering stays at origin |
| Heavy file read/write | “Local processing” | No persistent disk at the edge, limited memory | Route file operations through object storage APIs |
| Long-running compute tasks | “Parallel is faster” | CPU timeout triggers error 1102 | Split into smaller tasks or use a message queue |
4. Cost and platform choice: Cloudflare Workers vs Vercel Edge
Cloudflare Workers and Vercel Edge Functions are the two most common edge platforms for independent stores today. Your choice mainly depends on your tech stack and traffic volume. Cloudflare Workers runs on V8 isolates with near-zero cold starts and offers 100,000 free requests per day, making it ideal for lightweight routing and authentication. Vercel Edge Functions integrate deeply with Next.js. If you already use Next.js, migration cost is lowest, but cold starts are slower than Workers.
On cost, Cloudflare’s paid plan starts at $5/month and includes 10 million requests; Vercel Pro starts at $20/month, with edge functions billed by execution time, so bills can spike quickly as traffic grows. For small and mid-sized B2B independent stores with under 100,000 monthly page views, Cloudflare’s free plan is basically enough. For how to monitor performance, see Site monitoring and alerts.
| Dimension | Cloudflare Workers | Vercel Edge Functions | AWS Lambda@Edge |
|---|---|---|---|
| Cold Start | Near zero (V8) | 10 to 50 ms | 10 to 100 ms |
| Free tier | 100,000 requests/day | 100GB-hours/month | 1 million requests/month |
| Paid plan starts at | $5/month | $20/month | Usage-based, no flat monthly fee |
| Development language | JavaScript/TypeScript | JavaScript/TypeScript | Node.js/Python |
| Best for frameworks | Pure functions/middleware | Deep Next.js integration | AWS ecosystem sites |
| Node coverage | 300+ cities | 25+ countries | CloudFront global |
FAQ
Is Cloudflare Workers’ free plan really enough?
How do edge functions relate to CDN caching?
Vercel Edge Functions vs Cloudflare Workers: which is faster?
Can edge functions help with SEO?
How do you roll back when an edge function breaks?
When does edge computing not make your site faster?
Final thoughts
Edge computing is a small, targeted optimization, not a full-site architecture revolution. It solves one specific bottleneck: every request having to go back to the origin. It’s good for lightweight routing, authentication, and traffic splitting. If you go in expecting the edge to make your whole site twice as fast, you’ll probably be disappointed, because most slowness comes from database queries and third-party scripts, not network distance.
Start with the smallest possible use case: use Cloudflare Workers to set up a geo redirect that sends German users to the German-language page. You can ship this in half a day, the performance gain is immediate, and the risk is minimal. Once it has run smoothly for two weeks, consider adding A/B routing or edge authentication. Don’t try to move your entire site to the edge on day one.
Here’s a line worth remembering: edge computing is the delivery station closest to your users, not the warehouse closest to your database — let it handle the sorting, but don’t move the warehouse work there too.