Edge SSR is server-side rendering executed on edge compute infrastructure (like Cloudflare Workers or Vercel Edge) distributed across many global locations, rather than a single origin server. This cuts network latency by running the render close to the requesting user, at the cost of a more constrained runtime (no full Node.js APIs, stricter memory/CPU limits).
Traditional server-side rendering runs on a server in one region — if that server is in the US and a user requests the page from India, every request pays the round-trip latency to reach it, on top of the actual render time. Edge SSR runs the same rendering logic on infrastructure deployed at dozens of global points of presence, so the request is handled by whichever location is physically closest to the user, cutting network latency substantially.
Edge runtimes (Cloudflare Workers, Vercel Edge Runtime) are not full Node.js — they're deliberately lightweight, V8-isolate-based environments with CPU time limits, memory caps, and a restricted API surface (no native Node modules like `fs` without a compatibility layer). This means Edge SSR isn't a free upgrade over traditional SSR: code that does heavy computation, relies on Node-specific APIs, or needs long-running processes has to be re-architected, or explicitly opted out of the edge runtime for those specific routes.
No - it's usually a per-route decision. Pages doing heavy computation or relying on Node-specific APIs are often better left on standard server rendering, while lightweight, latency-sensitive pages benefit most from edge SSR.
No - SSG pre-renders pages at build time and serves the same static output to everyone. Edge SSR still renders per-request, it just does so on distributed edge infrastructure instead of a single origin server.