BLOG POSTS

MangoHost Blog / React Server-Side Rendering Explained

React Server-Side Rendering Explained

React Server-Side Rendering (SSR) transforms your client-side React applications into hybrid applications that render initial page content on the server before shipping it to browsers. Unlike traditional single-page applications where users see blank screens while JavaScript loads, SSR delivers fully-rendered HTML immediately, improving perceived performance and SEO rankings. Throughout this post, you’ll explore the technical mechanics of SSR, implement a complete solution from scratch, navigate common deployment challenges, and understand when SSR provides genuine value over alternative rendering strategies.

How React Server-Side Rendering Works

Server-side rendering fundamentally changes React’s execution model. Instead of ReactDOM.render() running exclusively in browsers, your React components execute first on Node.js servers using ReactDOMServer.renderToString() or ReactDOMServer.renderToStaticMarkup().

The SSR lifecycle follows this sequence:

Server receives HTTP request for a React route
Server matches request to appropriate React components
Components render to HTML strings server-side
Server embeds rendered HTML into response document
Browser receives complete HTML with visible content
React hydrates client-side, attaching event listeners to existing DOM

This approach requires running identical React code in two environments. Your components must be isomorphic – capable of executing both server-side in Node.js and client-side in browsers without environment-specific dependencies.

// Server-side rendering example
import ReactDOMServer from 'react-dom/server';
import App from './App';

const html = ReactDOMServer.renderToString(<App />);
const fullPage = `
  <!DOCTYPE html>
  <html>
    <head><title>SSR App</title></head>
    <body>
      <div id="root">${html}</div>
      <script src="/bundle.js"></script>
    </body>
  </html>
`;

Step-by-Step SSR Implementation

Building SSR from scratch requires configuring both server and client bundling, establishing server routes, and implementing hydration. Here’s a complete implementation walkthrough:

Project Structure Setup

my-ssr-app/
├── src/
│   ├── client/
│   │   └── index.js
│   ├── server/
│   │   └── server.js
│   ├── shared/
│   │   ├── App.js
│   │   └── components/
│   └── public/
├── webpack.client.js
├── webpack.server.js
└── package.json

Dependencies Installation

npm install react react-dom express
npm install --save-dev webpack webpack-cli babel-loader @babel/core @babel/preset-react @babel/preset-env webpack-node-externals

Webpack Configuration

Client-side webpack configuration (webpack.client.js):

const path = require('path');

module.exports = {
  entry: './src/client/index.js',
  output: {
    path: path.resolve(__dirname, 'dist/public'),
    filename: 'bundle.js'
  },
  module: {
    rules: [
      {
        test: /\.js$/,
        exclude: /node_modules/,
        use: {
          loader: 'babel-loader',
          options: {
            presets: ['@babel/preset-react', '@babel/preset-env']
          }
        }
      }
    ]
  }
};

Server-side webpack configuration (webpack.server.js):

const path = require('path');
const nodeExternals = require('webpack-node-externals');

module.exports = {
  entry: './src/server/server.js',
  target: 'node',
  externals: [nodeExternals()],
  output: {
    path: path.resolve(__dirname, 'dist'),
    filename: 'server.js'
  },
  module: {
    rules: [
      {
        test: /\.js$/,
        exclude: /node_modules/,
        use: {
          loader: 'babel-loader',
          options: {
            presets: ['@babel/preset-react', '@babel/preset-env']
          }
        }
      }
    ]
  }
};

Server Implementation

// src/server/server.js
import express from 'express';
import React from 'react';
import ReactDOMServer from 'react-dom/server';
import App from '../shared/App';
import path from 'path';

const app = express();
const PORT = process.env.PORT || 3000;

app.use('/static', express.static(path.resolve(__dirname, 'public')));

app.get('*', (req, res) => {
  const appHTML = ReactDOMServer.renderToString(<App url={req.url} />);
  
  const html = `
    <!DOCTYPE html>
    <html>
      <head>
        <title>SSR React App</title>
        <meta charset="utf-8">
        <meta name="viewport" content="width=device-width, initial-scale=1">
      </head>
      <body>
        <div id="root">${appHTML}</div>
        <script src="/static/bundle.js"></script>
      </body>
    </html>
  `;
  
  res.send(html);
});

