There is a lot of information on the web about how to use server-side rendering, or SSR, with React. But the question you'll want to answer first is: should I use it?
Server-side rendering is very cool, and a must-have in certain situations, but it comes with drawbacks.
Before you jump into server-side rendering, consider carefully:
Does server-side rendering make sense for my React app?
Here are three topics to consider when looking at server-side rendering:
Rendering server-side helps search engine crawlers find your content, but sometimes Google can find your content without SSR.
SSR will usually increase performance for your app, but not always.
Using SSR will increase the complexity of your application, which means less time working on other features and improvements.
With SSR, the initial content is generated on the server, so your browser can download a page with HTML content already in place. Updates to the content are still handled in the browser.
Fixing this problem could be the single biggest reason to go for server-side rendering.
Server-side rendering can improve performance in many situations but worsen it in others.
SSR improves performance
SSR degrades performance
SSR is more work for your server, so your HTTP response will take a little longer to return. A lot longer if your servers are under heavy load.
The size of your HTML will be increased and will take longer to download. For most apps this should be negligible, but could become a factor if your React components contain long lists or tables.
Other Performance Factors
We cannot say performance is better with SSR or performance is worse with SSR. Neither statement would be true in general.
Server-side rendering increases the complexity of an app in a few ways.
- Node support: Your React components will need to run on node. Check if
windowand other browser-specific APIs exist before using them.
- Two routers: If you use
react-routeron the client side, you'll need to rewrite those same routes on your server.
- APIs: If your React components make requests to your API, these requests may need to behave differently when they run on the server, perhaps by directly querying your database or other application logic.
Adding SSR to your site isn't trivial, so don't use it unless you need it for performance or SEO reasons. To find out if those apply to you, read on.
When to Use SSR
Use SSR if...
- You need SEO on Bing, Yahoo, or Baidu.
- You already have a working React app, need the best possible performance, and are willing to pay for the extra server resources.
Don't use SSR if...
- Your React app isn't finished yet: get it working first!
- SEO on Google is good enough. (Make sure that Google is crawling your content.)
- Server resources are scarce, perhaps due to a low budget or inability to scale.
Three Alternatives to SSR
If you would rather not use server-side rendering, here are a couple alternatives:
Place some information inside your mount element. Crawlers will see it, and React will replace it. Like this:
prerender is a service that will store a cached version of your pages. This helps with both SEO and performance, while keeping your code simple. I haven't personally tried out this service so I cannot vouch for it's quality.
Don't use SSR just because it's sexy right now - it comes with a cost.
Consider whether or not server-side rendering makes sense for YOUR app, and decide accordingly.
And for help making more of these architectural React decisions in the future, sign up for the Modern JS newsletter!