CSR, SSR, pre-rendering: Which rendering technique to choose?

Written by Fimber Elemuwa✏️

When building modern web applications with Next.js, selecting the right rendering technique is critical for optimal performance and a smooth user experience. Next.js has three main rendering options: client-side rendering (CSR), server-side rendering (SSR), and pre-rendering.

Each approach has unique characteristics, advantages, and limitations:

CSR vs. SSR vs. Pre-rendering

Deciding which technique to use can significantly impact your application's speed, SEO performance, and scalability. In this article, we'll examine each rendering method in detail, exploring their use cases, and providing examples to help you understand when to leverage each. By the end, you'll clearly understand which best aligns with your development goals, allowing you to maximize your application's performance and user experience.

Let's jump in!

Client-side rendering (CSR)

Before frameworks like React, Vue, and Next.js, most website content was rendered on the server and sent to the browser as static HTML. While this approach worked, it severely limited interactivity, making it challenging to build highly dynamic pages such as analytics dashboards. Client-side rendering (CSR) changed this by shifting the rendering process to the browser using JavaScript.

In CSR, the browser initially requests a single HTML file, which serves as the entry point for the application. This file includes links to the necessary JavaScript files that handle rendering the content and requesting any additional data needed. This process allows for more interactive, dynamic user experiences because content updates happen directly in the browser without reloading the entire page.

In Next.js, CSR is no longer the default rendering strategy. This is due to the recent shift in the ecosystem of pre-rendering content on the server with React Server Components (RSC) and server-side rendering (SSR) – concepts we'll explain in a bit. To render a client-side component, we must lazy load it using the exported dynamic function with the ssr option disabled:

"use client";

import dynamic from "next/dynamic";

const Header = dynamic(() => import("../components/header"), {

  ssr: false,

});

Advantages of client-side rendering

• Rich interactivity: CSR allows for dynamic and interactive user interfaces, providing seamless page transitions and smooth content updates without reloading the page
• Faster updates after initial load: Once the initial JavaScript files are loaded, interactions such as fetching new data or updating the UI happen quickly without needing full page reloads
• Lower server load: Because rendering happens on the client side, the server doesn’t need to process each request, reducing the overall server load

Disadvantages of client-side rendering

• Slower initial load time: The initial load can be slower because the browser has to download and execute JavaScript files before rendering the content, leading to a delay in displaying meaningful content
• SEO challenges: Search engines typically struggle to index JavaScript-heavy pages, as the content is not immediately available in the static HTML file
• Potential performance issues on slower devices: CSR requires the user's device to do more work, potentially leading to performance issues on devices with slower CPUs or limited resources

Server-side rendering (SSR)

An alternative to CSR is server-side rendering (SSR), which is a web development technique in which the server generates the HTML content of a webpage and sends it to the client's browser. Unlike client-side rendering (CSR), where JavaScript on the client side dynamically renders the content, SSR pre-renders the HTML on the server before sending it down to the browser as HTML.

This means the browser receives the fully rendered HTML content and doesn't have to wait for JavaScript to render the initial content.

In Next.js, SSR is the default rendering strategy. You do not have to do anything special to render a component server-side.

Now, Next.js uses a relatively new terminology called 'Client' and 'Server' components, or 'React Server Components'. To put it simply, this enables you to execute asynchronous code exclusively on the server inside components.

I bring this up because there's another misconception that 'Client-side' components aren't rendered on the server. This is false. Next.js renders all components on the server by default unless you disable ssr explicitly.

To create a server-side rendered component, all you have to do is simply create the component and export it. Next.js will take care of the rest:

import React from "react";

export const Page = () => {

  const isServer = typeof window === "undefined";

  console.log(isServer ? "Server" : "Client");

  return <h1>HelloWorld</div>;

};

Advantages of server-side rendering

• Faster initial load time: The server typically has a faster internet connection and is closer to remote data stores than the client. This reduces the latency of the initial request and response time, meaning users can see the content quickly, without waiting for JavaScript to execute
• Improved SEO: With SSR, the browser receives the fully rendered HTML content and doesn't have to wait for JavaScript to render the initial content. Search engines can crawl the fully-rendered HTML, improving indexing and search visibility
• Better performance on slower devices: Because the rendering is handled on the server, users on devices with lower computing power experience better performance

