What edge rendering actually is
Edge rendering moves your compute out of a single region and onto a geo-distributed fleet of points of presence. Instead of a request from Melbourne travelling to a US-East server and back, it hits a node a few hundred kilometres away, runs there, and returns a response in tens of milliseconds.
Sold like that, it sounds like a no-brainer. In practice, every edge platform has a list of constraints long enough that we have talked plenty of clients out of using it. This post is the conversation we tend to have.
Why TTFB matters
Time to First Byte is the hinge that most of the user-perceived performance story turns on. A slow TTFB delays every subsequent metric: FCP, LCP, interactivity, the lot. Google cares, users care, and a 400ms TTFB from a single US-East origin looks a lot worse to a Sydney user than to a New York one.
Edge rendering fixes that. Sub-50ms TTFB from anywhere in the world is achievable when the work being done is light: auth checks, redirects, geo-personalisation, A/B test bucketing, lightweight HTML transformations.
The three main stacks
Vercel Edge
Tight integration with Next.js, good developer experience, runs on top of Cloudflare infrastructure. You mark a route or a middleware function as edge-runtime and Vercel handles the rest. The catch is the runtime is Web Standard APIs only, not Node.js, which shows up the first time you try to import a library that assumes fs or crypto the Node way.
Cloudflare Workers
The most mature and cheapest edge platform, and the most capable if you commit to it. Workers give you KV, R2, D1, Durable Objects, Queues and the rest of the Cloudflare developer platform in one ecosystem. It is Web Standard APIs plus Cloudflare-specific bindings, and it scales a long way before you hit meaningful bills.
Netlify Edge
Powered by Deno, deployed on Netlify's edge network. Clean ergonomics, solid for personalisation and A/B testing, a smaller ecosystem than Cloudflare but easier to reason about than Vercel if you are not already Next.js-native.
All three cold-start fast. All three charge on request count and CPU time rather than instance hours.
The limitations nobody leads with
No Node runtime
Edge runtimes run Web Standard APIs. Any library that relies on Node internals will not work. That rules out chunks of the npm ecosystem, including some ORMs, PDF generators, and server-side rendering libraries written for pure Node.
Cold starts are smaller but not zero
Edge cold starts are milliseconds, not seconds. But if your worker pulls in a large bundle, the first request to a cold region can still add measurable latency.
Database latency dominates
This is the big one. Your function runs in Sydney, lovely. Your Postgres lives in us-east-1. Every query is a 200ms round trip, twice, and suddenly your sub-50ms edge response is a 500ms request. Edge rendering only pays off if the data is also at the edge (KV, D1, Durable Objects, a distributed database like Turso or PlanetScale's edge reads) or if you can render without hitting the database at all.
Bundle size limits
Cloudflare Workers has a 1MB compressed bundle limit on the paid plan and smaller on free. Vercel and Netlify have their own limits. You cannot drop a big React app into an edge worker and hope.
When the complexity pays off
Edge rendering earns its keep when three things are true: your users are geographically spread, your personalisation needs to run on every request, and your data is either already at the edge or can be cached aggressively.
Concrete cases we have shipped:
- Geo-aware redirects and content for global sites where a visitor in Singapore should see different pricing to a visitor in Germany, and both should get it without a client-side flicker.
- A/B test bucketing at the edge so the first byte already reflects the variant. No flash of wrong content, no Optimize-style render delay.
- Auth-gated marketing where a signed-in user sees a personalised hero on a page that is otherwise statically cached.
- Header-based routing for things like multi-tenant SaaS where the tenant is in a subdomain and needs to rewrite to a shared app.
When it is overkill
Most marketing sites do not need edge rendering. A good CDN in front of static HTML already gives you fast responses worldwide, because the CDN is doing exactly the geo-distribution job you would be reaching for.
If your site is content-driven, updates daily not per-request, and does not personalise, SSG plus a proper CDN beats edge rendering on complexity, cost and reliability. Edge rendering adds moving parts. Static files on a CDN have almost none.
Practical patterns that work
A pattern we like is static-by-default with an edge layer for the bits that need it. The page renders statically. A thin edge middleware handles auth, geo, or A/B bucketing and sets a header or rewrites the URL. The static page reads that header and adjusts. You get edge speed on the decisions that matter without pushing the whole render out there.
// Vercel Edge Middleware example
import { NextResponse } from "next/server";
export const config = { matcher: "/" };
export function middleware(req) {
const country = req.geo?.country ?? "AU";
const res = NextResponse.next();
res.headers.set("x-country", country);
return res;
}
The static page then keys off x-country to swap the currency strip without leaving the edge.
Observability and debugging
One unsung cost of edge rendering is operational. A traditional Node server is easy to log into, easy to profile, easy to attach a debugger to. An edge runtime is a distributed compute fleet, and a bug that only triggers in one region at one time of day is a different debugging experience altogether.
Every platform ships logging and tracing, but you should plan for it on day one. Set up structured logs, forward them to a log aggregator you already use, and make sure you can filter by region and by request ID. Cloudflare has Workers Logs and Tail Workers. Vercel has its logs pipeline and Observability dashboard. Netlify surfaces function logs through the UI and their CLI. The platforms are not the problem. Teams that skip the observability setup are.
How we decide
We reach for edge rendering when we need per-request logic to be fast globally, and the data for that logic lives somewhere the edge can reach. We avoid it when the project is content-driven and a CDN would do the same job for half the operational cost.
If you are weighing up an edge migration, or wondering whether your current stack would benefit, we are happy to sanity-check the architecture before you commit.
