Edge rendering and its tradeoffs
Rendering close to the visitor sounds like pure win. It is, until your data lives somewhere else.
The pitch
Edge rendering runs your server code in data centers near your visitors instead of in one central region. A request from Sydney is handled in Sydney, a request from Frankfurt in Frankfurt. The network round trip for the HTML shrinks from hundreds of milliseconds to a few dozen.
For pages that need no data, or only data that is itself replicated globally, this is an unambiguous improvement.
The catch
Most pages need data, and most data lives in one place. If a page rendered in Sydney must query a database in Virginia, the round trip has not disappeared; it has moved. Worse, a page that makes three sequential queries now pays the long-distance trip three times, where a server sitting next to the database would have paid it once on the way back to the visitor.
This is the central tradeoff: edge rendering is fast when the data is close to the edge, and can be slower than central rendering when it is not.
Patterns that work
Static shell, dynamic islands
Render the parts of the page that do not depend on user data at the edge, or serve them from cache, and fetch the personalized parts separately. The visitor sees the page structure immediately.
Replicated reads
Many databases now offer read replicas in multiple regions. If the page only reads, an edge function can query the nearest replica and keep the whole request local.
Edge caching of data, not pages
Instead of caching whole pages, cache the API responses the page depends on at the edge for a short time. Pages are still rendered fresh on every request, but the data behind them is usually a nearby cache hit.
Regional rendering
Some platforms let you pin rendering to the region where your data lives while still terminating connections at the edge. You lose some latency on the first hop but avoid repeated long-distance queries.
Runtime constraints
Edge runtimes are usually lighter than a full server environment. Some libraries that rely on native modules or particular file system access will not run there. Check your dependencies before committing.
Measure, do not assume
The only way to know whether edge rendering helps your particular pages is to measure from multiple regions. Test time to first byte from at least three continents with both setups, using realistic data access patterns. The answer is frequently different for different pages on the same site, and a hybrid is often best.