What is server-side rendering? A complete guide with code examples

Server-side rendering (SSR) allows you to improve the performance and SEO of your web applications by rendering web pages on a server and delivering the fully rendered HTML to users and search engines.

In this guide, we explore SSR and how it works, using Next.js as an example. We also explain its benefits and drawbacks, and compare it to other rendering methods, including client-side rendering (CSR), static site generation (SSG), and incremental static regeneration (ISR).

What is SSR (server-side rendering)?

Server-side rendering is when web pages are rendered on the server (in response to user requests). The server generates a fully rendered HTML page, which is then returned to the browser as HTML.

This is in contrast to client-side rendering (CSR), where pages are rendered in the browser, instead of on the server. CSR usually results in slower page loads than SSR, because it usually involves the browser having to download and execute JavaScript files to dynamically render a page. CSR is the cheaper option as you don't have to pay for server resources; however, offloading this work to the client side can result in slow page load times, particularly if your users' computers are low spec or overloaded.

Some other rendering methods have also been created to try to balance the positives of SSR and CSR. Static site generation (SSG) is one of these newer methods. With SSG, the HTML is pre-rendered at build time. Like SSR, the rendering happens on the server — however, unlike SSR, the HTML is pre-rendered and served as static files (as opposed to it being rendered on request). This combines the performance and SEO benefits of SSR (in fact, the performance is even better than SSR because each page only needs to be rendered once, at build time) with the cost benefits of CSR. 

However, with SSG, the downside is that content becomes less fresh over time if it's pre-rendered and not generated again periodically. To solve this issue, incremental static regeneration (ISR) allows you to combine SSR with SSG. Like with SSG, the HTML is pre-rendered at build time, but ISR allows these pages to be updated dynamically, either at regular intervals or when an event occurs.

How server-side rendering works

Here’s a step-by-step workflow for the rendering of a web page when server-side rendering is in play.

1. User request: A user enters an address in the browser, which sends a request for that page to the server.

2. Identifying the page: The server processes the request, working out which page the user is requesting.

3. Fetching data: The server does some backend logic, such as fetching any data required to generate the page.

4. Generating HTML: The server generates a static HTML document, by inserting any data fetched from the previous step into the page template.

5. HTML displayed: The HTML is sent to the browser and the page is displayed to the user. Initially, this is just plain HTML — no JavaScript is yet added.

6. Downloading JavaScript: The linked JavaScript files from the HTML get downloaded to the browser.

7. Hydration: When the JavaScript is executed, it attaches event listeners and initializes interactive elements, adding interactivity to the page. For example, an ecommerce product listings page might only allow users to add products to their basket after hydration, but they could still browse the products while waiting for this functionality to load.

Benefits of server-side rendering

SSR has many benefits over CSR, especially when it comes to performance, SEO, UX, and security.

Performance: SSR allows users to view HTML content in the browser more quickly than CSR does, giving a faster time to first byte (TTFB). This is because the user doesn't have to wait for JavaScript to be executed before they can view the HTML. SSR also offers even more performance improvements if you have users with slow, old devices, because it doesn't rely on their potentially slow browsers to do the rendering.

SEO: SSR still holds an advantage over CSR when it comes to SEO. With SSR, a page is fully rendered as soon as it reaches the browser (and therefore, web crawlers), meaning that all your content can be indexed by web crawlers from the start with no delays, which is a metric they prioritize when ranking pages. With CSR, the content is rendered in the browser using JavaScript, so the JavaScript must be loaded first. 

Although Google has recently made some improvements with CSR, it's still not as good as SSR for SEO. It's worth noting that SSG and ISR have similar SEO advantages to SSR; however, SSR has a slight edge when it comes to highly dynamic sites that continually update in real time — because the search engine always crawls the most up-to-date content.

UX: Since content can be displayed more immediately with SSR, the UX benefits are obvious — there’s a much lower chance of a blank white screen being displayed to the user while they're waiting for content to load.

Security: Applications using SSR are much less likely to be exposed to client-side vulnerabilities (such as cross-site scripting) than those using CSR. This is because SSR helps to minimize the amount of JavaScript executed in the browser. Also, if your application uses sensitive data, this will all be processed on the back end, meaning most sensitive APIs won't be exposed to potential hackers.

Disadvantages of server-side rendering

Despite the benefits of SSR, it does come with a few drawbacks.

Cost: Since all the rendering for SSR happens on the server, and rendering happens every time a page is requested, there will be increased server load, which is costly. For this reason, it might be tempting to go with the cheaper option (CSR) of farming out the cost of rendering to your user's machines. But given the performance problems with CSR, you may be better off considering SSG (where pages are only loaded once) or ISR (where you get to decide how often to reload your pages based on what you can afford and the level of performance you need).

Complexity of build setup: SSR has a more complex build setup, as you'll need to manage a backend server or use serverless functions to handle the on-request rendering. This adds development overhead — unlike CSR, where you can get away with using a static hosting service or CDN. 

