What is SSR

The full name of SSR is Server-Side Rendering. As the name implies, the rendering is executed is on the server side.

Another common rendering way is CSR (Client Side Rendering), which renders pages directly in the browser using JavaScript. In CSR, it usually needs to do the rendering work after loading JS and fetching data.

The following picture shows the different loading sequence between CSR an SSR, when rendering the same application.

In CSR, the screenshot of orange corresponds to the time user have to wait before the meaningful contant reach.（The background color of the page is orange）

It can be seen that in terms of content arrival time, the working principle of SSR determines its advantages. This difference will be more obvious in a weak network environment.

SSR’s Dilemma

Although SSR outperforms CSR in FCP (First Contentful Paint), but why hasn’t it become the main rendering mode of the Web Application? We think this is because building a SSR application is not easy:

• When you start developing an SSR application, you are no longer a simple front-end development engineer, but will be forced to become a full-stack engineer. The delivery product has changed from the JS Bundle to a Node application. With it, it is necessary to select a Node framework, build a Node application, and deal with performance overhead, guarantee application stability, and so on.
• Secondly, we also need to consider how to make the existing code run on the server side. Although most JS frameworks like React provide Server-Side Rendering capabilities, differences in rendering environment will cause many coding differences, such as calling the window variable on the Node side, will result in an error. The asynchronous function such as hooks can neither work on the Server-Side Rendering.
• Finally, when you complete application development, you need to consider these issues: how to deploy the application, how to load balancing, how to deal with server downtime, how to deal with peak user requests, etc.

Therefore, although SSR outperforms CSR in FCP (First Contentful Paint), it is not used on a large scale because of its high development and maintenance costs.

When SSR meets Serverless

In recent years, with the continuous improvement of the serverless ecosystem, we are thinking about whether the Serverless can bring new vitality to SSR. The answer is yes.

On the one hand, with the ability of functions as a service (FaaS), there is no need to build traditional Node applications, a function can become a service, and developers can focus more on application logic.

On the other hand, FaaS uses functions as a unit and is inherently scalable, which brings natural isolation and dynamic repair capabilities to SSR applications. Compared to traditional Node application, some boundary error may leads application fatal, these error can be controlled to a small extent in FaaS Mode.

Furthermore, FaaS allows users to write and deploy code without the hassle of worrying about the underlying infrastructure, which greatly reduces the threshold for developers of SSR applications.

Now, with the imagination brought by Serverless, and the work Rax has done on the engineering and Server-Side Rendering engine, deploying SSR applications can be much easier than it used to be.

What Rax SSR brings

The following points will give you a quick look of Rax SSR:

Getting started with zero configuration

Without complicated project configuration, with Rax CLI, you can quickly create an SSR project.

Extreme rendering performance

Rax’s Server-Side Rendering engine uses a mixed rendering mode, and the rendering performance is 6 times faster than React.

----------- compare renderToString ----------
React (16.12.0) #renderToString x 1,178 ops / sec ± 1.23% (85 runs sampled)
Rax (1.1.1) #renderToString x 6,047 ops / sec ± 1.73% (82 runs sampled)
Preact (10.2.1) #renderToString x 1,005 ops / sec ± 1.10% (86 runs sampled)

The benchmark was run on:
   PLATFORM: linux 5.0.0-1027-azure
   CPU: Intel (R) Xeon (R) CPU E5-2673 v4 @ 2.30GHz
   SYSTEM MEMORY: 6.782737731933594GB
   NODE VERSION: v10.18.1

benchmark: https://github.com/raxjs/server-side-rendering-comparison

Serverless release mode

Rax’s SSR project supports the Serverless release model, which can be released to Aliyun, AWS and other Serverless platforms, and can also be integrated into traditional Node.js applications based on express or koa.

Taking releasing the application to the cloud platform ZEIT Now as an example, there is no complicated application development and application process. In the existing Rax project, with a plugin for ZEIT Now, you can release your application quickly.

Performance comparison

Taking a real Rax SSR application with data request as an example, the performance comparison data shows that: under WIFI, the first contentfual paint time of SSR is about 2 times faster compared to CSR; in a weak network environment, SSR is about 3.5 times faster than CSR.

Screen recording: (left: SSR; right: CSR)

SSR Demo address: https://rax-demo.now.sh/ssr/home
CSR Demo address: https://rax-demo.now.sh/csr/home

Let’s start the SSR journey together

https://rax.js.org/ssr