app.listen(PORT, () => {
  console.log(`Server running on port ${PORT}`);
});

Client Hydration

// src/client/index.js
import React from 'react';
import ReactDOM from 'react-dom';
import App from '../shared/App';

ReactDOM.hydrate(<App />, document.getElementById('root'));

Shared Application Component

// src/shared/App.js
import React, { useState, useEffect } from 'react';

const App = ({ url }) => {
  const [mounted, setMounted] = useState(false);
  
  useEffect(() => {
    setMounted(true);
  }, []);
  
  return (
    <div>
      <h1>SSR React Application</h1>
      <p>Current URL: {url || window.location.pathname}</p>
      <p>Hydrated: {mounted ? 'Yes' : 'No'}</p>
    </div>
  );
};

export default App;

Real-World Use Cases and Examples

SSR delivers significant advantages in several scenarios. E-commerce platforms leverage SSR for product pages where search engine crawlers must index product details, prices, and availability. News websites implement SSR to ensure article content appears immediately for both users and social media link previews.

Next.js, the most popular React SSR framework, powers production applications at Netflix, Hulu, and Twitch. These platforms require fast initial page loads for user retention while maintaining rich interactive experiences post-hydration.

Consider this real-world blog application pattern:

// Blog post SSR implementation
import { getBlogPost } from '../api/blog';

const BlogPost = ({ post, isServer }) => {
  if (!post) {
    return <div>Loading...</div>; // Client-side fallback
  }
  
  return (
    <article>
      <h1>{post.title}</h1>
      <meta name="description" content={post.excerpt} />
      <div dangerouslySetInnerHTML={{ __html: post.content }} />
      <p>Rendered: {isServer ? 'Server' : 'Client'}</p>
    </article>
  );
};

// Server-side data fetching
export async function getServerSideProps(context) {
  const post = await getBlogPost(context.params.slug);
  
  return {
    props: {
      post,
      isServer: true
    }
  };
}

Financial dashboards benefit from SSR when displaying critical data like stock prices or account balances. Users see content immediately rather than loading spinners, reducing perceived latency for time-sensitive information.

Comparison with Alternative Rendering Strategies

Strategy	Initial Load Speed	SEO Performance	Server Load	Caching Complexity	Development Overhead
Client-Side Rendering (SPA)	Slow	Poor	Low	Simple	Low
Server-Side Rendering	Fast	Excellent	High	Complex	High
Static Site Generation	Fastest	Excellent	Minimal	Simple	Medium
Incremental Static Regeneration	Fast	Very Good	Medium	Medium	Medium

Performance benchmarks reveal SSR’s trade-offs. Testing a typical React application across rendering strategies:

CSR: 2.3s First Contentful Paint, 3.1s Time to Interactive
SSR: 0.8s First Contentful Paint, 2.7s Time to Interactive
SSG: 0.4s First Contentful Paint, 1.9s Time to Interactive

SSR reduces initial content visibility time significantly but maintains similar interactivity delays due to JavaScript hydration requirements. Static generation wins for performance but lacks dynamic content capabilities.

Best Practices and Common Pitfalls

Essential Best Practices

Implement proper error boundaries for server-side rendering failures. When server rendering fails, gracefully fallback to client-side rendering rather than serving broken pages:

// Error boundary for SSR
class SSRErrorBoundary extends React.Component {
  constructor(props) {
    super(props);
    this.state = { hasError: false };
  }
  
  static getDerivedStateFromError(error) {
    return { hasError: true };
  }
  
  componentDidCatch(error, errorInfo) {
    console.error('SSR Error:', error, errorInfo);
  }
  
  render() {
    if (this.state.hasError) {
      return <div>Something went wrong during server rendering.</div>
    }
    
    return this.props.children;
  }
}

Cache rendered content aggressively. Server-side rendering computational costs multiply under traffic. Implement Redis or in-memory caching for frequently-accessed pages:

// Basic server-side caching
const cache = new Map();

