⚔️ Code Conqueror

🤖 Next.js disable SSR

Nov 02, 2019

You sometimes might want to disable server side rendering in Next.js, to do so you should use the dynamic module in Next. We'll show you how to do it, and some best practices about when to / when not to use it.

Out of the box Next.js has great support for server side rendering react components. But sometimes you might be working with a component that either is incompatible or doesn't benefit from server side rendering. In that case you might want to render some components only on the client side. To eject from server side rendering you should use the

dynamic
method provided by Next.js.

Disabling (Server side Rendering) SSR in Next.js

While there is no global setting to disable server side rendering, it is possible to render certain components client side. You many want to do this if you are using components that make calls to browser APIs like

window
or if the components are not visible on initial page load and large in size (as a performance optimization). To load a component on the client side you can use the Dynamic import handler provided Next.js:

import dynamic from "next/dynamic";
const NoSSRComponent = dynamic(() => import("../components/NoSSRComponent"), {
ssr: false,
});
function Home() {
return (
<div>
<Header />
<NoSSRComponent />
<p>HOME PAGE is here!</p>
</div>
);
}
export default Home;

Next Dynamic is based on React Suspense which means that it will almost certainly be updated to include some of the new Suspense methods that are coming out of React. You can find more docs on

dynamic
on the Next.js site.

Common reasons disable Server side rendering (use client side rendering)

There are some popular packages like Plot.ly and Codemirror that rely on browser APIs. That means they can only be rendered on the clients side. Therefore in order to use them you’ll have to import the components dynamically.

Next.js dynamic function does not directly allow for you to import node modules dynamically so you’ll need to create a wrapper component that imports the node module and then re exports it. Eg:

// components/NOSSRComponent.js
import CodeMirror from "react-codemirror";
export default CodeMirror;

Another one is document / initial payload size. If the contents of the component will be rendered off-screen in the first paint you can save quite a bit of bytes / rendering time by loading that component dynamically and delivering a smaller payload to the client on first request.

Should you disable Server Side Rendering?

Server rendering your application will always improve performance, and lead to better SEO since it’s easier for Google’s crawler to get information about your page.

That being said, if your application heavily relies on browser methods, or is not intended for public consumption. Then the benefits of Next.js compared to something like create-react-app are not as obvious and it might make sense to just consider using another framework. Although Next does sill provide great Typescript and API building support compared to create-react-app.

Also because of the proliferation of frontend javascript frameworks, Google's crawler has gotten a lot better at evaluating the javascript and then checking the final resulting page for information instead of just the delivered html payload.

Why you might want to disable SSR, but keep Next

The most common reason for disabling SSR is that a particular component calls to browser APIs like

window
or
localStorage
in a way that’s not easy to refactor.

In such a case you can import the components lazily as described above. An example of this is using CodeMirror, it’s not easy to refactor away the browser pieces so disabling SSR is a good option. You can even define a loading fallback that looks somewhat similar tot he code you are trying to render so the users get a nice experience on first paint.

Another reason is performance. If your SSR pages are not cacheable the server had to try to construct them on every request. This can significantly increase page load times in the case of large DOM size. We would recommend trying to first implement an SSR coaching strategy, but if that’s not an option lazy loading the expensive parts is a great alternative. That way users still get a very snappy initial load but some pieces are lazily loaded in later.