What Is Edge Rendering and Why Frontend Developers Should Care
Your server is in Virginia. Your user is in Jakarta. Every millisecond between them is a problem you can solve — if you know where to run your code.
Loading articles...
ZextOverseZextOverseLoading articles...
Your server is in Virginia. Your user is in Jakarta. Every millisecond between them is a problem you can solve — if you know where to run your code.
For most of the web's history, the server was a single place. A physical machine (or a cluster pretending to be one) sitting in a data center somewhere, waiting for requests to travel to it across the planet and then sending responses back the same way.
We got good at optimizing this model. CDNs cached static assets at the edge. Load balancers distributed traffic. We gzipped payloads and deferred scripts and lazy-loaded images. But fundamentally, the logic — the thing that decides what HTML to send — lived in one place.
Edge rendering breaks that assumption. It asks: what if the code that generates your page ran not in a single origin data center, but simultaneously across dozens or hundreds of locations worldwide, milliseconds away from wherever your user happens to be?
That's not a rhetorical question anymore. It's a production reality — and it's reshaping how frontend developers think about the rendering pipeline.
Before edge rendering makes sense, the alternatives need to be clear. Modern web applications have accumulated a surprisingly large vocabulary of rendering strategies, and edge rendering is most easily understood in contrast to them.
HTML is generated at build time and served as a flat file. Fast everywhere because CDNs are trivially good at serving static files. The limitation: content is frozen at deploy time. Updating a single product price requires rebuilding and redeploying the entire site.
HTML is generated on-demand, on the server, for each request. Content is always fresh. The limitation: every request travels to the origin server, pays full round-trip latency, and executes compute. Scale this to millions of users and the cost — both in latency and in compute bills — compounds quickly.
The server sends a minimal HTML shell; the browser downloads JavaScript, executes it, fetches data, and constructs the page. The limitation: the user stares at a blank screen (or a spinner) until all of that completes. Core Web Vitals suffer. SEO is complicated.
A hybrid: pages are statically generated but can be revalidated and regenerated at configurable intervals. Better than pure SSG for frequently-updating content, but still origin-bound for the regeneration compute.
HTML is generated on-demand, per request — like SSR — but the code runs at the edge: on servers physically close to the user, distributed globally. You get the freshness of SSR with latency characteristics approaching static delivery.
"Edge" is a spatial metaphor. The center of the network is the origin — your application servers, your databases, your APIs. The edge is the periphery: CDN nodes, Points of Presence (PoPs), infrastructure physically distributed across regions.
Traditional CDNs used the edge for one thing: caching. They were very fast file servers, not compute environments. The innovation behind edge rendering is that modern edge networks — Cloudflare Workers, Vercel Edge Runtime, Fastly Compute, Deno Deploy, AWS Lambda@Edge — have made it possible to run actual code at those PoPs, not just serve cached files.
This code runs in a constrained environment. Edge runtimes are typically:
fs, no child_process, limited native modules.Traditional SSR:
User (Jakarta) ──────────────────────────► Origin (Virginia)
~200ms RTT ▼
Generate HTML
User (Jakarta) ◄────────────────────────── Origin (Virginia)
~200ms RTT
Edge Rendering:
User (Jakarta) ──────► Edge Node (Singapore)
~8ms RTT ▼
Generate HTML
User (Jakarta) ◄────── Edge Node (Singapore)
~8ms RTT
The numbers are illustrative, but the principle is real. A round trip to a nearby edge node can be 10–30× faster than a round trip to a distant origin.
Let's ground this in something concrete. Suppose you're building an e-commerce product page in Next.js.
With traditional SSR using getServerSideProps, every request hits your origin:
// pages/products/[slug].tsx — traditional SSR
export async function getServerSideProps(context) {
const product = await fetchProductFromDatabase(context.params.slug);
const user = await getSessionUser(context.req.cookies);
return {
props: { product, user }
};
}
This works, but every request for /products/running-shoes from a user in São Paulo travels to your servers in Frankfurt, waits for your database query, and travels back. You're paying full geographic latency on every page view.
With edge rendering in Next.js (App Router), you opt a route into edge execution:
// app/products/[slug]/page.tsx — edge rendering
export const runtime = 'edge';
export default async function ProductPage({ params }) {
// This runs at the edge node closest to the user
const product = await fetch(`https://api.example.com/products/${params.slug}`, {
next: { revalidate: 60 } // Cache for 60 seconds at the edge
}).then(r => r.json());
return <ProductView product={product} />;
}
The HTML generation now happens at the PoP nearest your user. The edge function fetches product data from your origin API (that network hop is still there, but it's a backend-to-backend connection over fast infrastructure, not a user-facing round trip), renders the React component to HTML, and sends it back — all before the request would have even reached your origin in the traditional model.
TTFB is the latency between a browser making an HTTP request and receiving the first byte of the response. It's one of the most direct measures of server performance and directly impacts Largest Contentful Paint (LCP), a Core Web Vitals metric.
Edge rendering consistently improves TTFB for globally distributed audiences because the network round trip is shorter. Users in regions historically underserved by data centers — Southeast Asia, Latin America, sub-Saharan Africa — see the most dramatic improvements.
This is one of edge rendering's most powerful use cases. Pure SSG is fast but can't personalize. Pure SSR can personalize but is slow. Edge rendering can do both.
A common pattern: serve a cached static "shell" for anonymous users from the CDN, and use edge middleware to inject personalized content (user-specific pricing, localized copy, A/B test variants) without hitting the origin.
// middleware.ts — runs at the edge before every request
import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';
export function middleware(request: NextRequest) {
const response = NextResponse.next();
// Detect locale from Accept-Language header — at the edge
const locale = detectLocale(request.headers.get('accept-language'));
response.headers.set('x-locale', locale);
// A/B test assignment — at the edge, without origin roundtrip
if (!request.cookies.get('ab-variant')) {
const variant = Math.random() > 0.5 ? 'a' : 'b';
response.cookies.set('ab-variant', variant);
}
return response;
}
When edge nodes handle rendering, the origin server's job shifts from "generate every page for every user" to "respond to API calls from edge functions." This is a fundamentally different traffic pattern — fewer, more structured requests — that's often easier and cheaper to scale.
Geolocation used to require a separate API call or a geolocation database embedded in your server. Edge runtimes expose geographic information (country, region, city) directly from request metadata:
export const runtime = 'edge';
export default function Page(request: Request) {
const country = request.headers.get('cf-ipcountry'); // Cloudflare
// or
const geo = (request as any).geo; // Vercel Edge
// Redirect to localized version, no external service needed
if (country === 'DE') {
return Response.redirect('https://example.de');
}
}
Edge rendering isn't free lunch. The same properties that make edge functions fast create meaningful constraints.
This is the constraint that bites developers hardest. Your PostgreSQL database isn't available at the edge. Calling prisma.product.findMany() from an edge function will fail or perform terribly, because the database connection — which relies on persistent TCP connections and is optimized for a server sitting nearby — wasn't designed for ephemeral, geographically distributed clients.
The workaround: edge functions call HTTP APIs (your own or third-party), not databases directly. This pushes more architectural responsibility onto your API layer. Databases designed for edge access (PlanetScale, Neon, Turso, Upstash) expose HTTP endpoints specifically to address this.
Edge Function ──HTTP──► API Route (origin or another edge fn)
│
▼
Database (origin)
Many npm packages assume a Node.js environment. They import buffer, path, stream, or crypto from Node.js core. These don't exist in edge runtimes (though Web Crypto API is available as a substitute for crypto).
Before adopting a library in an edge function, check its edge compatibility. Next.js's build process will warn you when packages import Node.js built-ins incompatible with the edge runtime.
V8 isolates are fast to initialize — but the first request after a period of inactivity still incurs some startup overhead. For high-traffic applications this is negligible; for rarely-visited routes, it's worth understanding.
Distributed systems are harder to debug. An error in an edge function might originate from one of dozens of PoPs. Observability tooling for edge environments (structured logging, distributed tracing) is improving but still less mature than for traditional server environments.
These terms are sometimes conflated, but they're distinct.
Edge Middleware runs before your rendering logic — it intercepts requests and can rewrite, redirect, or modify them before they reach a page handler. In Next.js, this is middleware.ts. It's ideal for authentication guards, locale redirects, A/B testing, and bot detection.
Edge Rendering refers to page/route handlers themselves running at the edge — generating HTML at a PoP rather than at the origin.
You can use one without the other. Middleware is almost always beneficial (it's very cheap to run). Full edge rendering requires more architectural consideration.
Edge rendering has gone from an experimental curiosity to a first-class feature across the major deployment platforms:
Vercel pioneered the developer experience for edge rendering in Next.js. Their Edge Runtime is a subset of the Web APIs standard, and they've invested heavily in making the export const runtime = 'edge' migration path smooth.
Cloudflare Workers is the most mature edge compute platform by deployment scale. Their D1 (SQLite at the edge), R2 (object storage), and KV (key-value) products are building blocks for edge-native architectures that don't phone home to an origin for every data need.
Deno Deploy brings the Deno runtime to a globally distributed edge network, with first-class TypeScript and the same Web API compatibility philosophy as other edge runtimes.
AWS Lambda@Edge and CloudFront Functions bring edge compute to the AWS ecosystem, though with a steeper configuration curve than the developer-friendly alternatives above.
Fastly Compute targets enterprise use cases with strong isolation guarantees and predictable performance SLAs.
The convergence around Web APIs (Fetch, Request, Response, Headers, URL, Streams) as the common substrate for edge runtimes is significant. Code written for one platform is increasingly portable to others — a reversal of the vendor lock-in that plagued early serverless.
The best way to think about edge rendering isn't as a replacement for SSR or SSG — it's as a placement decision you make for each layer of your application.
Request Pipeline:
[User]
│
▼
[Edge Middleware] ← authentication, redirects, A/B testing, geo
│
▼
[Edge Rendering / CDN Cache] ← HTML generation, personalization
│
▼
[Origin API] ← business logic, database queries, heavy compute
│
▼
[Database / External Services] ← persistent state
Each layer has different latency, cost, and capability trade-offs. The skill of modern frontend architecture is knowing which work belongs at which layer — and edge rendering gives you a new, powerful option for that middle tier.
Edge rendering matters to frontend developers because the frontend developer's job no longer ends at the browser. The rendering pipeline — where HTML is generated, by what code, running where — is increasingly a frontend concern, and the edge is where that pipeline is most interesting right now.
The performance gains are real and measurable, especially for global audiences. The constraints are real too, and ignoring them leads to subtle bugs and architectural regret. But the tooling has matured to the point where edge rendering belongs in every frontend developer's mental model — even if you're not using it today.
The next time you deploy a page and check your TTFB numbers, ask: where is this code actually running? And then ask: could it run closer?
Create elementAI Explainer Videos That Convert With Simple Text Prompts.
Learn More