Disadvantages of server-side rendering

• Higher server load: Rendering on the server increases its workload, which may lead to higher operational costs, especially for large-scale applications
• Increased complexity: Implementing SSR can add more complexity to your application, as you need to handle both client and server-side rendering
• Potential performance issues for dynamic content: For highly dynamic pages that change frequently, SSR can become inefficient, as the server has to re-render the content on every request, leading to increased latency

Pre-rendering

Pre-rendering is a technique where static HTML files are generated at build time, meaning the HTML for a given page is created before any request is made by the user. This HTML is served directly to users when they visit the site, offering a balance between server-side rendering (SSR) and client-side rendering (CSR).

In contrast to SSR, which renders HTML dynamically on each request, pre-rendering generates the HTML once during the build process. This HTML is then cached and reused, reducing server load while providing fast initial page load times, similar to SSR.

However, because the pages are rendered in advance, there is a potential for serving outdated or "stale" content with pre-rendering. You can circumvent this by using a free tool like Prerender.io that refreshes the cache on its own after some time.

Next.js supports pre-rendering out of the box with its getStaticProps function, which allows pages to be pre-rendered at build time. Here’s an example:

// pages/index.js

import React from 'react';

const HomePage = ({ data }) => {
  return (
    <div>
      <h1>Prerendered Page</h1>
      <p>Data fetched at build time:</p>
      <pre>{JSON.stringify(data, null, 2)}</pre>
    </div>
  );
};

// This function is called at build time
export async function getStaticProps() {
  // Fetch data from an API
  const res = await fetch('https://jsonplaceholder.typicode.com/posts');
  const data = await res.json();

  // Pass data to the page component via props
  return { props: { data } };
}

export default HomePage;

Tools to implement pre-rendering

• Next.js: Next.js supports static site generation with getStaticProps and getStaticPaths, enabling efficient pre-rendering
• Gatsby: Gatsby is a React-based framework focused on static site generation (SSG), making it ideal for pre-rendering large-scale sites with fast page loads
• Prerender.io: A tool that pre-renders JavaScript-heavy websites by rendering pages using headless browsers and serving the static HTML to search engines
• Nuxt.js: Nuxt.js is a framework for Vue.js that supports static site generation and pre-rendering through nuxt generate

Advantages of pre-rendering

• Combines benefits of CSR and SSR: Pre-rendering offers fast initial load times like SSR, while minimizing server load similar to CSR
• Improved SEO: Because pages are rendered into static HTML before users or crawlers request them, it ensures that search engines can easily index all content, even JavaScript-rendered content
• Faster initial load time: Because HTML is served directly from a static file, users experience faster initial load times, even on slow devices or networks

Disadvantages of pre-rendering

• Potential for stale content: Because HTML is generated at build time, if the underlying data changes frequently, users may receive outdated content until the next build
• Increased build time: The initial build process can take a long time for large sites with many pages, especially if there are many dependencies or dynamic data to fetch

Differences between CSR, SSR, and pre-rendering

Rendering process

• CSR (client-side rendering): Content is rendered on the client side using JavaScript. The server sends a minimal HTML shell, and the content is generated in the browser after JavaScript execution
• SSR (server-side rendering): Content is rendered on the server and sent as fully-formed HTML. When a user requests a page, the server processes and delivers the complete HTML content to the browser
• Pre-rendering (static site generation): HTML is generated during the build process and served as static files. These pre-rendered pages are delivered to users without additional server-side processing

Performance considerations

• CSR: Potentially slower initial load because the browser needs to download and execute JavaScript to render the content. However, once loaded, interactions are fast because most of the application runs in the client’s browser
• SSR: Faster initial load because the server sends fully-formed HTML, allowing content to display immediately. However, there may be a slight lag when interacting with dynamic content that requires additional client-side rendering
• Pre-rendering: Very fast initial load because static HTML is served directly. However, if the content changes frequently, it may struggle with dynamic updates, leading to stale or outdated pages

