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:
Wait, what is SSR?
Normally when using React, your browser will download a minimal HTML page, and the content will be filled in by JavaScript.
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.
Historically, search engine crawlers do not support JavaScript. For apps built entirely with React, this means the crawler is seeing a blank page. That means your site won't show up in search engines at all.
Fixing this problem could be the single biggest reason to go for server-side rendering.
But there is another way out. Google's crawler now renders JavaScript in certain situations. I go into details in my react SEO post. If that approach works for you, you could save yourself a lot of effort and skip server-side rendering altogether.
The catch is that Google seems to be the only search engine that renders JavaScript right now. Yahoo, Bing, and Baidu do not.
Server-side rendering can improve performance in many situations but worsen it in others.
After the browser downloads HTML & CSS, it can display your rendered components to the user without waiting for JavaScript to download or React to render.
If your JavaScript file is very large, this can be a big improvement.
The web page won't be interactive until the JavaScript downloads and React boots up, but perceived performance is still improved because your user sees content sooner.
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.
When a single user loads multiple pages on your site or returns often, your JavaScript file should be cached. SSR will provide less of a performance boost in this situation.
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.
window
and other browser-specific APIs exist before using them.react-router
on the client side, you'll need to
rewrite those same routes on your server.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.
If you would rather not use server-side rendering, here are a couple alternatives:
Render client-side as usual. Rely on Googlebot's JavaScript crawling features for SEO, and focus on other areas of your app for performance improvements. Your SEO will suffer on Baidu, Bing, and Yahoo.
Place some information inside your mount element. Crawlers will see it, and React will replace it. Like this:
<div id="mount">
This content is searchable.
</div>
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.