A client feature with a hard sub-100ms global latency requirement forced us to actually compare edge runtimes rather than defaulting to whichever platform already hosted the rest of the app. The feature itself, a real-time inventory check surfaced on a product page, needed to feel instantaneous regardless of whether the visitor was in the same region as our primary infrastructure or on the other side of the world.
Cloudflare Workers' broader global point-of-presence footprint showed a measurable latency edge for users far from major cloud regions, which mattered for this client's genuinely global user base rather than a mostly-domestic audience where the difference would have been academic. We measured response times from several international test locations, and the gap was real enough, tens of milliseconds in the regions furthest from major data centers, to matter for a feature explicitly built around perceived instantaneous response.
Vercel Edge Functions integrated more smoothly with the existing Next.js app and required far less new tooling knowledge for the team to maintain long-term. Deployment was effectively the same pipeline the team already used for the rest of the application, whereas the Cloudflare Workers option meant introducing a separate deployment target, a different runtime API surface for reading environment variables and handling requests, and a second thing for the team to keep in their heads during incident response.
We also weighed the two platforms' approaches to state and data access from the edge. Neither runtime supports arbitrary Node APIs, both run a more restricted JavaScript environment, so any code shared between the edge function and the rest of the app needed auditing for compatibility either way; that cost was roughly equal between the two options and didn't end up being the deciding factor.
We ended up on Vercel Edge Functions for this project since the integration cost outweighed Cloudflare's latency edge for the client's actual user distribution, which skewed more toward North America and Europe than the raw "global" framing initially suggested. For a more globally spread audience, especially one with meaningful traffic from regions underserved by major cloud provider regions, we'd lean the other way and accept the extra tooling overhead for the latency win. The honest lesson here is that "edge" isn't one thing; the right choice depends on where your actual users are, not just where you'd like them to be.
Debugging experience factored into the decision more than we initially expected it to. Vercel's integrated logging and function tracing, tied directly into the same dashboard the team already used for the rest of the deployment, made tracking down an intermittent issue during testing noticeably faster than the equivalent workflow on Cloudflare, where logs lived in a separate tool the team had to actively remember to check. That's not an inherent limitation of Cloudflare's platform, more a reflection of which tooling our team already had strong habits around, but it's a real, practical factor worth weighing alongside raw latency numbers.
Cost at the traffic volumes we were testing came out close enough between the two platforms that it didn't meaningfully influence the decision, though we'd revisit that comparison at a much higher request volume, since the two providers' pricing models diverge more noticeably as usage scales up. We're keeping notes from this evaluation on file specifically so the next latency-sensitive project doesn't have to redo the comparison from scratch, only re-check whether either platform's global footprint or pricing has shifted enough to change the answer.