Server-side Rendering in React

Tram Ho

In some previous posts, I wrote about React and used Create React App to make the example the easiest and fastest way. However, using CRA also has some weaknesses when you view the source code on the web browser, you will only see the page almost empty and only the <head> but almost nothing in <body> .

This is the result of the CRA rendering your application on the client side . You can understand that the build .js file is downloaded to the user’s browser before the rest of the page starts loading. This causes the initial page load time to increase and some web crawlers cannot index the website.

There is a better way to render the application as server-side rendering.

Server-Side Rendering?

SSR is the content of your website displayed on the server, not using JS displayed on the browser. For example, a Laravel site, the main content comes from HTTP displayed on the server and renders HTML, CSS and even JS. With the application created by CRA, it only sends the .js file to the client, from which the client’s JS browser creates the markup after the .js file is completed loading.

Reason for using server-side rendering

Server-Side Rendering means that every web page is displayed and downloaded from the server. With React server-side, there are some disadvantages as follows:

  • SSR improves performance with the condition that your application is relatively small. However, it can slow down your application with a large enough application.
  • It also increases the response time of the application. For a busy or busy server, make this worse.
  • It increases the size of the response and of course your page load time cannot be reduced.
  • The application is also made more complicated.

However, we cannot fail to mention the advantages and necessities of SSR in some cases:

Improve performance

The display content appears earlier with the server-side render because the HTML page displayed is being sent to the client instead of the blank HTML page that is only displayed after loading JS / React on the client. Because the content appears earlier when using SSR compared to CSR, the performance is better. Actual performance is not necessarily better for the application displayed on the server side because the application cannot be updated or interacted until JS is loaded on the page. It happens simultaneously with CSR. In SSR, the performance of the application is high or low depending on the server’s resources and the user’s network speed. Faster page load times are the first factor to evaluate a user’s good or bad experience. With these large websites, of course they are using SSR.

Optimal Search Engine Optimization (SEO)

The gold standard for your web applications displayed in the results of search engines is to use server-side rendering for your crane applications. This will ensure that your application can be collected and indexed quickly and efficiently by search engines. Every website always wants to appear in search results from major search servers like Google and Bing. However, the search engine is not yet understood and it is not yet possible to retrieve content from JS. This means that they only see a blank page, no content even though your site is useful. It is currently heard that Google collects data from Web applications built by JS. However, not all search engines can crawl client-side renderable applications like Google. Furthermore, because JS rendering needs additional computing resources, Google will delay when it will crawl and index client-side render applications. Preparing the server-side content for your web data search engines seems to be a more sure way.

Social sharing

Another benefit of SSR is that you have a snippet and image that stands out when sharing your web content via social networks. This can only be done if your application is rendered from the server.

Viblo just recently got this feature:

Client-side Rendering with Server-side Rendering

We consider the sequence of events when loading CSR and SSR applications.

The figure above explains why the content is displayed faster for users when using SSR. It can also be seen that the application can be interacted at the same time for both CSR and SSR.

Below is a more detailed description of the SSR sequence, including what is actually happening on the server side.

  • Browser sends website request (client)
  • Server loads React from memory (server)
  • Server render HTML based on virtual DOM created by React application (server)
  • Server sends the generated HTML to the browser (server)
  • Content visible to users
  • Request JS package (client)
  • React application loads in the browser (client)
  • Users can interact with the application
  • Request API data from the backend (client)
  • Render re-applies the application with new data (client)

React the SSR framework

There are several frameworks for server-side React rendering as follows:

Next.js

Next.js is a great framework, along with that it also has a large community. Using Next.js, you don’t need to worry about bundling, minimize or reload. There are many outstanding features that you can experience with it. You can create pages as components in the files. In addition to having a support community, many large companies also use Next.js in their websites such as npm, Netflix …

Razzle

Razzle is a tool that helps abstract all the complex configurations required for SSR into a single dependency. It gives you a great developer experience about create-react-app .

To get started with Razzle it is relatively easy and it uses React Router v4 by default, unlike Next.js.

Some alternatives

If you are more familiar with using other Vue or JS frameworks, here are a few other alternatives.

Nuxt.js

Nuxt.js is a server-side rendering framework for Vue applications and is quite popular in the Vue community. If you are looking for an alternative to Next.js or Razzle in Vue’s world, try Nuxt.js

Gatsby

Gatsby is a static website creator based on React that has a special affection for many people (User Experience) and DX (Developer Experience). Strictly speaking, it does not do SSR at runtime. Instead, it performs server-side rendering with Node.js during build time. Where it creates static HTML, CSS and JS when deploying the site. This makes for faster loading times and further optimizations such as splitting route-based code and pre-fetching.

Does SSR always need?

Of course not ? . Not all applications need server-side rendering. Especially for dashboard and authenticated applications, there is no need for SEO or sharing to the media. In addition, the expertise required to build a SSR React application is higher for the create-react-app generated application.

Most importantly, SSR React applications are more costly in terms of resources because you need to maintain Node-only operation.

Conclude

The React client-side is great, but the application rendered on the server side has more noticeable benefits. Benefits include:

  • Performance
  • SEO
  • Social sharing

This article summarizes the theory of reading and mainly talks about the benefits of SSR. Hopefully, in the following article, I will be able to guide you as an example of using the above libraries for the SSR application for React. Thank you for reading ? ‍ ♀ .

Share the news now

Source : Viblo