Server-side rendering (SSR)
An architecture in which HTML is generated on the server in response to each request, then sent to the browser fully assembled.
Also known as: SSR
Server-side rendering (SSR) is an architecture in which a server generates the full HTML for a web page in response to each request, then sends the assembled HTML to the browser. The browser receives complete, ready-to-display content without needing to run JavaScript first.
How SSR works
When a visitor requests a page on an SSR site:
- The server receives the request
- Application code runs, fetching any required data (from a database, API, or file system)
- A template is applied to that data, producing complete HTML
- The server returns the HTML to the browser
- The browser displays the page; client-side JavaScript may then “hydrate” interactive elements
This is the model used by traditional CMS platforms like WordPress and Drupal, and by modern JavaScript frameworks running in SSR mode (Next.js, Nuxt, Remix, SvelteKit).
SSR vs static rendering
SSR generates HTML on each request; static rendering generates HTML at build time and serves the same file repeatedly.
| Aspect | SSR | Static |
|---|---|---|
| When HTML is generated | Per request | At build time |
| Per-request server work | Yes | No |
| Personalization | Native | Requires client-side JS or APIs |
| Hosting | Application server required | Any file host or CDN |
| Update propagation | Immediate | After rebuild |
SSR vs client-side rendering (CSR)
In CSR, the server sends a near-empty HTML shell and a JavaScript bundle. The browser runs the JavaScript, which builds the page in place. SSR sends fully assembled HTML; CSR builds it in the browser.
SSR pages typically appear faster on first load and are more reliably indexed by search engines. CSR can offer smoother in-app navigation after the initial load.
Common SSR frameworks
- Next.js, React-based, supports SSR, static export, and ISR
- Nuxt, Vue-based, similar capabilities to Next.js
- Remix, React-based, focused on SSR and form-driven workflows
- SvelteKit, Svelte-based, supports SSR and static
- Astro, supports SSR but defaults to static
- Ruby on Rails, Django, Laravel, Phoenix, traditional server-side frameworks predating the modern JavaScript SSR wave
Performance characteristics
SSR pages tend to have:
- Fast Time to First Byte (TTFB) if the server and database are well-tuned, but slower than static
- Fast First Contentful Paint because the HTML arrives ready
- Variable performance under load, heavy traffic can saturate the server
- Improved performance with caching at the page, fragment, or CDN level
For consistent performance under traffic spikes, SSR is often paired with edge caching or hybrid approaches like Incremental Static Regeneration.
When SSR tends to fit
- Pages with highly personalized content (logged-in users, per-visitor recommendations)
- Pages with rapidly changing data that should not be cached
- SEO-critical pages that need fully rendered HTML on first response
- Applications with complex server-side logic that should not run in the browser
When other approaches tend to fit better
- Marketing sites and blogs with stable content (static rendering is often sufficient)
- Highly interactive applications after first load (CSR with an API backend may be smoother)
- Sites with global audiences and predictable content (CDN-cached static is often faster)
Common misconceptions
- “SSR is slower than CSR.” SSR is faster on first load; CSR can feel faster on subsequent in-app navigation, depending on architecture.
- “SSR is the same as a dynamic site.” All SSR sites are dynamic by definition. Not all dynamic systems use the term SSR; the label is more common in the JavaScript ecosystem.
- “You must choose SSR, CSR, or static.” Modern frameworks support all three on a per-route basis within the same project.