Why prefer Server-Side Rendering?

So I came across these interesting concepts and facts during my GSoC project, although it’s not a part of my project specifically, but worth sharing…

Whenever you build an application, you start taking into consideration optimization techniques to handle multiple requests and responses within a short time span. Here is when we need to start thinking of choosing between Server-Side Rendering (SSR) and Client-Side Rendering (CSR).

SSR is a popular technique for rendering a client-side single page application (SPA) on the server and then sending a fully rendered page to the client.

Source: Google Images

Just as the name suggests it is very clear that obviously SSR gives better performance than CSR. SSR is when HTML is built on the server than on the browser. It is preferred mainly due to 2 reasons:

• Better performance
• Search Engine Optimization (SEO)

CSR happens when an empty HTML file is first served to the browser and then HTML is built on the browser and the painting is started. We can summarize the steps for each of them as follows after the request for the page is made by the browser:

Server-Side Rendering

• The server sends ready to render HTML page to the browser
• The browser renders the HTML page, which is now viewable to users
• Then the browser downloads JS
• Now React is loaded and the browser executes it
• The page is now interactable

Client-Side Rendering

• The server sends the response to the browser
• The blank HTML page is loaded
• Then the browser downloads JS
• React is loaded and the browser executes it
• The page is not viewable to users and interactable

The Increase in Performance

The loading part which can be seen as a blank page flicker in CSR does not happen when using SSR. Now let’s look at a few cases in CSR:

• If the user clicks on a button or performs some action before the page becomes interactable, the action won’t get executed until the React gets properly loaded.
• There is the obvious distinction in that the output of CRA (static files) can be served up through any web server (say a CDN) while the output of Next.js (being server-rendered) is served up by a Node.js server (going to be substantially slower than a CDN).

React SSR Framework

For rendering React on the Server-Side you might want to use Next.js.

Next.js by Vercel - The React Framework

There are obviously a few cons of Next.js, so as a developer one should always be open to new ideas and learning. You can turn your CRA into the server-side rendering by Pre-Rendering with CRA. Have a look at this blog:

How to Enable Server-Side Rendering for a React App | DigitalOcean

From Netflix to GitHub many applications are using Next.js. Even non-image content in CRA gets displayed at a delayed rate from Next.js. To get into more performance details and testing, have a look at this Github Repo. As the main page of Next.js mentions, it is a React Framework for:

• Production
• Progressive Web Apps (PWAs)
• Pre-Rendered Apps
• SEO friendly sites
• The Desktop
• The Mobile Web
• Static Websites
• Lightweight Apps

…and many more

While writing the code the JSX Components are almost similar in both, but how the API is fetched differs in both cases. There is a major time gap if we look at the content-loading of both cases and for large-scale applications, this affects the performance to a huge extent. The First Meaningful Paint usually has a difference of 6–7 seconds, because downloading all the required bundles for an application takes up ample time and you can see where the lag is caused.

One of the cons of Next.js is that image files aren’t cached. The first load of Next.js doesn’t involve downloading the bundles, so your user has already started viewing the static page content before Javascript got even downloaded by your browser.

Resources

• Walmart Labs Blog — A must read!!!
• Logrocket Blog — Details on really interesting stats
• Codeburst Blog