Introduction to Server-Side Rendering with React

What is Server-Side Rendering (SSR)?
SSR vs. Client-Side Rendering (CSR): Key Differences
Why Use SSR with React?
How SSR Works with React: A Step-by-Step Overview
Setting Up SSR in React: A Practical Example
Key Considerations for SSR in React
Popular SSR Frameworks for React
Conclusion
References

1. What is Server-Side Rendering (SSR)?

Server-Side Rendering (SSR) is a technique where the server generates fully rendered HTML for a web page before sending it to the client. For React applications, this means the server processes React components, fetches necessary data, and converts those components into a static HTML string. This HTML is then sent to the browser, which displays the content immediately—even before the JavaScript bundle finishes downloading.

Once the client receives the HTML, it downloads the React JavaScript bundle and “hydrates” the static HTML. Hydration is the process where React attaches event listeners, initializes state, and makes the static content interactive, turning it into a fully functional React app.

2. SSR vs. Client-Side Rendering (CSR): Key Differences

To understand SSR’s value, let’s compare it to CSR, the default approach for most React apps:

Aspect	Client-Side Rendering (CSR)	Server-Side Rendering (SSR)
Rendering Location	Browser (client)	Server
Initial HTML Content	Minimal (often just a `<div id="root"></div>`)	Fully populated with page content
Time to First Contentful Paint (FCP)	Slower (waits for JS bundle to download/parse)	Faster (HTML is sent immediately)
SEO Friendliness	Poor (search engines may struggle to crawl JS-rendered content)	Excellent (search engines crawl static HTML easily)
Server Load	Low (server only serves static files)	Higher (server renders HTML for each request)
Complexity	Simpler (no server setup for rendering)	More complex (requires server setup, data sync)

When to Use CSR: For dynamic SPAs with heavy user interaction (e.g., dashboards, editors) where initial load time is less critical.
When to Use SSR: For content-heavy apps (e.g., blogs, e-commerce) where SEO, fast initial load, and user experience on slow networks matter.

3. Why Use SSR with React?

SSR solves critical pain points of CSR for React apps:

Search engines and social media crawlers (e.g., Twitter, Facebook) rely on parsing HTML to index content or generate previews. With CSR, crawlers may only see an empty <div>, leading to poor search rankings or broken previews. SSR ensures crawlers receive fully rendered content.

2. Faster Initial Page Load

Users see content faster with SSR because the server sends pre-rendered HTML. This improves metrics like Largest Contentful Paint (LCP), a core web vital that impacts SEO and user retention.

3. Better Performance on Low-Powered Devices

Low-end phones or devices with limited processing power struggle to parse large JS bundles quickly. SSR reduces the client’s workload by sending pre-rendered HTML, making apps usable sooner.

4. Enhanced Accessibility

Screen readers and assistive technologies can parse SSR HTML immediately, improving accessibility for users who rely on these tools.

4. How SSR Works with React: A Step-by-Step Overview

Let’s break down the SSR workflow for a React app:

Client Requests a Page: The user navigates to https://yourapp.com/blog/post-1.
Server Fetches Data: The server identifies the requested route and fetches necessary data (e.g., from a database or API) to render the page (e.g., blog post content).
Server Renders React to HTML: Using ReactDOMServer.renderToString() or renderToPipeableStream(), the server renders the React component tree (e.g., BlogPost) into an HTML string, injecting the fetched data into the components.
Server Sends HTML to Client: The server wraps the rendered HTML in a full HTML document (with <head>, <body>, etc.) and sends it to the client.
Client Displays Static HTML: The browser displays the HTML immediately, so the user sees content without waiting for JavaScript.
Client Downloads JS Bundle: The browser downloads the React bundle (including component logic, state, and event handlers).
Hydration: React “hydrates” the static HTML by attaching event listeners, initializing state, and syncing the client-side React tree with the server-rendered HTML. The app becomes fully interactive.

SSR Workflow

5. Setting Up SSR in React: A Practical Example

Let’s build a simple SSR React app from scratch. We’ll use:

Express: A Node.js server framework to handle requests.
ReactDOMServer: React’s built-in module for server-side rendering.
ReactDOM.hydrateRoot: For hydrating the client-side app.

Step 1: Project Setup

First, initialize a Node.js project and install dependencies:

mkdir react-ssr-demo && cd react-ssr-demo
npm init -y
npm install react react-dom express

Step 2: Create a React Component

Create a simple component (src/App.js) to render:

// src/App.js
import React from 'react';

function App({ title, content }) {
  return (
    <html>
      <head>
        <title>{title}</title>
      </head>
      <body>
        <h1>{title}</h1>
        <p>{content}</p>
        <button onClick={() => alert('SSR Hydrated!')}>Click Me</button>
      </body>
    </html>
  );
}

