SSR in Next.js

Next.js has become very popular recently because it is built on top of React. In addition, it has out-of-the-box features that are sometimes redundant to implement on React applications like server-side rendering, image optimization, Routing, and API Routes.

Not like a typical React app, Next.js supports SSR out of the box. This means that Next.js allows pages to be pre-compiled to static HTML, instead of having it all done by client-side JavaScript. Next.js routing and other built-in configurations are designed primarily for SSR (Server Side Rendering), and crawling towards SSG (Static Site Generation).

There are some instances where you don’t need SSR for your Next.js components. In this article, we’ll go over how you can disable SSR on the Next.js application.

Understanding Next.js rendering concepts such as SSR (Server-Side Rendering), CSR (Client-Side Rendering), and SSG (Static-Site Generation) can help you to understand this article. If you are not familiar with these concepts you can read this section at the bottom of this article.

The problem

Even though Next.js routing and other built-in configurations are specifically for SSR and SSG, there may be cases where you want to disable SSR (Server-Side Rendering) on one or some specific pages of your Next.js application. Some examples include:

If the component needs to access some properties only available in the browser, like the window or  localStorage.
You want a page to behave like a standalone React page without SSR.
Your application has an external dependency on browser APIs like window object.
You prefer the developer experience of Next.js over standalone React because of things like file-based routing, and fast compilation times, but don’t need SSR.
You want to disable SSR temporarily for debugging purposes.
You want to disable server-side rendering for a component or an entire page to lower your bundle size, as not all users will require this functionality.

How to opt-out of SSR in NextJS

1. React no ssr package

This is the quickest way to opt out of SSR. React-no-ssr provides a component that wraps non-SSR components.

Installation:

Usage:

Let’s assume that the <AdminPanel /> component is needed to be rendered on the client side. Here’s how we do it.

This way <AdminPanel /> component will only be rendered on the client after it has been mounted. It will not render while server-side rendered HTML is loading up in the browser.

With react-no-ssr you could also add preloader image or text that will be rendered before the component starts to render.

The <Preloader />  component will be rendered until <AdminPanel /> is rendered.

 

2. Use dynamic import

Alternatively, you can use dynamic import. We will need to create a wrapper component and wrap any page where you want SSR disabled with that component.

Let us assume that you want to disable SSR on a page. Import the wrapper component you created above.

Anything wrapped in the <NoSSRWrapper /> component will not be visible in the SSR source.

 

Verify if Server-side Rendering is enabled.

After you did either one of the above modifications, it is a good idea to check if we have successfully disabled SSR. We can achieve this by checking if the window object is undefined.

Let us create a utility function to check this:

If SSR is disabled, we will be able to see the <Main /> component.

Why can’t we use Static Site Generation (SSG)?

Even though SSG provides excellent SEO capabilities, it has its limitation: lack of access to incoming requests. It cannot read request headers or URL query parameters. On SSG, all the pages in your app are generated as individual .html-files at build times. SSG is generated before a user request takes place. Therefore, you need to know all the paths your app has ahead of time. This is not possible with apps that have dynamic routes like /user/[id]/post/[pid].js.

 

CSR, SSR, SSG. What is that?

Next.js supports three forms of rendering: Client-Side Rendering, Static Site Generation, and Server-Side Rendering. Static Site Generation and Server-Side Rendering are two forms of pre-rendering methods.

The significant difference between these renderings is when it generates the HTML for a page.

1. Client-Side rendering (CSR)

This is the way we build typical applications in React with Create React App or other JavaScript frameworks.

The site requested by the user
The server sends a response with minimal HTML
The browser downloads JavaScript or React app’s bundle. The page is not viewable.
The browser executes the framework, fetches the required data, and renders components. All logic, data fetching, templating, and routing are handled on the client side. The page is not viewable.
The page is loaded and interactive

Pros:

Fast on the server – Because the server only sends a blank page it’s very fast to render.
Great for Single Page applications – Client-Side Rendering is the only model that supports Single Page Applications. Allows us to reuse UI components across our application, without requesting them again from the server.

Cons:

No initial render – CSR might take time to make the site visible to the users in case of slow internet or large bundle size. A user sees a blank page in such scenarios which makes a bad user experience.
Not SEO friendly – Because it is based on JavaScript, web crawlers are unable to index the blank site.

Use case:

Admin panel – CSR is recommended for a page in which you don’t prioritize SEO, when the content does not need frequent updates or when you do not need to pre-render your data.

2. Server-side rendering (SSR)

This is the way we built web pages back then. SSR pages are generated upon each request. All logic, data fetching, templating, and routing are handled on the client side before the site reaches the browser.

The site requested by the user
The server fetches required data from an API and feeds that data to the React component as props.
The server sends ready-to-render HTML files. The site is viewable but not interactive.
Browser parsing the React app in the JavaScript bundle.
The page is viewable and interactive.

Pros:

Content immediately available – The user will start to see content immediately because the server sends a completed page.
SEO friendly – Great for SEO visibility because the WebCrawler will see a completed page.

Cons:

Higher server demand – Each time the user accesses another page within the website, a new HTML file is loaded. This demands a large use of the server, which usually has a higher cost.
Incompatible with some UI libraries – Some UI libraries depend on windows object which does not exist when the page is being rendered by the server.

Use case:

A news search results page or an e-commerce website. SSR is recommended for apps in which you have to pre-render frequently updated data from other sources. It is usually used when the data cannot be statically generated before a user request happens.

 

Static Site Generation (SSG)

SSG is pretty much similar to Server-Side Rendering with the exception that the HTML is generated at build time and will be reused on each request. You can reuse (and reload) the whole page on each request.

Pros:

Content immediately available – The user will start to see content immediately because the server sends a completed page.
SEO friendly – Great for SEO visibility because the WebCrawler will see a completed page.

Cons:

Long build times – Built times can be slow if the site is large and contains a lot of routes.
Incompatible with some UI libraries – Some UI libraries depend on windows object which does not exist when the page is being rendered by the server.

Use case:

A blog page or about us page because the content does not change very often. SSG is recommended for use on any page where you have to pre-render data. It can be generated before a user request takes place. It means that your data is available at build time.