All Docs
FeaturesDepositClearUpdated March 12, 2026

Edge Runtime Performance — PERF-21

Edge Runtime Performance — PERF-21

Status: Recommendation / Pending Implementation
Introduced in: v0.1.208
Category: Performance · Build & Deploy

What Is the Edge Runtime?

Vercel's edge runtime executes JavaScript closer to the end user at the CDN layer, rather than in a centralised Node.js server region. This results in:

  • Lower cold start times — edge functions start in microseconds vs. hundreds of milliseconds for Node.js serverless functions.
  • Reduced auth overhead — session checks run at the edge before a request ever reaches the origin.
  • Global low-latency — requests are handled by the nearest edge node rather than a single fixed region.

The trade-off is a restricted API surface: Node.js-specific built-ins are not available, and some third-party libraries are not edge-compatible.

Current State

As of v0.1.208, no routes or middleware in the application declare export const runtime = 'edge'. All server-side execution runs on the default Node.js runtime.

The audit identified the following candidates for edge migration:

1. Middleware (src/middleware.ts) — Highest Priority

The Next.js middleware intercepts every authenticated request and is the single highest-impact candidate. Auth.js v5 beta supports edge-compatible session checks via the JWT strategy.

Recommended action:

// src/middleware.ts
export const runtime = 'edge';

Pre-condition: Confirm the Auth.js adapter is configured for JWT (not database) sessions. The edge runtime cannot use a database-backed session strategy because TCP-based database connections are not supported at the edge.

2. Redirect-Only Routes

Routes that perform a simple HTTP redirect with no business logic have no runtime dependencies. These are safe to move to edge immediately once identified.

// Example: a redirect route
export const runtime = 'edge';

export function GET() {
  return Response.redirect('https://example.com', 301);
}

3. Token-Validation & Health Check Endpoints

Lightweight endpoints that only inspect a request header or return a static response are strong edge candidates.

export const runtime = 'edge';

export async function GET(request: Request) {
  const token = request.headers.get('Authorization');
  if (!token) return new Response('Unauthorized', { status: 401 });
  // lightweight validation only — no DB call
  return new Response('OK', { status: 200 });
}

4. Database-Backed API Routes

Routes that query the database are conditionally compatible. The Neon HTTP driver communicates over HTTP rather than a persistent TCP connection, making it compatible with the edge runtime.

import { neon } from '@neondatabase/serverless';

export const runtime = 'edge';

export async function GET() {
  const sql = neon(process.env.DATABASE_URL!);
  const result = await sql`SELECT 1`;
  return Response.json(result);
}

⚠️ Standard Postgres clients (e.g. pg, postgres.js in TCP mode) will not work on the edge runtime. Ensure the Neon HTTP/WebSocket driver is used.

Migration Checklist

Before adding export const runtime = 'edge' to any route:

  • No Node.js built-in modules used (fs, path, crypto, buffer, etc.)
  • No TCP-based database client used — Neon HTTP driver in place
  • Auth.js configured with JWT session strategy (not database sessions)
  • All imported libraries are edge-compatible (check the Edge Runtime compatibility table)
  • Route tested locally with next dev and verified in a Vercel preview deployment

Expected Impact

MetricBefore (Node.js)After (Edge)
Middleware cold start~200–400 ms~5–50 ms
Auth check latency (global users)Origin-region RTTNearest edge node RTT
Redirect route latency~100–200 ms~5–20 ms

Estimates based on typical Vercel serverless vs. edge benchmarks. Actual values depend on deployment region and payload size.

Related