export default App;

Step 3: Set Up the Express Server

Create a server (server.js) to handle requests, fetch data, render React to HTML, and send it to the client:

// server.js
import express from 'express';
import React from 'react';
import { renderToString } from 'react-dom/server';
import App from './src/App.js';

const app = express();
const PORT = 3000;

// Serve static files (e.g., client-side JS)
app.use(express.static('public'));

// Handle all routes
app.get('*', (req, res) => {
  // Step 1: Fetch data (simulated here)
  const pageData = {
    title: 'SSR Demo',
    content: 'This content was rendered on the server!',
  };

  // Step 2: Render React component to HTML string
  const appHtml = renderToString(<App {...pageData} />);

  // Step 3: Send HTML to client (includes appHtml and client JS bundle)
  res.send(`
    <!DOCTYPE html>
    ${appHtml}
    <script src="/client-bundle.js"></script>
  `);
});

app.listen(PORT, () => {
  console.log(`Server running on http://localhost:${PORT}`);
});

Step 4: Hydrate the Client-Side App

Create a client entry file (src/client.js) to hydrate the server-rendered HTML:

// src/client.js
import React from 'react';
import { hydrateRoot } from 'react-dom/client';
import App from './App.js';

// Reuse the same data as the server (in practice, pass via window.__INITIAL_DATA__)
const pageData = {
  title: 'SSR Demo',
  content: 'This content was rendered on the server!',
};

// Hydrate the app
const root = document.documentElement; // Target the root of the server-rendered HTML
hydrateRoot(root, <App {...pageData} />);

Step 5: Bundle Client-Side Code

To run the client code, we need to bundle it (e.g., with Webpack or Vite). For simplicity, use esbuild (a fast bundler):

npm install -D esbuild
npx esbuild src/client.js --bundle --outfile=public/client-bundle.js

Step 6: Run the App

Start the server and visit http://localhost:3000:

node server.js

You’ll see:

Pre-rendered HTML (view page source to confirm).
The “Click Me” button works (hydration attached the event listener).

6. Key Considerations for SSR in React

While SSR improves UX, it introduces complexity. Here’s what to watch for:

1. Data Fetching

Data required for rendering must be fetched on the server before rendering. Tools like react-query or SWR can help sync data between server and client, but you’ll need to ensure data is available server-side (e.g., using getServerSideProps in Next.js).

2. Server Load & Caching

SSR increases server load since each request triggers rendering. Mitigate this with caching (e.g., CDN caching for static pages, in-memory caching for frequent requests).

3. Routing

The server must handle client-side routes (e.g., /blog/post-1). Use libraries like react-router and configure the server to redirect all routes to your SSR handler.

4. State Management

State initialized on the server (e.g., Redux, Context) must be passed to the client. Attach state to window.__INITIAL_STATE__ in the server-rendered HTML, then rehydrate it client-side.

5. Code Splitting

Avoid large client bundles by splitting code into chunks (e.g., with React.lazy or Next.js’s automatic code splitting).

7. Popular SSR Frameworks for React

Manual SSR setup (as in our example) is complex. Frameworks abstract this complexity:

1. Next.js (Most Popular)

Next.js is the de facto SSR framework for React. It simplifies SSR with:

Automatic code splitting, routing, and data fetching (getServerSideProps).
Hybrid rendering (SSR, Static Site Generation, Incremental Static Regeneration).
Built-in API routes and image optimization.

Use Case: E-commerce, blogs, marketing sites.

2. Gatsby

Gatsby uses Static Site Generation (SSG) (pre-renders pages at build time) but supports SSR for dynamic content. It’s ideal for content-heavy sites with GraphQL integration.

Use Case: Documentation, blogs.

3. Remix

Remix is a full-stack framework focused on nested routing and data loading. It uses SSR by default and emphasizes web standards (e.g., FormData, Fetch API).

Use Case: Complex apps with nested routes (e.g., dashboards).

4. Razzle

Razzle is a zero-configuration SSR toolchain that works with React (and other libraries like Vue). It abstracts Webpack and Babel setup.

Use Case: Prototyping or custom SSR setups.

8. Conclusion

Server-Side Rendering (SSR) transforms React apps by delivering faster initial loads, better SEO, and improved user experience on slow networks. While manual SSR setup is complex, frameworks like Next.js make it accessible to most developers.

If your React app is content-heavy, SEO-critical, or needs to perform well on low-end devices, SSR is worth exploring. Start small with Next.js to leverage its built-in SSR tools, and iterate from there!

Table of Contents