Web development is a bit like samurai philosophy: there is no goal, only a path. Along the way, developers are constantly solving two tasks: a) implementing business logic in websites and web applications, and b) optimizing their performance.

The latter task will not be considered done until the amount of traffic between the server and the client becomes negligible, and the page speed (First Contentful Paint, FCP) and the time to interactive element start (Time to Interactive, TTI) become faster than the beat of a butterfly’s wing. Then again, infinity is not a limit. Because, as we remember, there is no goal.

We touched on the topic of website performance optimization in our previous posts when we talked about the React library, the Next framework and Server-Side Rendering. Today, we will return to these technologies and explain the importance of server components in optimizing performance.

The issue of Server-Side Rendering

One of the ways to improve website performance is to reduce traffic from the server to the user’s (client’s) device. The client-server architecture is essentially the queue of requests and responses between the client and the server, which in turn accesses the database.

Gradually, web development began to take on other tasks, such as where and how to cache the page or mark it up for SEO so that it could later go live and work for the user, or what part of the page rendering could be done by the client or by the server.

Eventually, there were developers who took the React library, built the Next framework around it, proposed the principle of Server-Side Rendering (or SSR) along with the framework, and said: “Now, the dynamic React application can be partially assembled on the server, delivered to the browser in the form of one page, while the content that depends on the user’s actions can be additionally sent in the form of small AJAX files as the user performs the actions.”

Well, a small AJAX file is a big step the web development has made to reduce the time of the First Contentful Paint. In addition, the React sites that use this approach show great SEO results.

However, despite its groundbreaking nature, the SSR was still no bargain in terms of performance. Before components are sent to the client side, a lot of server resources are used to render them, so in the late 2010s it was common to buy additional resources to save users the time they spent waiting for the page to download.

What are React Server Components?

The question arises: why not distribute page rendering equally between the client and the server? Let the server render only static elements of the component tree and send them to the client in the form of HTML, while the client processes buttons, forms, and other interactive elements received in the form of JS files. This is where the idea of separating React components into client and server components came from.

The implication of server components is that even though the code is written in React, it is executed on the server. After execution, it is compiled in JSON format and sent to the user’s browser as part of the virtual DOM, allowing the React application to build it in the DOM tree and make it behave as if it were built in the browser.

React Server Components vs. Server-Side Rendering

Let’s get back to the Server-Side Rendering. When SSR is used, the page is built on the server — almost entirely, with the exception of dynamic components. First, the user sees the version that was built on the server and has no responsive interactive interface elements. And only during hydration, when React attaches event listeners to the page markup and begins processing the application in the browser, do previously inactive dynamic elements become interactive.

Only the server processes React Server Components to produce finished markup and metadata and send them to the browser to the React application, which builds them into the DOM tree. This is similar to working with common monolithic applications, where the server provides the HTML markup — you do not know how the page is built inside, you just see the result. This is about the same, but it is not the HTML markup that the server provides, but the data for React.

The RSC method comes with some limitations: server components do not have a life cycle. So if you need to process the data the user enters, these components will not work. But for static elements they are ideal because the code responsible for rendering the server component is not sent to the client at all, which reduces both the amount of downloaded code and the size of the bundle where JS, CSS and other resources needed for the work of application are stored.

Therefore, server components should include static elements such as headers, footers, and content. On the other hand, the reactive part that will work with hydration consists of the forms, buttons, and other elements with a changing state.

The RSC has another feature: when you use it, you can get access to database resources directly, bypassing the server API. Again, this results in less code, less data transmitted, and a more efficient application.

In addition, starting with the current version of React (React 18), the Server Components API allows you to describe the server components declaratively and automatically manage their download. This includes automatic code splitting: the system automatically defines which parts of the code can be downloaded to the server asynchronously, depending on the current request context.

The purpose of server and client components is shown in the table below.

Benefits of React Server Components

What a React application gets when using React Server Components:

• Pages are rendered without the queue of requests and responses between the client and the server (the so-called client-server waterfalls);
• The size of the application is reduced because some of the code is executed on the server;
• You can access backend resources bypassing the server API;
• Code Splitting is automated.

We have already tried the React Server Components. In the online service we are currently developing, there are multiple accounts and the accounts are mostly dynamic. In addition to these accounts, there is a website which is static for the most part. To make it work and download faster, we use server components.

While working with the previous version of Next, we observed the server component technology in a rather raw state, which caused some problems. In the same project, the site framework was sent from the server to the client first, and the menu was sent separately because it depends on the browser resolution and changes its states, so it was not possible to make it a server component. In the latest version, the server components are more stable and we are watching its progress in the field with interest.

Contact our development team if you want your website to be more interactive and load even faster.