Edge Rendering Explained: Why Your Site Should Run Closer to Your Visitors
Edge rendering runs your site's code in data centres close to each visitor. Here is what that actually means, how it differs from a CDN, and when it helps or quietly makes things slower.
"We deploy to the edge" has become a line in every hosting pitch. It sounds like it must be faster, and sometimes it is. Sometimes it makes a site slower, and nobody mentions that part. It is one of the development trends I am watching this year, so here is what edge rendering actually is in plain English, followed by the practical notes I give developers when we decide where code should run.
Three places your page can be built
When someone visits a page, the HTML has to come from somewhere. There are broadly three options.
- A single-region server. Your code runs in one data centre, say London or Virginia. Every visitor, wherever they are, sends their request there and waits for the reply. Simple, predictable, and close to your database.
- A CDN cache. A content delivery network keeps copies of finished files in many locations worldwide. A visitor in Sydney gets a copy stored in or near Sydney. Nothing is computed; a saved answer is handed over.
- An edge function. Your code runs in those same distributed locations, so a visitor in Sydney has their request handled by code running near Sydney. Unlike a cache, it can make a fresh decision for every request.
Edge rendering is option three applied to building the page itself.
Why distance matters at all
Data travels fast but not instantly, and a web request is rarely a single trip. Connection setup, security handshakes and the request itself all involve round trips. A visitor on another continent can spend a noticeable fraction of a second waiting for signals to cross oceans before your server has done any work at all.
Moving the code closer shortens every one of those trips. That is the entire pitch, and for the right kind of work it holds up.
Edge function vs CDN cache: not the same thing
These get confused constantly, including in sales material. The difference is whether anything is computed.
| CDN cache | Edge function | Single-region server | |
|---|---|---|---|
| Runs your code per request | No | Yes | Yes |
| Close to the visitor | Yes | Yes | Only for nearby visitors |
| Close to your database | Not relevant | Usually not | Yes, if you put them together |
| Can personalise per visitor | No | Yes | Yes |
| Best for | Pages and files that are the same for everyone | Quick decisions per request | Data-heavy pages |
A cached page is almost always the fastest option of all, because there is nothing to compute. If a page is the same for every visitor, cache it; do not run code at the edge to rebuild it on every request. I cover this properly in CDNs and caching explained.
Where edge code genuinely helps
The edge shines when a request needs a small, fast decision based only on information already in the request: cookies, approximate location, the URL, the headers.
- Authentication redirects. Checking whether a session cookie exists and sending logged-out visitors to the login page before any page work starts.
- Geo routing. Sending visitors to the right country or language version, which matters if you run a multilingual site. Suggest rather than force where you can; redirecting search engine crawlers into one version can cause indexing problems.
- A/B testing. Assigning a variant at the edge and serving the matching cached page avoids the flicker of client-side testing tools.
- Light personalisation. Swapping a currency, a banner or a regional phone number without rebuilding the whole page.
- Header and security rules. Adding headers, blocking obvious bad traffic, rewriting old URLs.
In Next.js this kind of request-level logic lives in one file that runs before any route, originally called middleware and renamed proxy in recent versions. It is part of the App Router setup I use on nearly every client site.
Where it hurts: your database is still in one place
This is the part the hosting pitch leaves out. Most business sites have a database, a CMS or an e-commerce backend, and it lives in one region. If your page is rendered at the edge in Sydney but needs three queries from a database in Virginia, every one of those queries crosses the Pacific. You have moved the code closer to the visitor and further from the data.
For a page that makes one quick call, this can still come out ahead. For a page that makes several calls in sequence, it is often slower than rendering the whole thing in Virginia and sending the finished HTML once. One long trip beats many.
Put the code next to whatever it talks to most. For routing decisions, that is the visitor. For page rendering, it is usually your data.
This is why the industry has swung back somewhat. Much of the early excitement was about rendering entire pages at the edge; the more common advice now is to keep lightweight logic at the edge and run data-heavy rendering in a region close to the database.
Practical notes for developers
Runtime limits
Edge runtimes are usually a slimmed-down JavaScript environment built on web-standard APIs like fetch, Request and Response, not full Node.js. Some Node APIs are missing, some npm packages will not run, and code size and execution time limits are tighter than on a regular server. Check that your database driver, auth library and any image or PDF tooling actually work there before committing.
Database connections
Traditional database drivers expect long-lived connections, which do not suit short-lived functions spread across many locations. If you do query from the edge, use an HTTP-based driver or a connection pooler, and consider read replicas in the regions where most of your visitors are.
Caching still comes first
Before moving anything to the edge, ask whether the response could simply be cached. Static and incrementally regenerated pages served from a CDN will beat edge rendering for anything that is the same for everyone.
Measure from where your visitors are
Test from the regions your customers are in, not from your office. A change that saves time for visitors abroad can add time for visitors next door to your server.
Questions to ask your developer or host
- Which parts of our site run at the edge, and which run in a single region?
- Where is our database, and how many times does a typical page talk to it?
- Which pages are cached, and for how long?
- Have we measured response times from the countries our customers are in?
If the answers are vague, that is worth knowing before you pay for a premium tier. My guide to choosing website hosting covers the rest of what to ask.
Does your site need it?
If your visitors are mostly in one country and your host is in or near that country, edge rendering will make very little difference. Good caching and a lean front end will do far more, and your Core Web Vitals will tell you where the real problems are. If you sell internationally, gate content behind logins, or personalise by region, a small amount of well-placed edge logic can be a genuine improvement.
Not sure where your site's code should run? Send me the URL and tell me where your customers are, and I will tell you whether the edge would help or just add cost.