State management: State management is more complex with SSR than CSR, due to the need to keep consistency between server-side and client-side states after JavaScript hydration. After hydration, you need to ensure the client- and server-side states match exactly, because if they don't, frustrating bugs can be introduced. 

You won't have this problem with CSR because all state management is done on the client side, meaning no matching is required. SSG actually works the same as CSR here — despite pages being pre-rendered on a server, they're actually served statically from a CDN, so there's no need to reconcile states. 

ISR can also have mismatched states, but it may happen less frequently than SSR. One reason for this is that many state mismatches come from user-specific data and ISR doesn't render any user-specific data. Another is that regeneration only happens occasionally and not on every request. This means that you're likely to experience state management bugs less often with ISR.

Best use cases for server-side rendering

Server-side rendering is usually the best choice for real-time, content-heavy sites with dynamic or user-specific content, or when SEO and security are strong concerns. 

Real-time, content-heavy sites with dynamic or user-specific content: This includes large ecommerce platforms with features like location-based pricing or real-time stock availability, blogs with personalized content, healthcare apps such as patient portals, or financial services applications like online banking or stock trading apps. For all these use cases requiring real-time updates, SSR is the most suitable. 

SSG and ISR are unsuitable for pages with user-specific content because they cache and serve the same pre-prendered page for all users. However, it is possible to use a hybrid approach where you use SSR for user-specific pages and SSG or ISR for the others. CSR is less suitable for either dynamic or user-specific on very content-heavy sites (due to performance).

SEO: When good SEO is a requirement, SSR ensures that your content can be immediately indexed by search engines by delivering fully rendered HTML to the browser. SSG and ISR are also similarly good for SEO, but CSR is less good, because it uses JavaScript to render the content on the client side, which can delay search engine indexing.

Security: SSR (and also SSG and ISR) are better for security than CSR, because they process and render content on the server side, which reduces the amount of JavaScript run in the browser, and consequently the risks of cross-site scripting.

How to implement server-side rendering

You can implement server-side rendering in many languages. Here, we show a step-by-step example using Next.js (with App Router).

1. Create a Next.js project

Use the below command to create a Next.js project. When it comes to selecting options, choose "No" for TypeScript and "Yes" for App Router.

npx create-next-app@latest contentful-ssr-example

2. Fetch the data on the server side

In your Next.js project, replace the existing home page code in app/page.js with the code below, which will be added to incrementally over the next few steps. First, create a function to fetch your data. You can use any data source you like, but here we're using the Cat Facts API because it doesn't require any authentication or extra setup.  If you've used Next.js Page Router in the past, it's worth noting that, unlike with Page Router, you don't need to use the getServerSideProps function for this.

To load this data in your browser, you'll need to add the code from the snippet below to your app/page.js file.

3. Render the HTML on the Next.js page component

In app/page.js, add the following code below your fetchData snippet. This code renders the HTML on the server side, and then exports the component so Next.js can send the fully rendered HTML to the front end.

4. Run your Next.js app 

npm run dev

5. Open your app in a browser

Access your site at http://localhost:3000 in your browser. You'll see that the HTML appears very quickly.

6. Add some JavaScript interactivity to your app

Add a JavaScript counter button to your app so you can see hydration occurring. You can do this by creating a counter in app/components/Counter.js and pasting in the following code:

You'll then need to add the counter to your home page:

7. Test the JavaScript on your new Next.js app

First, you'll need to throttle the loading speed of the page, which simulates a device on a slower network, allowing you to see more easily the gap between the HTML loading and the JavaScript loading. To do this, go to the Network tab of Chrome Developer Tools and change the throttling to 3G.

Now, load the new Next.js app in the same browser tab. You should see that the JavaScript takes longer to load than the HTML-only page. When the page with the fact initially loads, try immediately clicking the button and at first the counter won't advance. Once the JavaScript has been fully loaded, the counter will work.

Best practices for server-side rendering

Streaming and lazy loading: You can improve the perceived performance of SSR by rendering the most critical content first. This could include streaming your HTML in small chunks as it's generated (for example, using React Suspense) so that above-the-fold content gets loaded first, code-splitting your JavaScript so it only loads what you need, or using lazy loading to defer non-critical JavaScript.

Efficient data fetching: Make use of pagination or GraphQL to fetch only the data you need.

Caching: Reduce the load on the server by caching whatever you can. This could include page-level caching, API response caching, or CDN (edge) caching.

Reduce server load: Make further improvements to server load by using load balancing to distribute your requests, or by optimizing your database and API calls.

Combine the performance and SEO benefits of SSR with Contentful

Server-side rendering gives great performance and SEO benefits for apps with dynamic, real-time content. Make managing that content even easier with Contentful. With a headless CMS and SDKs for a variety of languages including React and Next.js, it's easy to get started. Try out our Contentful Next.js starter project and sign up to Contentful today.

Start building

Sign up for a free Contentful account

Use your favorite tech stack, language, and framework of your choice.

Subscribe for updates

Build better digital experiences with Contentful updates direct to your inbox.