You Might Need Server-Side Rendering

There’s a popular idea within the React community that SSR (server-side rendering) isn’t necessary, and it’s a popular idea for some very attractive reasons.

Firstly, it’s not trivial to get SSR working well. It involves a lot of bootstrap code on both client and server, and it often needs to be highly bespoke to your particular project. Additionally, React is very slow at rendering a component tree to a string on the server (there are tricks to speeding this up, but the most effective ones are a little… dirty). There are also tricks you need to do on the client to deal with interactivity issues related to pre-rendered content.

Secondly, the most common reason why people think SSR is unnecessary is because it’s not needed for SEO. The justification for this is that Google crawls JavaScript just fine, and it does — people have tested it pretty thoroughly. This has led many people to argue that you don’t need SSR for SEO purposes. However, for some reason we’ve fallen into the trap of thinking we only need to optimise for Google. But Bing and Yahoo have a higher market share than you might think, and then there’s Baidu in China, and it seems that none of them will execute your JavaScript. But despite all this, not needing it for SEO remains the most common argument against the effort of implementing SSR in your React-based websites/apps.

Even if you don’t care about the SEO of your particular project, usually because it’s an app and content doesn’t need to be indexed, you may still need SSR.

If you have the need to support Twitter Cards, Open Graph (e.g. sharing rich content on Facebook), or any of the other numerous micro-format use cases on the web, you probably need SSR. Twitter won’t execute your JavaScript, and neither will Facebook.

At my day job, we went down the route of implementing SSR, and as expected we found it to be an error-prone and complicated process. Then we fell into the trap of thinking we didn’t actually need it for SEO (due to all the popular reasoning), so we stripped it all out — ending up with a much cleaner codebase. It was only when we came to implement Twitter Cards and Open Graph that we realised that we really did need SSR. Thankfully this all happened in the early stages of the project architecture, so the costs of change were low, if it had happened later it could have caused some major delays.

The lesson here isn’t you should always implement SSR, just that there are good reasons for doing so that you may have overlooked.

Aside: I love the mild irony that Facebook hasn’t put a lot of effort into supporting SSR in React and Relay, mainly because they don’t need or use it — but Facebook itself is one of the reasons that other people do need it. ;)