Server-Side Rendering (SSR)
Server-Side Rendering (SSR) means the server builds the full HTML for a page and sends it ready to display. The browser receives a complete page on the first response. This contrasts with Client-Side Rendering (CSR), where the server sends a near-empty page and JavaScript builds the content in the browser.
SSR vs CSR
SSR:
Browser -> request -> Server builds HTML -> full page arrives -> visible fast
CSR:
Browser -> request -> tiny HTML + JS -> JS runs -> fetches data -> then visible
With SSR, the user sees content sooner. With CSR, the first paint waits for JavaScript.
What the server returns
In SSR, the response already contains the real content.
HTTP/1.1 200 OK
Content-Type: text/html
<html>
<body>
<h1>Welcome, Ada</h1>
<ul><li>Order 1</li><li>Order 2</li></ul>
</body>
</html>
In CSR, the same route would return an empty <div id="root"></div> and a script tag.
Hydration
After SSR delivers HTML, the browser often loads JavaScript that “hydrates” the page, attaching event handlers so it becomes interactive. You get a fast first view plus a dynamic app.
1. Server sends ready HTML -> user sees content
2. JS loads and hydrates -> page becomes interactive
SEO
Search engine crawlers read HTML easily. With SSR, the content is right there in the response, so it indexes well. Pure CSR can be harder for some crawlers because the content only appears after JavaScript runs.
Advantages
- Faster first paint and time to content.
- Better SEO: content is in the initial HTML.
- Works even before JavaScript loads.
Disadvantages
- More server work per request, so higher server cost.
- More complex setup, especially with hydration.
- Trickier caching than fully static pages.
When to use it
Choose SSR for content-heavy and public pages where SEO and first-load speed matter: blogs, e-commerce, landing pages. For private dashboards behind a login, CSR is often fine since SEO does not apply. Many frameworks let you mix both per page.