Want your site to make a stellar first impression? One of the best ways, at least on the technical end, is to achieve fast load times and to make it as easy as possible for a browser to crawl your site. This’ll keep your SEO sharp and your site responsive.
This is where Server Side Rendering (SSR) comes in. React 19, the leading JavaScript library, offers even better SSR capabilities than React 18 did. It’s easier than ever to leave the heavy lifting to the server and make sure browsers and users alike get the smoothest possible user experience.
Interested? In this guide, we’re going to dig into the exciting world of React Server Side Rendering. Our experts will break down what SSR really is, its pros and cons, and, of course, how to implement Server Side Rendering in React. Stay tuned!
What is Server Side Rendering in React?
React Server Side Rendering is a way of leaving a website’s heavy lifting to the server. Users see the page, 100% ready to go, almost instantly.
Imagine you’re at a restaurant. With SSR, the chef prepares your entire meal in the kitchen (which is the server) and serves it to you steaming and ready to enjoy. You don’t have to do any cooking or plating up. That’s very different from CSR (Client Side Rendering), where the chef would give you the ingredients and instructions and leave the rest to you. This is basically how it works: the server sends a fully prepared webpage to your browser.
Of course, there’s a lot more to Server Side Rendering in React than this. A more technical explanation would be:
SSR means the HTML for a page is generated on the server at request time and sent to the client already populated with content. The browser just renders that HTML, then hydrates it with JavaScript for interactivity. By contrast, CSR ships mostly an empty HTML shell and a JavaScript bundle, and the browser executes the JS to fetch data and build the UI.
Most modern sites actually use a mixture of both SSR and CSR - what we call a “hybrid.” This approach means that some parts are rendered on the server for speed, while others are handled in the browser for interactivity.
React Server Side Rendering: pros & cons
Server Side Rendering in React may open up new doors, but it’s not a magic wand. There are plenty of advantages and disadvantages to take into account when considering whether or not to implement SSR.
Here’s what you should be looking at:
Pros
The main advantages of SSR are:
- Faster first load (TTFB / FCP): the server sends a fully built HTML page, the user sees the content almost instantly. Simple. Studies show that slow load times are one of the main reasons users bounce, so this is a major plus in SSR’s favour.
- SEO-friendly: when the HTML is pre-rendered, search engines can easily crawl it (which they can’t do as easily with CSR). This means better discoverability and better SERP performance.
- Better for slow devices: even weaker devices like older phones can display your content relatively quickly because less computation is required on the client side. It’s pre-rendered.
- Consistent content delivery: when the HTML is pre-rendered, it’ll be the same everywhere it goes, regardless of browser or device. This means you effectively have more control over the site.
Cons
Now, let’s examine a few potential drawbacks:
- Higher server load: with SSR, the server is working overtime. Every time a request comes in, it’s the server that has to generate HTML, not the client. Over time, this can be expensive, especially under heavy traffic.
- Slower navigation (after first page): CSR is great for smooth, app-like navigation. SSR, however, provides less optimization on the client’s side, so moving around the site can feel less responsive (depending on conditions).
- Complex setup: true SSR requires backend rendering infrastructure and sometimes caching strategies to scale well.
- Latency-sensitive: it’s all very well handing off the hard work to the server, but what happens when the server is far away from the user, or has a slow response time? SSR is vulnerable to latency issues.
How to implement Server Side Rendering in React, step-by-step
Now for the technical part: how to actually use Server Side Rendering in React.
You have two options to choose from right from the outset:
- Use a framework: for example, with Next.js. Built-in SSR, routing, data fetching and deployment conveniences. The fastest way to get SSR without reinventing infra.
- Custom SSR: roll your own Node server (with Express, for example) plus React’s server APIs. Gives maximum control and is great for learning or very custom setups.
Below, we’ll go over both methods using examples (note that these are examples and will need adjustments for your own projects!).
Method 1: SSR with Next.js
The easy-entry method for SSR:
1.Open your terminal and run this command:
npx create-next-app@latest my-ssr-app2. Then, go into the new folder:
cd my-ssr-app3. And start the development server:
npm run dev4. For per-request SSR use “getServerSideProps” (pages router) or use server components / fetch with “no-store” in the app router. Next handles rendering and hydration for you. Here’s an example:
// pages/profile.jsx
export async function getServerSideProps(ctx) {
const res = await fetch(`https://api.example.com/user/${ctx.params.id}`);
const user = await res.json();
return { props: { user } }; // rendered on server for every request
}
export default function Profile({ user }) {
return <div>Hello {user.name}</div>;
}Method 2: Do it yourself
Method two takes longer, but ultimately gives you more control. Follow these steps:
First, you’ll have to set up the new project:
1.Make a new folder and go inside it:
mkdir my-ssr-app
cd my-ssr-app2. Initialize a Node project (this creates a “package.json”):
npm init -y3. Install the dependencies you’ll need:
npm install react react-dom express
npm install -D @babel/core @babel/preset-env @babel/preset-react babel-loader webpack webpack-cliNow, it’s time to create your React app component:
4. In a folder called “src”, add a file “App.jsx”:
// src/App.jsx
import React from "react";
export default function App({ message }) {
return (
<html>
<head>
<title>My SSR App</title>
</head>
<body>
<div id="root">
<h1>{message}</h1>
</div>
<script src="/bundle.js"></script>
</body>
</html>
);
}Now, you need a client entry file.
5.Make a file “src/client.jsx”:
import { hydrateRoot } from "react-dom/client";
import React from "react";
import App from "./App";
// Hydrate the HTML the server sent
hydrateRoot(document, <App message={window.__INITIAL_DATA__} />);Next, make the server entry file.
6. Make “server.js” in the root:
import express from "express";
import { renderToPipeableStream } from "react-dom/server";
import App from "./src/App.js";
const app = express();
// Serve the client bundle (built later with webpack)
app.use(express.static("dist"));
app.get("*", (req, res) => {
const { pipe } = renderToPipeableStream(
<App message="Hello from the server!" />,
{
onShellReady() {
res.setHeader("Content-Type", "text/html");
pipe(res);
},
}
);
});
app.listen(3000, () => {
console.log("SSR app running at http://localhost:3000");
});Next, it’s time to bundle the client code.
7. We need webpack to build “client.jsx” into a browser-ready file. Create a file “webpack.config.js”:
const path = require("path");
module.exports = {
entry: "./src/client.jsx",
output: {
path: path.resolve(__dirname, "dist"),
filename: "bundle.js",
},
module: {
rules: [
{
test: /\.(js|jsx)$/,
exclude: /node_modules/,
use: {
loader: "babel-loader",
options: {
presets: ["@babel/preset-env", "@babel/preset-react"],
},
},
},
],
},
resolve: {
extensions: [".js", ".jsx"],
},
};8. Then build the client bundle:
npx webpackAll that’s left is to run the server!
9. Start the server with:
node server.jsWith these steps, you now have a hand-rolled SSR in React. The server generates HTML with your custom message, then the client hydrates it.
Common mistakes to avoid in React Server Side Rendering
For those new to React Server Side Rendering, implementation, especially through method two, can take practice. There are more than a few tripwires waiting to trip you up!
We’re here to help you minimize hassle. So, here are some of the most common mistakes SSR first-timers often make - and what to do about them:
- User browser-only APIs on the server: you’ll encounter problems when things like “document” and “localStorage” don’t exist on the server. The answer is to only use them inside “useEffect” or client-only code paths.
- Hydration mismatch: sometimes your server’s HTML doesn’t match up with what React tries to render on the client. For example, your server might try to render today’s date, but the client might render a different one. This can cause big problems. The solution is to keep server and client logic deterministic and pass pre-fetched data from the server as props so both sides see the same values.
- Blocking requests with slow data fetching: users staring at a blank page? Your server could be waiting on slow APIs. There are two fixes: firstly, to use streaming SSR (so some content loads fast) and secondly to set fallbacks.
- Forgetting caching: server overload is a common problem with SSR as every request generates a fresh page. Always remember to cache responses wherever possible. For example, cache per-page or per-API call.
- Bundling too much JavaScript: a giant JavaScript bundle can really drag down your interactivity if you’re not careful. The key is to split your bundles and to only hydrate what really needs to be hydrated. Don’t try and take on too much!
Final Thoughts
React Server Side Rendering is your ticket to faster page load times and better SEO discoverability, but it takes some getting used to. Luckily, you have two basic options: the quicker, Next.js framework method, and the longer, but more customisable, DIY method.
We recommend the first method if you want reliable SSR with less effort. However, if you’re running complex sites and need a higher level of customisation, it’s worth learning how to achieve SSR manually.
If you follow our steps and take care to watch out for the potential pitfalls we’ve pointed out, you’ll be a React Server Side Rendering pro in no time. Good luck!
Frequently Asked Questions
Is SSR better than CSR?
It’s not necessarily “better” in every situation. SSR gives faster first content and SEO benefits, but Client Side Rendering (CSR) is better for highly interactive web apps. Many apps use a hybrid approach with both.
Does SSR make my app slower?
That’s a complicated question. Technically, SSR can be slower on the server-side per request. However, users will usually actually see content faster. And don’t forget: caching can help to offset server load and speed things up!
Can all websites use SSR?
Most can, yes. However, not all. Some ultra-dynamic dashboards or apps with heavy client interactions might benefit more from CSR or a hybrid strategy, instead.
What’s the difference between “renderToString” and “renderToPipeableStream”?
It all comes down to how the HTML is actually generated. “renderToString” generates the HTML all at once - this is called “blocking”. “renderToPipeableStream” streams HTML as it becomes ready, so some aspects can load quicker while dealing with slower aspects.
Can React SSR fetch data?
Yes! You fetch data on the server before rendering, then pass it as props to components so the HTML contains all the content.
Should I use Next.js or build SSR manually?
That’s a tricky question, as it depends on your coding capabilities and your needs. Next.js is definitely faster and simpler. But a manual SSR approach offers more in the way of customisation.
Tapptitude
Tapptitude is a mobile app development company specialized in providing high-quality mobile app development services, and a top-rated app company on Clutch.
