Learn about server-side rendering in React

What is Server-Side Rendering?

Server-Side Rendering (SSR) is a technique for rendering web pages on the server side before they are sent to the browser. In contrast to Client-Side Rendering (CSR), where the page is built by the browser from data provided by the server, SSR generates the complete HTML on the server. This makes the website load faster, which is beneficial for users with slower internet connections or older devices.

How does Server-Side Rendering work in React?

Server-Side Rendering (SSR) in React is the process of rendering application components on the server before they are sent to the user’s browser. Instead of relying on the browser to execute JavaScript and dynamically create the user interface, the server renders the finished HTML, which is immediately delivered and displayed in the browser when the page is loaded.

Technical overview of the SSR process:

Server-Side Rendering (SSR) in React is the process of rendering application components on the server before they are sent to the user’s browser. Instead of relying on the browser to execute JavaScript and dynamically create the user interface, the server renders the finished HTML, which is immediately delivered and displayed in the browser when the page is loaded.

Technical overview of the SSR process:

1. Request to the server: When a user opens a page, a request is sent to the server that runs the React application.

2. Rendering components: The server uses React to render the application components into HTML. All data needed to display the page is fetched and used on the server.

3. Sending HTML to the client: The finished HTML is sent to the browser, making the website immediately visible.

4. Hydration: Once the HTML has been loaded, the React application activates the interactive functions on the website, i.e. it runs the JavaScript code in the browser so that the components can react to user actions.

Example of SSR implementation in Next.js:

Below you will find a practical example of implementing Server-Side Rendering (SSR) in a Next.js application. For demonstration purposes, we will create a simple blog page that displays a list of articles retrieved from the API.

Step 1: Creating a Next.js project

We start by creating a new Next.js project:

npx create-next-app@latest my-blog-app
cd my-blog-app

Step 2: Install dependencies (if needed)

If you are using a clean environment, make sure you have all the basic dependencies installed:

npm install react react-dom next

Step 3: Configure the environment (.env)

Create an .env.local file in the project’s root directory and add the URL to the API to it:

API_URL=http://localhost:3000/api

To be safe, don’t commit this file – instead, you can add .env.example with placeholders.

Step 4: Create the endpoint API

Next.js allows you to create local API endpoints in the pages/api directory.

Create a pages/api/articles.js file with a sample list of articles:

// pages/api/articles.js
const articles = [
  { id: 1, title: 'What is SSR in React?', author: 'Emily Johnson' },
  { id: 2, title: 'Introduction in React 18', author: 'Jan Kowalsky' },
];

export default function handler(req, res) {
  res.status(200).json(articles);
}

Step 5: Create a page /articles with SSR.

Create a pages/articles/index.js file. In it, retrieve data from the server-side API using React Server Components:

export default async function ArticlesPage() {
  const res = await fetch(`${process.env.API_URL}/api/articles`, { cache: 'no-store' });
  const articles = await res.json();

  return (
    <div>
      <h1>Technical articles</h1>
      <ul>
        {articles.map((article) => (
          <li key={article.id}>
            <strong>{article.title}</strong> – {article.author}
          </li>
        ))}
      </ul>
    </div>
  );
}



export async function getServerSideProps() {
  const res = await fetch(`${process.env.API_URL}/api/articles`);
  const articles = await res.json();

  return {
    props: {
      articles,
    },
  };
}

export default ArticlesPage;

This will generate the article list on the server side and send it to the client as finished HTML.

Step 6: Start the development server
Fire up the local Next.js server:

npm run dev

And then go to http://localhost:3000/articles.

Step 7: Verify SSR operation

If you go to “View page source” in your browser, you will see that the content of the articles is directly in HTML – that is, it was rendered on the server side (SSR), not by JavaScript on the client.

Hydration in React: A key step in integrating SSR and client-side interactivity

Hydration is the process by which a React application, previously rendered on the server side (SSR), becomes fully interactive when loaded in the user’s browser. With SSR, the user receives the complete HTML code, which speeds up the display of the page. Then, on the client side, React “revives” this static structure, attaching event handlers and restoring component state.

React 18 introduced a new method hydrateRoot(), replacing the earlier hydrate() function. hydrateRoot() allows for more efficient hydration, supporting asynchronous streaming and working with React’s new functions. An example implementation of hydrate looks like the following:

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

const container = document.getElementById('root');
hydrateRoot(container, <App />);

