The pitch for Vercel’s Edge runtime is a V8 isolate close to the user with cold starts measured in milliseconds. That used to be a clean win over Node serverless — but two things changed by 2026. First, Vercel renamed and restructured the whole stack in mid-2025: “Edge Functions” and “Edge Middleware” are deprecated, replaced by Vercel Functions (which can use the Edge runtime) and Vercel Routing Middleware. Second, Fluid compute now keeps Node instances warm, so the old “Node cold start is 300-1500ms” argument barely holds. For a content site, that shifts the math hard toward static plus a thin slice of middleware. This article covers exactly where the Edge runtime still earns its keep, and where it costs more than it gives.
TL;DR
- For pure content pages, static still wins: a pre-rendered page from the CDN serves in roughly 20-40ms TTFB with zero function cost. Nothing below beats that.
- The Edge runtime is the right tool only for work that must run before the cache: geo-routing, language redirects, A/B bucketing, reading an auth cookie. That is what Routing Middleware is for.
- Since Fluid compute shipped (default on new projects since April 2025), Vercel reports zero cold starts on 99.37% of requests. The classic reason to “go Edge to dodge Node cold starts” is mostly gone.
- Watch the real limits (June 2026): Edge-runtime bundle 2 MB on Pro / 4 MB on Enterprise, request+response body 4.5 MB, Routing Middleware budgeted to ~50ms average CPU.
What actually changed in 2025-2026
If you are reading older tutorials, the names will not match the dashboard. As of the June 2025 platform update:
- Edge Functions → Vercel Functions (Edge runtime). Same V8-isolate runtime, but it is now one runtime option inside the unified Functions product, running after the cache.
- Edge Middleware → Vercel Routing Middleware. A first-class primitive that runs before the cache using Fluid compute, still on the Edge runtime by default, budgeted to about 50ms of CPU on average.
- Fluid compute is on by default for new projects. Instead of one micro-VM per request, instances are shared across concurrent invocations, and Pro/Enterprise plans keep at least one instance warm (“scale to one”). That is what drove cold starts down to under 1 in 100 requests.
The practical upshot: choosing “Edge vs Node” is no longer mostly about cold-start latency. It is about where in the request lifecycle the work runs (before vs after the cache) and what APIs you need (web-standard only vs full Node).
How to tell if you even need a function
- You hit a function on every page load and the work genuinely cannot be pre-rendered.
- You need geolocation, A/B testing, or an auth check before serving the page — not after.
- The work is small (under the 2 MB Edge bundle on Pro), pure JS, and needs no filesystem or native modules.
- You see Time-to-First-Byte spikes tied to a function, not to network distance you can fix with the CDN.
If none of these are true, you want static. Most article pages on a content site are static.
Quick verdict
If the work is “rewrite, redirect, geo-route, set a cookie, read a header” — Routing Middleware on the Edge runtime is right. If it is “render a page, generate an OG image, hit a database with a fat ORM” — a Node Vercel Function is the safer choice, and Fluid compute means its cold start rarely bites. For pure content, static beats both.
Where the Edge runtime actually wins
Three patterns where running before the cache, on the Edge runtime, meaningfully beats a Node function for a content site:
- Geo-aware language redirects in middleware. Routing
/to/en/or/zh/based onAccept-Languageor country code. This runs before the cache and adds roughly 20ms:
// middleware.ts — Vercel Routing Middleware
import { NextResponse, NextRequest } from 'next/server';
export const config = { matcher: ['/'] };
export function middleware(req: NextRequest) {
const country = req.geo?.country ?? 'US';
const lang = country === 'CN' || country === 'TW' ? 'zh' : 'en';
return NextResponse.redirect(new URL(`/${lang}/`, req.url));
}- A/B testing with cookie persistence. Bucket a user on first visit, set a cookie, keep them stable. The bucket decision must happen before the cache, so middleware is the right place:
// middleware.ts — bucket and rewrite to a variant
import { NextResponse, NextRequest } from 'next/server';
export const config = { matcher: ['/pricing'] };
export function middleware(req: NextRequest) {
const existing = req.cookies.get('ab-pricing')?.value;
const bucket = existing ?? (Math.random() < 0.5 ? 'a' : 'b');
const url = req.nextUrl.clone();
url.pathname = `/pricing-${bucket}`;
const res = NextResponse.rewrite(url);
if (!existing) {
res.cookies.set('ab-pricing', bucket, { maxAge: 60 * 60 * 24 * 30 });
}
return res;
}- Auth-gated content preview. Read a session cookie at the edge, rewrite drafts to the preview branch, and deny access without a round-trip to a Node origin. Keep it under the ~50ms CPU budget — a JWT check qualifies, a database lookup does not.
Real latency numbers worth knowing (June 2026)
Rough budget on Vercel, measured from iad1 (us-east-1) with a warm cache:
| Path | TTFB (warm) | Cold case |
|---|---|---|
| Static page from CDN | 20-40ms | n/a (no function) |
| Routing Middleware (Edge runtime) | +20-50ms before cache | ~80-150ms first hit in a cold region |
| Node Vercel Function (Fluid, warm) | 80-200ms | rare — under 1% of requests |
| Node Vercel Function (true cold) | — | 300-1000ms, mostly eliminated by scale-to-one on Pro/Enterprise |
Two things to internalize. First, middleware runs on every matched request before the cache, so its cost is additive on routes you would otherwise serve straight from the CDN — only match the paths that truly need it. Second, with Fluid compute keeping an instance warm, the old worst-case Node cold start is now an edge case on paid plans, which removes a big chunk of the historical reason to reach for the Edge runtime.
When a Node function is the right answer
- OG image generation with
@vercel/ogand custom fonts. It can run on the Edge runtime, but if you load assets from the filesystem or your bundle creeps past the 2 MB Edge limit, Node is cleaner. - API routes that hit Prisma, Drizzle, or any ORM without first-class Edge support. Most still want the Node runtime; with Fluid compute the cold-start penalty that used to push these to the edge is largely gone.
- Anything with a native dependency:
sharp,puppeteer,node-canvas. These do not run on the Edge runtime at all — Node only.
When neither is right — static wins
- Article pages whose content changes on a known schedule. Pre-render at build, use ISR or on-demand revalidation for updates, and skip the function entirely.
- Sitemap and robots. Generate at build, serve from the CDN, zero function invocations.
- Search and filter UIs where the dataset fits in a JSON file under ~200 KB. Ship it with the page and filter client-side.
For a typical bilingual content site, that covers the overwhelming majority of routes. The only persistent function is usually a single middleware doing language routing.
Common mistakes
- Putting article pages behind a function “for personalization.” This kills CDN caching and adds latency to every request. Personalize client-side or with a thin middleware rewrite instead.
- Importing a Node-only module into an Edge route and finding out at deploy time. Set the Edge runtime in local dev too so the failure surfaces early.
- Forgetting middleware runs even on a 304. Routing Middleware executes before the cache, so it counts toward usage on matched requests regardless of whether the body is re-sent.
- Reading a centralized database from the edge. The function is fast, but the DB round-trip from random regions is not. Use a globally replicated store (Upstash, a PlanetScale-style edge driver) or pre-render the data.
- Assuming the old 1 MB middleware limit. The Edge-runtime bundle limit is now 2 MB on Pro and 4 MB on Enterprise (June 2026). If fonts push you past it, move OG work to a Node function.
Cost note
On the Pro plan ($20/seat/month as of June 2026), Vercel bills functions on active CPU time and provisioned memory time, not wall-clock — waiting on I/O like a database or AI call does not count. The included tier covers a lot for a content site, but middleware on a high-traffic route burns Edge Requests on every hit, so scope your matcher tightly. The Hobby plan is free but non-commercial, so a monetized content site needs Pro.
FAQ
- Did Vercel really deprecate Edge Functions?: The names did. As of the mid-2025 platform update, “Edge Functions” and “Edge Middleware” are deprecated and replaced by Vercel Functions (which can run the Edge runtime) and Vercel Routing Middleware. The Edge runtime itself is alive and used by middleware by default.
- With Fluid compute, do I still need the Edge runtime to avoid cold starts?: Usually no. Vercel reports zero cold starts on about 99.37% of requests with Fluid compute, so cold-start avoidance is no longer the main reason to choose the edge. Choose it for running before the cache (geo, A/B, auth), not for raw latency.
- What is the current Edge-runtime bundle size limit?: 2 MB on Pro and 4 MB on Enterprise as of June 2026, including code, libraries, and bundled assets like fonts. Node functions allow up to 250 MB uncompressed.
- What APIs are available on the Edge runtime?: Web-standard APIs (fetch, Request, Response, crypto.subtle, streams). No
fs, no native modules, limitedBuffer. For full Node coverage, use a Node Vercel Function. - Does Astro support the Edge runtime?: The
@astrojs/verceladapter exposes an edge option, but most Astro content sites are static and never need it. Ship static, add one middleware only if you need pre-cache routing. - Will moving to the edge improve my Lighthouse score?: Only if TTFB was bottlenecked on a function cold start — which Fluid compute mostly removes. A static page with good cache headers already wins on Lighthouse.