Server-side rendering of your frontend application can be indispensable for some cases, but... is it worth the effort?
4 min read
By Eirik Wiig
December 19, 2018
In simple terms, server-side rendering (SSR) in React enables you to render your app to static html on a server, which can then be returned to a browser. There are numerous ways of setting up the full SSR experience - and for those, Google is your friend. The basic setup however, is fairly straightforward.
On a Node.js server, simply render your app by:
import ReactDOMServer from "react-dom/server"; // ... ReactDOMServer.renderToString(<MyApp />);
import ReactDOM from "react-dom"; // ... ReactDOM.hydrate(<MyApp />, document.getElementById(MY_APP_MOUNT_POINT));
This works in the same way as
render(), but basically fills in the gaps of the html created by your SSR by adding the event listeners. And there you go, you got your App hooked up with SSR!
As with all the big questions in life, the answer is that very unsatisfying... "it depends". So let's take a closer look at how it stacks up.
There are also other ways to achieve the same effect without having to go down the SSR road. Using loading animations, optimising your code and build packages for speed, pre-rendering tools (etc.) can also improve the perception among your users of a blazing fast site.
Again, as an alternative to SSR, you could look to pre-render your site using tools like
react-static in order to support you with your SEO performance.
There is broad agreement in the community that SSR can be hard and a real pain to do well and to maintain, in particular if you have a data rich application with many routes.
Essentially, you will be pushed to duplicate a lot of features to get it working correctly on the server-side. Think things like how to manage your redux store, CSS-in-JS, internationalisation, and so forth. In addition, one of the key challenges about SSR is how to know what data your view needs and how to get that data, before rendering it. Furthermore, there is the challenge on how to best handle cookies, redirects, and non 200 HTTP statuses. You also need to set up the infrastructure to render your app for you.
Of course, these are all challenges that are solvable - it just requires development time and effort. And it then becomes a matter of deciding whether the benefits outweigh the costs.