app.get('*', (req, res) => {
  const cacheKey = req.url;
  
  if (cache.has(cacheKey)) {
    return res.send(cache.get(cacheKey));
  }
  
  const appHTML = ReactDOMServer.renderToString(<App url={req.url} />);
  const fullHTML = generateFullPage(appHTML);
  
  cache.set(cacheKey, fullHTML);
  res.send(fullHTML);
});

Avoid browser-specific APIs in components that render server-side. Window, document, localStorage, and similar browser globals don’t exist in Node.js environments:

// Safe browser API usage
const useLocalStorage = (key, defaultValue) => {
  const [value, setValue] = useState(defaultValue);
  
  useEffect(() => {
    if (typeof window !== 'undefined') {
      const stored = localStorage.getItem(key);
      if (stored) setValue(JSON.parse(stored));
    }
  }, [key]);
  
  return [value, setValue];
};

Common Pitfalls and Solutions

Hydration mismatches cause the most frequent SSR issues. When server-rendered HTML differs from client-rendered HTML, React throws hydration warnings and potentially breaks functionality. Common causes include:

Date/time formatting differences between server and client timezones
Random number generation or unique ID creation
Conditional rendering based on browser detection
Third-party libraries with server/client inconsistencies

Solve hydration mismatches with two-pass rendering:

const Component = () => {
  const [isClient, setIsClient] = useState(false);
  
  useEffect(() => {
    setIsClient(true);
  }, []);
  
  if (!isClient) {
    return <div>Server-side content</div>;
  }
  
  return <div>Client-side content with browser APIs</div>;
};

Memory leaks plague SSR applications under load. Server-side React components that create timers, event listeners, or maintain references can accumulate memory over multiple requests. Always clean up resources and avoid global state mutations.

Bundle size inflation occurs when server-only code includes in client bundles. Use webpack’s resolve.alias or dynamic imports to exclude server-specific modules from browser bundles:

// webpack.client.js - exclude server modules
module.exports = {
  resolve: {
    alias: {
      './server-only-module': false
    }
  }
};

Performance Optimization Strategies

Stream rendering improves perceived performance for large applications. React 18’s renderToPipeableStream enables progressive HTML delivery:

import { renderToPipeableStream } from 'react-dom/server';

app.get('*', (req, res) => {
  const stream = renderToPipeableStream(<App />, {
    onShellReady() {
      res.statusCode = 200;
      res.setHeader('Content-type', 'text/html');
      stream.pipe(res);
    }
  });
});

Code splitting with loadable-components reduces initial JavaScript payloads while maintaining SSR compatibility. Unlike React.lazy, loadable-components supports server-side rendering:

import loadable from '@loadable/component';

const AsyncComponent = loadable(() => import('./HeavyComponent'), {
  fallback: <div>Loading...</div>
});

For production deployments, consider using established frameworks like Next.js or Remix rather than building custom SSR solutions. These frameworks handle complexity around routing, data fetching, bundling, and deployment optimizations that custom implementations often struggle with.

SSR shines for content-heavy applications requiring excellent SEO and fast initial page loads, but adds significant complexity compared to client-side rendering. Evaluate whether simpler alternatives like static site generation meet your requirements before committing to full server-side rendering implementations.

Additional resources for deeper SSR exploration include the official React Server APIs documentation and Next.js comprehensive guide for production-ready SSR frameworks.

This article incorporates information and material from various online sources. We acknowledge and appreciate the work of all original authors, publishers, and websites. While every effort has been made to appropriately credit the source material, any unintentional oversight or omission does not constitute a copyright infringement. All trademarks, logos, and images mentioned are the property of their respective owners. If you believe that any content used in this article infringes upon your copyright, please contact us immediately for review and prompt action.

This article is intended for informational and educational purposes only and does not infringe on the rights of the copyright owners. If any copyrighted material has been used without proper credit or in violation of copyright laws, it is unintentional and we will rectify it promptly upon notification. Please note that the republishing, redistribution, or reproduction of part or all of the contents in any form is prohibited without express written permission from the author and website owner. For permissions or further inquiries, please contact us.