Edge rendering
Slap yourself if
You think edge rendering is just SSR moved closer to the user.
Why this exists
Edge rendering exists because latency dominates perceived performance, but centralized servers can’t get closer than physics allows. Moving execution to the edge reduces round trips, but introduces a very different execution and consistency model.
Mental model
Edge rendering is not ‘the server, but faster’. It’s a constrained, distributed execution layer where code runs closer to users, with limited state, limited time, and weak guarantees about reuse.
- A request is routed to a geographically close edge node.
- Rendering logic executes in a sandboxed, short-lived environment.
- Responses are streamed or returned without touching the origin.
- State is typically derived from the request, not shared memory.
- Assuming edge nodes share state or caches globally.
- Porting server code that relies on long-lived connections.
- Underestimating cold start frequency at scale.
- Treating edge failures as rare instead of expected.
Edge rendering is server-side rendering executed on distributed edge nodes close to users, trading lower latency for tighter execution constraints and weaker state guarantees.
- Using edge functions as a general-purpose backend
- Relying on in-memory caches for correctness
- Ignoring regional consistency issues
- Assuming edge always beats origin latency
Deep dive
Requires Pro
Premium deep dives include more internals, more scars.