How to Disable Server-Side Rendering (SSR) in Next.js
Tags: react, webdev, javascript
Published: 2020-12-23 08:05:49

_Learn how to disable SSR in Next.js and use it to replace Create React App or any custom tooling._

---

Next.js is my absolute favorite tool for developing React applications. It offers you a best-in-class developer experience. It also has a ton of useful features for being more productive and optimizing your apps in production:

- Static & server rendering 
- TypeScript support
- Multiple entry points
- Bundle-splitting and tree-shaking

However, in the past, I did not want to use it for all my React apps. Next.js does not work without server-side rendering (SSR) by default. I preferred using a non-SSR solution like Create React App, when my app did not require SSR, because SSR had caused me so many unnecessary problems. 

Then, one day Tanner Linsley, the author of React Query, posted on Twitter that he was using Next.js without SSR as a replacement for Create React App:

{% twitter 1303818811322195969 %}

I was stoked! After a little bit of research, I was able to do this myself. 🤯 

# Why Disable SSR in Next.js?

SSR for React apps is necessary in a few cases:

- The app's content needs to rank high on search results (SEO).
- You need social-media previews (Facebook, Twitter, Slack, etc.).
- You need the additional speed optimizations it can provide for your users.

However, using SSR has multiple trade-offs and challenges:

- **You need a complicated hosting environment.** You cannot just upload your app to a server or a CDN. You need Node.js servers doing the server-side rendering. This adds complexity and also costs more.
- **You need to make sure your code works both on the browser and on the server (Node.js).** This makes debugging harder and restricts you in some cases. For example, you cannot use localStorage to store authorization information, but you need to pass it in a cookie and use a cookie library that works on the server and the browser. 

{% twitter 1230449374091784194 %}

- **It affects your application architecture.** For example, server-side rendering needs to be done in a single render, so you need to fetch all the data for the page in a single location (like `getInitialProps`). This requirement complicates data fetching with libraries like Redux or React Query and often leads to duplicate code.

If you don't need SSR, these trade-offs are not worth it. Basically, you should consider disabling SSR for all apps where the UI is behind a login.

> Heuristic: If your app is behind a login, you likely should disable SSR.

# How can you disable SSR in Next.js?

Let's go through the steps for disabling SSR for a fresh Next.js application (created with `npx create-next-app`).

## Step 1: Rewrite All Requests to `pages/index.js`

Next.js supports [adding redirects](https://vercel.com/docs/configuration#project/redirects). Create a file named `next.config.js` to the root of your project. Add the following configuration there:

```js
module.exports = {
  target: "serverless",
  async rewrites() {
    return [
      // Rewrite everything to `pages/index`
      {
        source: "/:any*",
        destination: "/",
      },
    ];
  },
};
```

These redirects work only in the development environment. In production, you need to have a proxy server like NGINX or use your hosting platform's capabilities (e.g. [Netlify's redirects](https://docs.netlify.com/routing/redirects/)) for doing these redirects. 

## Step 2: Disable SSR for Page Content

To disable SSR for page content, we need to add the following code to `pages/_app.js`:

```jsx
import '../styles/globals.css'

function SafeHydrate({ children }) {
  return (
    <div suppressHydrationWarning>
      {typeof window === 'undefined' ? null : children}
    </div>
  )
}

function MyApp({ Component, pageProps }) {
  return <SafeHydrate><Component {...pageProps} /></SafeHydrate>
}

export default MyApp
```

In the code above, we wrap our page content to a component called `SafeHydrate` that allows us to prevent the page content from rendering on the server. Let's go through what is happening in the code above. 

With Next.js you can check if we're on the server by checking if the `window` object is `undefined`.

```js
if(typeof window === 'undefined') {
  // This code will only execute on the server 
  // and not in the browser
}
```

However, we cannot just wrap our code into this `if`-statement directly. If you try it, you'll notice that React will produce an annoying hydration mismatch warning in the console: `Warning: Expected server HTML to contain a matching <div> in <div>.` This happens, if the server HTML is different from what the browser renders. 

In our case, it is safe to ignore this warning. To keep things tidy, we want to completely hide the warning from the console. This can be done by rendering a div with the prop `suppressHydrationWarning`. For better readability, we create a separate `SafeHydrate` component for this and wrap our page component into it.

## Step 3: Check that Everything Works with `npm run dev`

Now, run `npm run dev` in your terminal. After the server is running at http://localhost:3000/ you should able to go to any URL (like http://localhost:3000/some/random/path) and see the content of index.js there.

![Screenshot 2020-12-10 at 12.20.29](https://dev-to-uploads.s3.amazonaws.com/i/tw9l5iacvlko87cpgxhd.png)

Success! 🎉

## Step 4: Build production bundles with `next export`

We want to deploy our app as a static bundle that can be served without a Node.js server. For this, Next.js offers the command `next export`. It will create a static version of your app in the `out` directory.

To use the command, update the "build" script in your `package.json` like this:

```json
"scripts": {
  ...
  "build": "next build && next export"
  ...
}
```

Now, run `npm run build`. When you see the message `Export successful`, congrats! You now have a working static Next.js app in the `out` directory. 🎉

You can check the whole example app from [this Github repository](https://github.com/apkoponen/next-js-disable-ssr)

# Notes on Routing and other Advanced features

## Routing

Next.js does not support dynamic routing if you don't have a server running. You need a router like `react-router`. The setup is the same as with other tools like Create React App. 

## Updating the `<title>` and Other `<head>` Tags 

You don't need to add something like `react-helmet` for updating the `head`, Next.js `<Head />` component will work. 

## Having Multiple Separate Pages

If you want, you can still use Next.js pages to have multiple different pages as separate entry points for your app. This will make your bundles per route smaller and speed up your development environment because only a part of the app will be built when you make changes.

For example, if you have a page `/accounts` you can create a file `pages/account.js` and add a corresponding rewrite:

```js
module.exports = {
  target: "serverless",
  async rewrites() {
    return [
      // Rewrite everything under `/account/ to `pages/account`
      {
        source: "/account/:any*",
        destination: "/account",
      },
      // Rewrite everything else to `pages/index`
      {
        source: "/:any*",
        destination: "/",
      },
    ];
  },
};
```

# How's this different from using Next.js `getStaticProps` with `getStaticPaths`?

Using `getStaticProps` with `getStaticPaths` allows you to do Static Site Generation (SSG). This means that all the pages in your app are generated as individual `.html`-files when you run `npm run build`. 

SSG is awesome, but has a single big limitation: **You need to know all the paths your app has ahead of time**. This is not possible with many apps that have tons of user-specific paths like `/my-payments/123121521241`. 

With the approach described in this article, you can use a dynamic router like `react-router` with Next.js just like you would with Create React App or any traditional single-page app.

# Additional Resources:

- [This wonderful gist by @tannerlinsley](https://gist.github.com/tannerlinsley/65ac1f0175d79d19762cf06650707830)