It is crucial that the HTML structure generated on the server is identical to that on the client side. Mismatches can lead to warnings in the development console or errors in application performance. In situations where mismatches are unavoidable (e.g., dynamic data), you can use the suppressHydrationWarning={true} attribute for a specific element:

<p suppressHydrationWarning={true}>{dynamicContent}</p>

However, it should be used with caution, as overuse can mask real hydration problems.

The hydration process is crucial to ensure the smooth operation of server-side rendered React applications. A thorough understanding of this mechanism allows you to effectively combine the advantages of SSR, such as fast content display, with the interactivity characteristic of client-side rendered applications.

Benefits of using SSR in React applications

Server-Side Rendering in React offers many benefits that translate into better application performance and improved user experience. Here are the most important ones:

Content Personalization:

SSR enables dynamic delivery of content tailored to users’ preferences, such as language, location or preferences. This leads to more personalized interaction and better tailored content.

Incremental Content Loading (Lazy Loading):

With SSR, key elements of a page can be loaded immediately, while less important sections can be recharged later – a technique known as lazy loading. This allows the most important content to be displayed more quickly, improving the responsiveness of the application and reducing user wait times.

In React (and especially in Next.js), this can be achieved by dynamically importing components that are not needed right away when the page loads. This way, the application code is divided into smaller fragments, loaded only when needed. An example of a dynamic import with SSR disabled:

import dynamic from 'next/dynamic';

// This component will not be rendered on the server
const Sidebar = dynamic(() => import('../components/Sidebar'), { ssr: false });

export default function Page() {
  return (
    <div>
      <h1>Homepage</h1>
      <Sidebar />
    </div>
  );
}

You can also use the loading=”lazy” attribute next to images or iframes so that the browser only loads them when they are close to the viewport:

<img src="/product.jpg" alt="Produkt" loading="lazy" />

In Next.js, it is useful to use the component with priority and loading=”lazy” to optimize images:In Next.js, it is useful to use the <Image /> component with priority and loading=”lazy” to optimize images:

import Image from 'next/image';

<Image
  src="/product.jpg"
  alt="Produkt"
  width={400}
  height={300}
  loading="lazy"
/>

Optimization of application status management:

The server transmits the initial status of the components, which enables the fully configured application to be displayed immediately on the client side. This minimizes delays and errors during startup.

Better SEO optimization:

SSR significantly improves search engine visibility. The server delivers finished HTML to the browser. This allows indexing robots to easily read the content of the page, which increases the chances of higher search engine rankings.

How does Server Side Rendering affect SEO?

SSR improves performance and SEO because the server delivers finished HTML. This, in turn, makes it easier for search engine robots to index content faster and more correctly. With CSR, dynamically generated content can be more difficult to index. SSR also ensures greater consistency of application operation across different browsers, eliminating problems with the support of specific functions.

This solution also gives you more control over how your application is presented in search results and on social media. It is worth using techniques that support SEO in the SSR environment:

– in Next.js, you can use the Head component to dynamically set the page title, description, and other relevant meta data

– in applications using SSR, it is worth ensuring that the sitemap (sitemap.xml) is automatically generated and updated. Next.js does not generate it by default, but you can use a library such as next-sitemap to generate a pre-rendered map:

// next-sitemap.config.js
module.exports = {
  siteUrl: 'https://example.com',
  generateRobotsTxt: true,
  changefreq: 'weekly',
  priority: 0.7,
};

– Open Graph and Twitter Cards tags – to make your pages look good when shared on social media, it’s a good idea to use Open Graph and Twitter Card tags – also by next/head. This is especially important in marketing and e-commerce projects, where the appearance of the shared link can affect conversions. Here we especially recommend the article React vs SEO to explore this topic more deeply.

Challenges and limitations of Server-Side Rendering

Although Server-Side Rendering (SSR) in React offers numerous advantages, it also brings with it certain challenges:

– Application state management: SSR requires state synchronization between the server and the client. The hydration process, which makes the page interactive after loading, can be difficult to manage, especially in more complex applications.

Server load: Each user request requires the generation of full HTML. This increases the server load, especially with high traffic. Caching is necessary to reduce this problem.

Cache optimization: Cache management in SSR is more complicated. It is necessary to balance loading speed with content freshness.

Integration with existing projects: Adding SSR to applications that used CSR may require a redesign of the architecture, which increases development time.

Time and complexity: SSR increases the complexity of the application, which can affect the time and cost of development and maintenance.

