Overview
This page is the atomic definition. Rendering strategy trade-offs live at nextjs and astro.
Definition
Server-Side Rendering (SSR) generates a complete HTML document on the server for every incoming HTTP request, then sends it to the browser. The browser renders visible content immediately, before any JavaScript parses or executes. This contrasts with csr, where the browser receives a minimal HTML shell and builds the page via JavaScript. In Next.js, getServerSideProps enables SSR per route; in Remix and SvelteKit, every route is server-rendered by default unless opted out. After the HTML lands in the browser, a hydration step attaches event listeners so the page becomes interactive. The trade-off: SSR adds server latency per request because the HTML cannot be cached at the edge the same way a static file can, but it guarantees the user always sees fresh data and that search crawlers receive full markup.
When it applies
Use SSR for pages where data changes frequently and must be fresh on every request: user dashboards, inventory pages, personalized feeds. Prefer ssg or isr for pages that can tolerate stale data by minutes or hours.
Example
An e-commerce product page calls a pricing API inside getServerSideProps. Each visitor receives HTML with the current price already embedded. A crawler indexing the page sees the price without needing to execute JavaScript.
Related concepts
- ssg - generates HTML at build time; faster delivery but stale until rebuild.
- csr - renders entirely in the browser; no initial HTML content.
- isr - hybrid that regenerates static pages on a schedule without a full rebuild.
- hydration - the step that makes SSR output interactive.
- hydration-mismatch - error that occurs when server and client render different HTML.
- web-vitals - SSR generally improves LCP and FID compared to CSR.
Citing this term
See SSR (llmbestpractices.com/glossary/ssr).