Edge runtime vs Node.js: which wins, and when to use each

Edge runtime vs Node.js: which wins, and when to use each

Edge beats Node.js for most marketing sites and APIs. But it has limits. Pick the wrong runtime and you waste time and money.

What edge runtime is.

Edge runtime runs your code on a V8 isolate near the user. It starts in under 5ms, runs your function, and shuts down. There is no warm server.

Edge providers push your code to 200-plus regions. The user request hits the closest region. TTFB is sub-100ms in most places. For the rules behind going edge first, see why we build edge AI-first.

What Node.js is.

Node.js runs your code on a warm server in one place. It starts once and stays up for many requests. Cold start can be 1 to 5 seconds for big apps.

Node.js has the full Node API. That covers fs, Buffer, add-ons and child tasks. Most npm packages work as they are.

The edge runtime limits.

Limits we hit on client work:

No native Node modules. Sharp, sqlite and other add-ons. None of these work. No fs or Buffer APIs in the usual way. A 30-second cap on most platforms. Low CPU. Most requests get 50 to 200ms. Low memory. Most cap out at 128 MB. No long-held links. No WebSocket server.

Node.js limits.

Node.js gives you the full Node API and npm ecosystem, but every request hits the same server — which means TTFB varies with load. For teams deciding between edge and Node.js, our JavaScript SEO guide explains how render architecture affects what Googlebot and AI crawlers can index.

Higher TTFB. 200 to 500ms, or 1 to 5 seconds on cold start. Idle cost stays high. It runs all the time. One region, unless you add more. Slower reads from far away.

The decision.

Use edge for.

Marketing sites. Every page is a static or ISR render. Auth checks. JWT checks, rate limits, redirects. Simple APIs. Read-only CRUD, JSON-LD, OAuth callbacks. Features you can set at the edge. A/B tests, feature flags, redirects by country. Work that wants sub-100ms TTFB across the world.

Use Node.js for.

Image work. Sharp, resizing, format changes. File uploads. File parsing, virus scans, S3 uploads. Big JSON parsing. Payloads over 1 MB. Native modules. Work with C++ bindings. WebSocket servers. Long-lived links. Long jobs. Anything over 30 seconds.

Use both.

You can mix runtimes in one Next.js app. Middleware runs on edge by default. Pages and API routes each pick their own:

For an upload API, use runtime nodejs. For a health API, use runtime edge.

This is the pattern we use on most work. Edge for reads. Node.js for writes.

Common mistakes.

Putting heavy work on edge.

One client put a PDF maker on edge. It timed out at 30 seconds on big PDFs. We moved it to Node.js and it was fixed.

Putting simple APIs on Node.js.

One client put a JSON-LD endpoint on Node.js. It served 100 requests a second at 400ms TTFB. We moved it to edge and TTFB fell to 50ms. TTFB feeds straight into Core Web Vitals and your rank. See the Core Web Vitals 90-day plan for the Indian-side issues TTFB choices cause.

Forgetting the bundle size limit.

Edge functions have a 1 to 4 MB bundle limit. Pull in one heavy library and you hit it. Use imports that drop dead code to stay small.

Using native modules on edge.

Sharp, sqlite and bcrypt do not work on edge. If your route needs any of them, you must use Node.js.

What we use.

For our marketing site and most client sites: edge throughout. Sub-100ms TTFB across the world. The free tier covers most small sites.

For our analyzer endpoints: edge. The work is HTML parsing and JSON changes. Both are fast on edge.

For our internal tools and dashboard: Node.js. Heavy work, add-ons, long sessions.

The call is per route. We do not pick edge or Node.js for the whole app. We pick per route, based on the work it does. See our lessons from shipping 16 Next.js sites for how we use this in practice.