Many of you probably use React CLI, better known as Create React App (CRA). Using CRA allows you to get up and running with ease and has a lot of other advantages. However, building with CRA has a few disadvantages, for example, when you
view source of a web page from a web app initialized with CRA, you will notice that it’s an almost empty page with just the <head> section but hardly anything within <body>.
This is because CRA renders your app in the client-side, meaning the built .js file is first downloaded to the user’s browser before the rest of the page starts loading. This increases the initial load time and some web crawlers are unable to index the site.
Is there a better way to render your app? Yes!
This is where server-side rendering for React comes in.
In this article, I want to introduce you to SSR React, reasons to use it and some popular frameworks for rendering React on the server side. I would also like to address when SSR React does not make sense. This article is aimed at developers already working with React on the client side.
Examples of traditional SSR languages/frameworks are PHP, Java, ASP .NET and Node.js.
To be clear, this is how content was rendered on early websites, until the influx of client-side libraries. However, now, server-side rendered React apps use Node for the server which is a key difference to traditional server-rendered apps (we’ll see how later on in this post).
As I said before, server-side rendering initially means every page is rendered and loaded from the server. With the introduction of server-side (universal) React, however, things are slightly different.
The initial page is rendered from the server, meaning the subsequent pages load directly from the client. So, you have the best of both worlds — the power of the initial server-side content plus the speedy subsequent loads which requests just the content that is needed for future requests.
In addition to the above benefit, here are some other advantages you get from going SSR:
Faster load times lead to a better experience for the end user. This is one of the reasons many large companies are taking the SSR approach for their sites.
The advantage with SSR is that you get the benefits of a traditional website’s SEO since the entire page can now be crawled by bots.
The other benefit with SSR is that you get an elaborate snippet and featured image when sharing your web page’s content via social media. This will not be possible when you have just client-side rendered apps. For example, here is what a server-side rendered React app looks like when shared on LinkedIn:
Getting started without frameworks is possible, but I wouldn’t recommend this approach since there are many considerations and moving parts in a React SSR app. For example, you have to handle bundling, minification, hot reload (and more), all on your own.
However, if you want to go this route, I’d recommend reading this tutorial by Roger Jin on CSS Tricks.
I would recommend picking up a framework if you want to render React on the server side. Here are some frameworks you can consider:
Next.js is a great framework with a great community around it. With Next.js, you don’t have to worry about bundling, minification or hot reloading, you get a lot of features out of the box. You are able to create pages as React components within files. You may be used to this if you worked with PHP. In addition to the community and support, there are many large companies using Next.js in production including npm, Netflix and Auth0.
Razzle (a project by Jared Palmer) has been gaining a lot of traction lately.
“Razzle is a tool that abstracts all complex configuration needed for SSR into a single dependency — giving you the awesome developer experience of create-react-app, but then leaving the rest of your app’s architectural decisions about frameworks, routing, and data fetching up to you.” (https://github.com/jaredpalmer/razzle)
It’s easy to get started with Razzle and it uses React Router 4 by default, unlike Next.js which does not have a router out of the box.
Nuxt.js is a server-side rendering framework for Vue.js and is popular in the Vue.js community. If you are looking for alternatives Next.js or Razzle in the Vue.js world, do give this a try.
I explored server rendered React apps a few months back and created an app with Next.js and hosted it on Now — a serverless platform. Both Next and Now are from a company called Zeit, who are doing a great job at educating developers about React and serverless technologies along with offering other fantastic products.
The short answer would be no. Not all apps need server-side rendering, especially apps with a dashboard and authentication that will not need SEO or sharing via social media. Plus, the expertise for building a server-rendered React app is higher than an app initialized using create-react-app.
Most importantly, SSR React apps cost a lot more in terms of resources since you need to keep a Node server up and running. There are times you may be better off going the serverless route when you want to choose server-side rendering for your React applications.
Client-side rendered React apps are great but having apps rendered on the server have noticeable benefits.
As we covered in this post, the benefits include:
- Search engine visibility
- Social sharing
I would highly encourage you to explore server-side rendering for your React apps and use it for your next product to see these benefits in action.
LogRocket is a frontend logging tool that lets you replay problems as if they happened in your own browser. Instead of guessing why errors happen, or asking users for screenshots and log dumps, LogRocket lets you replay the session to quickly understand what went wrong. It works perfectly with any app, regardless of framework, and has plugins to log additional context from Redux, Vuex, and @ngrx/store.