Skip to content

Server Rendering Strategies in React

At the end of this class, you should be able to…

  • Explain the principles of server-side rendering and how it differs from client rendering.
  • Describe the benefits and trade-offs of SSR in terms of performance, SEO, and complexity.
  • Explore how frameworks such as React Router v7 and Next.js implement SSR and hybrid rendering.

Additional Notes:

  • Emphasize that students are not expected to implement full SSR yet (focus on understanding its purpose and process).
  • Time permitting, compare with Next.js as a reference framework to show SSR, static generation, and hybrid options conceptually.
  • React 19 introduces enhancements for streaming and progressive hydration—mention as a future direction.
  • Prepare to transition from rendering strategies to state management patterns in the next lesson.

The SSR demo project is intentionally small:

lesson-22-ssr-demo/
├── package.json
├── server.js
└── public/
└── client.js

We are using this project to demonstrate the idea of SSR clearly before looking at framework-supported SSR.

This lesson introduces server-side rendering (SSR) and compares it to client-side rendering (CSR).

We will:

  • examine how SSR works conceptually
  • compare CSR and SSR behavior
  • observe how HTML is delivered differently
  • understand hydration
  • explore how frameworks support SSR
  • identify when SSR is appropriate

This lesson is primarily conceptual with light implementation.

In Lesson 21, we learned:

  • React apps commonly use client-side rendering
  • the browser builds the UI after JavaScript loads
  • the initial HTML is minimal

This creates a key limitation:

The user may see a blank or incomplete page before the app loads.

In a CSR application:

HTML loads -> JavaScript loads -> React renders -> UI appears

This can result in:

  • delayed first content
  • poor perceived performance
  • heavy reliance on JavaScript

Server-side rendering means:

  • the server generates HTML for the requested route
  • the browser receives ready-to-display content
  • JavaScript loads afterward to enable interactivity
User requests page -> Server renders HTML -> Browser displays content immediately -> JavaScript loads -> React hydrates the page

SSR improves time to first content and perceived performance.

Open the SSR demo project and inspect the server.js file.

You should see something similar to this:

app.get('/', (req, res) => {
res.send(`
<html>
<body>
<h1>Server Rendered Page</h1>
<p>This content was generated on the server.</p>
<script src="/client.js"></script>
</body>
</html>
`);
});

The demo also includes a small client script in:

public/client.js

That script simulates hydration by attaching behaviour after the HTML has already been rendered and displayed.

  • the HTML already contains visible content
  • no JavaScript is required to see the page
  • the browser renders immediately

CSR HTML:

<div id="root"></div>

SSR HTML:

<h1>Server Rendered Page</h1>

SSR alone is not enough.

The application must still become interactive.

Hydration is:

React attaching behaviour to server-rendered HTML

For example, the client script may include logic like:

document.getElementById('test-btn')?.addEventListener('click', () => {
alert('Button is now interactive');
});

The key idea is that the HTML was already visible before this script made the page interactive.

Server -> HTML
Client -> JavaScript loads
React -> attaches event handlers
UI -> becomes interactive
  • SSR provides content early
  • hydration enables interactivity

Open DevTools -> Network -> Document

Reload the SSR page.

  • HTML contains real content
  • content appears immediately
  • JavaScript loads afterward

CSR:

  • HTML is minimal
  • content appears after JavaScript runs

SSR:

  • HTML contains content
  • content appears immediately

Modern applications often combine rendering strategies.

  • some routes use SSR
  • some routes use CSR
  • some routes are pre-rendered
  • marketing page -> SSR
  • admin dashboard -> CSR
  • blog -> pre-rendered

Rendering strategy is a design decision, not a fixed rule.

Modern frameworks handle SSR for you.

Examples:

  • React Router (framework mode)
  • Next.js
  • Remix (Now React Router)
  • render routes on the server
  • run loaders on the server
  • send HTML to the browser
  • hydrate on the client

We do not typically build SSR manually.

Frameworks manage the complexity.

  • browser renders UI
  • minimal initial HTML
  • requires JavaScript before content appears
  • server renders HTML
  • content appears immediately
  • JavaScript enhances interactivity
FeatureCSRSSR
Initial contentDelayedImmediate
InteractivityAfter JSAfter hydration
ComplexityLowerHigher
Performance perceptionLowerHigher
  • faster initial content display
  • improved perceived performance
  • better SEO support
  • works better on slower devices
  • more complex architecture
  • requires a server environment
  • more complex deployment
  • hydration still required
  • SSR moves rendering to the server
  • hydration connects server-rendered HTML to React
  • CSR and SSR solve different problems
  • hybrid rendering is common in real applications
  • frameworks simplify SSR implementation

Students should be able to explain:

  • what SSR is
  • how SSR differs from CSR
  • what hydration is
  • one advantage of SSR
  • one tradeoff of SSR

Answer the following questions:

  1. What is server-side rendering?
  2. What problem does SSR solve?
  3. What is hydration?
  4. When might SSR be a better choice than CSR?

Determine the best rendering strategy for each:

  • marketing website
  • admin dashboard
  • blog platform
  • real-time collaboration app

Be prepared to explain your reasoning.