SSR (Server-Side Rendering) is a rendering strategy where HTML is generated on the server for each incoming request, delivering a fully-formed page to the browser rather than relying on client-side JavaScript to render content.
SSR contrasts with CSR (Client-Side Rendering) and SSG (Static Site Generation). The trade-offs:
- SSR pros: per-request freshness, server-side authentication, full HTML on first byte (essential for SEO).
- SSR cons: each request hits the server; latency depends on server load and origin location.
For ecommerce, SSR is mandatory for SEO surfaces — search engine crawlers do not reliably execute JavaScript, so client-rendered pages frequently render empty for Googlebot. Modern SSR is usually paired with caching (CDN edge cache, ISR-style revalidation, Cache Components) to limit how often the origin server actually renders.
In Next.js 16, the line between SSR, ISR, SSG, and PPR has blurred. The cacheComponents + PPR model lets developers describe what should be cached and what should be dynamic at the component level rather than the page level, eliminating most of the historical strategy choices.