Edge rendering, honestly

The edge is sold as a speed setting: move your rendering closer to users and everything gets faster. Sometimes that is true. Often it makes things measurably slower, and the reason is not subtle once you look at where the data lives.

The edge removes network distance. That is the whole benefit. Whether removing distance helps depends entirely on how much of your work needs something that is still far away.

Do the latency arithmetic

Rendering in a city near your user saves perhaps 100–200ms of round trip. Real, and worth having. But if that render then makes three sequential queries to a database in one region, you have moved the compute away from the data and added a fresh round trip to each call. Three times eighty milliseconds, gained back — and then some.

Moving compute closer to the user moves it further from your data. Only one of those distances is usually the bottleneck.

The question is never "should this run at the edge". It is "how many times does this request need to talk to something that lives in one place".

What genuinely belongs there

Work that needs the request but not your database is where the edge is unambiguously the right tool — it runs in single-digit milliseconds and never touches your origin at all.

• Redirects and rewrites: locale routing, legacy URLs, canonical host enforcement.
• Auth gates: verify a signed token and bounce the request before it costs you anything.
• Experiment assignment: hash the visitor into a bucket, set the cookie, carry on.
• Geo and device shaping: currency, language, coarse layout hints.
• Cache orchestration: stale-while-revalidate around content that is nearly static.

// Cheap at the edge: no origin, no database, no round trip.
export function middleware(req: Request) {
  const country = req.headers.get("x-vercel-ip-country") ?? "GB"
  const session = req.headers.get("cookie")

  if (!session && isPrivate(req.url))
    return Response.redirect("/login", 302)

  return rewriteForRegion(req, country)
}

What gets slower

Anything chatty with your primary database. A dashboard that joins across six tables belongs next to those tables, in one region, where the queries are cheap and the connection is warm. Put it at the edge and you have distributed the slowest part of the request instead of the fastest.

Connection handling is the second trap. Edge runtimes are many small, short-lived isolates, which is precisely the access pattern traditional connection pools handle worst. It is solvable — poolers, HTTP-based drivers, regional functions for the data-heavy routes — but it is a cost to plan for, not a detail to discover in production.

How we actually decide

Per route, not per application. Most products we build end up mixed: middleware and static content at the edge, data-heavy pages rendered in the region where the database lives, and a cache policy chosen deliberately for each. That is not a compromise, it is just matching the tool to the work.

And it stays honest for the same reason everything else does — the routes carry budgets, and the budgets run in CI, exactly as in performance budgets that actually hold. If moving a route to the edge made it slower, the build says so before a user does.

The edge is a good tool with a narrow, valuable job. It is worth using for that job, and worth not using for the rest.