– Increased hosting fees – Server-side page generation requires more computing resources, which may require more expensive hosting plans or scalable cloud infrastructure. For high-traffic applications, operating costs can increase significantly compared to the traditional CSR approach.

Server costs – how can they be minimized?

Implementing Server-Side Rendering can generate higher server maintenance costs, especially with high traffic. Fortunately, there are several proven techniques that allow you to minimize these expenses without sacrificing the performance and quality of your application:

1. Cache

Using a cache allows you to store previously generated HTML pages and serve them to subsequent users without having to render them on the server again. Caching can be applied at various levels – from caching HTTP responses (e.g. with the help of CDN) to caching data in a database. This means that the server does not have to process the entire application logic every time, which reduces the load on the infrastructure and the consumption of resources.

2. ISR (Incremental Static Regeneration)

ISR is an approach that combines the advantages of SSR and static page generation. The pages are rendered statically on the first request and then refreshed in the background at a defined interval (e.g. every few minutes). The user gets an immediate response from the cache and the content is updated asynchronously. This significantly reduces the number of live renderings, reducing server load and costs.

3. Edge Rendering

Edge rendering involves moving part of the rendering from the main server to distributed CDN servers closer to the end user. This not only reduces page load times, but also relieves the load on the central infrastructure. Platforms such as Vercel or Cloudflare Workers offer support for this type of solution, which helps optimize costs and increase scalability.

4. Serverless Functions

Instead of keeping a server running all the time, you can use serverless functions that only run when requested and for a short period of time. You only pay for the time the function is running, which is more economical compared to traditional servers that run non-stop. This is especially beneficial with irregular or moderate traffic, when it is not profitable to maintain a constant infrastructure.

Popular tools and libraries supporting Server-Side Rendering in React

Server-Side Rendering (SSR) in React can be supported by several popular tools and libraries that simplify the implementation of this technique.

Next.js is one of the most popular tools that simplifies the implementation of SSR in React applications. It enables dynamic page rendering on the server and provides functions such as getServerSideProps, which allows you to retrieve data on the server before rendering. Next.js is perfect for creating SEO-friendly applications and those that require dynamic content.

Tanstack.com – (formerly React Query) is a toolkit that, although not directly concerned with server-side rendering, perfectly supports SSR through advanced data state management and synchronization with the backend. Thanks to features such as data prefetching and state dehydration/hydration, TanStack Query enables efficient data retrieval on the server and its smooth transfer to the client, which significantly speeds up the rendering process and improves the performance of SSR applications. It integrates perfectly with Next.js, making it a valuable tool for modern server-side React applications.

Gatsby also supports SSR. This tool is best suited for creating websites with many fixed elements, e.g. blogs or news portals, where a large part of the content can be generated in advance and the dynamic components can be reloaded using SSR.

Razzle is a more flexible tool that offers fewer limitations compared to Next.js and Gatsby, but requires more advanced configuration. It is often used in projects requiring custom Webpack configuration and full control over the application build process.

The choice of tool depends on the needs of the project. Next.js is best for general SSR use cases, Gatsby for static content pages, and Razzle for projects that require flexibility and customization.

Best practices for implementing SSR in React

When implementing Server-Side Rendering (SSR) in React, it is worth using several methods to optimize the performance and scalability of the application.

Minimize server queries:

Limit the number of queries the server has to handle during rendering. Retrieve key data once and cache less frequently changing information to reduce server load and speed up page loading.

Use caching:

Use caching of server responses and resources to avoid unnecessary queries and speed up content delivery to users. Make sure that the cache mechanisms are properly configured to provide up-to-date data.

Data prefetching:

Before the user accesses subsequent pages, try to download the necessary data in advance. This minimizes the waiting time for loading the next subpages.

Application scaling:

For larger applications, use techniques such as load balancing and dynamic server scaling. This way, you can handle a higher load and ensure that the application runs smoothly with an increasing number of users.

Alternatives to Server-Side Rendering: CSR and SSG.

Rendering web pages can be done in a variety of ways, and Server-Side Rendering (SSR) is just one of the available approaches. Depending on the needs of the project, other strategies are also worth considering: Client-Side Rendering (CSR) and Static Site Generation (SSG).

Examples of CSR and SSG implementation in Next.js

Client-Side Rendering (CSR):

import dynamic from 'next/dynamic';

const Chart = dynamic(() => import('../components/Chart'), { ssr: false });

export default function DashboardPage() {
  return (
    <div>
      <h1>Statistics</h1>
      <Chart />
    </div>
  );
}