SEO implications

• CSR: SEO can be challenging as the content may not be fully visible to search engine crawlers at the time of the page load due to delayed rendering. Search engines may struggle to index pages relying solely on JavaScript
• SSR: Better SEO performance because the content is readily available as HTML when search engines crawl the page. SSR ensures that important content is available to crawlers right away
• Pre-rendering: Excellent for SEO because fully rendered HTML is served upfront. Search engines can index the static pages immediately, making it ideal for SEO-friendly content delivery

Flexibility and maintenance

• CSR: Highly flexible for dynamic content updates and real-time interactions, as the rendering is managed on the client side. However, this requires complex client-side handling of the data and logic
• SSR: Balances performance and flexibility, offering server-side content delivery while still allowing dynamic client-side updates. However, it adds complexity to development and increases server load
• Pre-rendering: Serving static content is simple and highly performant, but it can become outdated quickly if the content changes often. Maintaining fresh content requires frequent rebuilds and updates, leading to higher maintenance efforts

When to choose client-side rendering:

• Creating highly dynamic and interactive applications (e.g., single-page applications, dashboards, social media platforms)
• Your application doesn’t prioritize SEO, or you’re using tools like dynamic rendering to serve pre-rendered content to bots
• Your application has frequent real-time updates and user interactions

When to choose server-side rendering:

• Ideal for content-heavy websites like e-commerce platforms, blogs, and news sites that require fast initial load times and strong SEO performance
• SSR balances performance and flexibility, making it ideal for websites that combine static and dynamic content, such as product pages with frequent updates

When to choose pre-rendering:

• Perfect for websites with mostly static content that needs to be SEO-optimized and load quickly (e.g., marketing pages, documentation websites, blogs that don’t frequently update)
• Maintaining dynamic content updates often requires using tools like Prerender.io that serve search engine bots the static form of your page while giving users the dynamic version; this is ideal for SPAs and e-commerce platforms

Hybrid approaches: Combining CSR, SSR, and pre-rendering

A hybrid approach that combines CSR, SSR, and pre-rendering may be the best solution for many projects. Frameworks like Next.js allow developers to use a mix of these rendering techniques for different pages or components within the same site. For example, you can pre-render static marketing pages, use SSR for dynamic product pages, and implement CSR for interactive features like user dashboards.

This hybrid model allows you to optimize performance and SEO for content-driven pages while still enabling dynamic, real-time interactivity for user-driven features. It gives you flexibility in balancing the benefits of each rendering approach based on your project's specific needs.

Conclusion

Choosing the right rendering technique for your Next.js application — whether it's client-side rendering (CSR), server-side rendering (SSR), or pre-rendering — depends largely on your project's requirements for performance, SEO, and content dynamism.

CSR is ideal for highly interactive, real-time applications but can pose challenges for SEO. SSR balances fast initial load times with good SEO performance, making it a great option for content-heavy websites. Pre-rendering excels in scenarios where static content is preferred and offers the best SEO and performance benefits but requires maintenance for frequently changing content.

Each rendering technique has its own strengths and trade-offs, and Next.js's flexibility allows you to combine these approaches based on the needs of different components or pages within your application. By carefully considering your project's goals, user experience, and performance needs, you can choose the optimal rendering strategy or hybrid approach, ensuring that your application delivers the best experience for users and search engines.

LogRocket: Full visibility into production Next.js apps

Debugging Next applications can be difficult, especially when users experience issues that are hard to reproduce. If you’re interested in monitoring and tracking Redux state, automatically surfacing JavaScript errors, and tracking slow network requests and component load time, try LogRocket.

LogRocket is like a DVR for web and mobile apps, recording literally everything that happens on your Next app. Instead of guessing why problems happen, you can aggregate and report on what state your application was in when an issue occurred. LogRocket also monitors your app's performance, reporting with metrics like client CPU load, client memory usage, and more.

The LogRocket Redux middleware package adds an extra layer of visibility into your user sessions. LogRocket logs all actions and state from your Redux stores.

Modernize how you debug your Next.js apps — start monitoring for free.