This component (Chart) will not be rendered on the server – only after the JavaScript is loaded in the browser. This is an ideal approach for window-dependent components, such as charts, maps or animations.

Static Site Generation (SSG):

With getStaticProps Next.js, you can generate static pages at the application build stage:

export async function getStaticProps() {
  const res = await fetch('https://api.example.com/products');
  const products = await res.json();

  return {
    props: {
      products,
    },
  };
}

export default function ProductsPage({ products }) {
  return (
    <ul>
      {products.map(p => (
        <li key={p.id}>{p.name}</li>
      ))}
    </ul>
  );
}

The website is generated as static HTML during the build and immediately served to the user. It is an ideal solution for blog pages, landing pages or product catalogs.

Client-Side Rendering (CSR) means that all rendering logic takes place on the browser side. The server only sends “empty” HTML and JavaScript files, which are then run on the user’s side. This solution is easy to implement and works great in SPA (Single Page Application) where SEO is not crucial, and interactivity and smooth switching of views are more important.

Static Site Generation (SSG), on the other hand, generates ready-made HTML pages as soon as the application is built (e.g. during implementation). This allows the server to deliver static files very quickly, which significantly improves performance and loading time. SSG is ideal for sites with rarely changing content, such as blogs, documentation or promotional sites.

Comparing CSR and SSG:

• CSR offers full flexibility and dynamism, but at the expense of slower first page loading and weaker SEO.
• SSG ensures lightning-fast loading and great SEO optimization, but is less flexible when it comes to dynamic data.

In addition, Incremental Static Regeneration (ISR) is becoming increasingly popular – a hybrid technique that combines the advantages of SSG and SSR. ISR allows individual pages to be updated live without having to rebuild the entire site, which is great for sites that combine static and dynamic content.

How does SSR affect Core Web Vitals: LCP, FCP and CLS?

Server-side rendering (SSR) in React has a significant impact on Core Web Vitals. By generating HTML on the server, SSR reduces the time it takes for the first contentful paint (FCP) and the largest contentful paint (LCP) because the user receives the finished markup before JavaScript is loaded and executed. This eliminates delays related to client-side rendering. However, in the context of CLS (Cumulative Layout Shift), SSR does not guarantee improvement – if the layout is based on dynamic components or unspecified image and font sizes, shifts may occur after styles and scripts have been loaded. Therefore, it is crucial to use layout stabilization techniques, such as reserving space for images and loading fonts in a way that does not cause jumping.

SSR use cases in React applications

SSR is particularly useful when loading speed, SEO and dynamic data are crucial. For example:

• E-commerce:

SSR is ideal for online shops where fast loading of product pages and dynamic content updates are crucial. Thanks to SSR, users can browse offers faster. This affects their positive experience and also improves SEO results.

• News websites:

On news websites, fast access to content is a priority. SSR enables instant page loading and easier indexing by search engines. This is crucial for SEO and user satisfaction, especially with slower connections.

• Social media platforms

SSR ensures that content on platforms with dynamic content such as comments or user updates is displayed quickly. Availability is crucial for building user engagement.

Summary

Server-Side Rendering (SSR) in React improves performance and SEO, especially in e-commerce applications and news sites. SSR dynamically renders content, but requires more server resources and complex application state management.

Tools supporting SSR include Tanstack, Next.js and Gatsby. It is worth implementing SSR where loading speed and SEO optimization are important, which translates into a better user experience.

FAQ – Frequently Asked Questions

Is SSR faster than CSR?
Yes, server-side rendering (SSR) generally ensures faster loading of the first page content compared to client-side rendering (CSR), especially with a slower internet connection. This is because the finished HTML is generated on the server and sent to the browser immediately. However, please note that the full interactivity of the page may appear a little later, as the React components need to be hydrated on the client side.

How can I convert React to server-side rendering?
The easiest way to implement SSR in a React application is to use a framework such as Next.js, which has built-in support for server-side rendering. This allows you to use functions such as getServerSideProps, which enable dynamic page generation on the server.

Does Next.js support SSR?
Yes, Next.js natively supports server-side rendering. It allows you to create both static pages (SSG) and dynamically rendered pages on each request (SSR). This allows you to adapt the rendering strategy to the specific needs of your application.

Do hooks work in SSR?
Yes, many React hooks work correctly in SSR, especially those responsible for rendering logic, such as useState, useContext or useMemo. However, hooks such as useEffect or useLayoutEffect, which refer to the browser environment, are not executed on the server and only start running after the page is loaded by the client.