The original link

The Web Page Rendering Dilemma

The discussion of web rendering has only been around for the last few years. In the early days, websites and web applications had a common policy to follow. They prepare the HTML content to be sent to the server-side browser; The content is then rendered in the browser as HTML with CSS styles.

JavaScript frameworks take a completely different approach to Web development. JavaScript frameworks offer the possibility of lightening the load on the server.

With the power of JavaScript frameworks, you can render dynamic content directly from the browser by requesting only what you need. In this case, the server provides only the necessary basic HTML wrappers. This conversion provides a seamless user experience for visitors, as the time required to load a page is minimal. In addition, once loaded, the page will not reload again.

In this article, we will discuss these technically different methods of rendering web pages. I’ll explain the main differences between each approach and suggest one for you.

Server-side rendering

Server-side rendering, or SSR, is the traditional way to render a Web page in a browser. As mentioned above, the traditional way of rendering dynamic web content follows the following steps:

  • A user sends a request to a Web site (usually through a browser)
  • The server checks the resources, compiles, and prepares the HTML content after iterating through the server-side scripts within the page.
  • This compiled HTML is sent to the client’s browser for further rendering and display.
  • The browser downloads the HTML and makes the Web site visible to the end user
  • The browser then downloads JavaScript (JS) and makes the page interactive when executing JS

Note that in the second step of server-side rendering, the client can browse the static page sent from the server, but cannot interact because the JavaScript has not yet been downloaded to the client.

In this process, all the burden of capturing dynamic content, converting it to HTML, and sending it to the browser is on the server. Therefore, this process is called server-side rendering (SSR). The responsibility of rendering the full HTML ahead of time comes with the burden of memory and processing power on the server. This increases page load time compared to the page load time of a static site with no dynamic content to render.

Client-side rendering

Client-side rendering, or CSR, is a different way of processing a Web page for display in a browser. In CSR, the burden of compiling dynamic content and generating HTML for it shifts to the browser on the client side.

This approach is supported by JavaScript frameworks and libraries such as ReactJS, Vuejs, and Angular. The normal web rendering process for client rendering scenes follows the following steps:

  • A user sends a request to a Web site (usually through a browser).
  • You can use a CDN (Content Delivery Network) instead of a server to provide users with static HTML, CSS, and supporting files.
  • The browser downloads HTML first, then JS. At the same time, the user will see a load symbol.
  • After the browser gets the JS, it makes an API request through Ajax to get the dynamic content and process it to render the final content.
  • After the server responds, the final content is rendered using DOM processing in the client browser.

In the third step of CSR rendering, the user only sees a blank screen.

Because this process involves fetching and processing data on the client side, it is called client-side rendering.

A comparison of the two rendering modes

Because the two approaches approach content differently, each approach has its advantages. Let’s compare CSR to SSR from a user and Web perspective.

Web page load time

Web page load time is the time it takes between a request being sent to the server and its rendering on the browser. This is an important aspect when it comes to the user experience (UX) of your website or Web application. The page load times for CSR and SSR are different in the two cases:

Home page load time

The first page load time is the average time users take to load your site for the first time. On the first load, in CSR, the browser loads the basic HTML, CSS, and all the necessary scripts at once, and then compiles the HTML into something usable on the browser.

This time it’s usually not just getting the precompiled HTML and corresponding scripts from the server. Therefore, when it comes to the first page load time, SSR usually takes less time.

The next page load time

The second page load time is the average time spent navigating from one page to the next. In this case, the load time for CSR is faster because all the supporting scripts for CSR are loaded ahead of time. It does not send a request to the server unless it needs to load a lazy JavaScript module.

However, with SSR, the full request cycle followed during the first page load is repeated. This means that SSR has almost no effect on page load times. Therefore, CSR is more responsive in this case.

It is important to note here that the above inference does not take into account the network aspect. We believe that the client and server have comparable bandwidth on the network.

Impact on caching

To speed up heavy Web applications, every browser and Web server employs a caching mechanism to cache reusable scripts on the client machine. This improves load times for CSR and SSR. However, CSR has one major benefit.

In CSR, CSR-based Web applications can run without the Internet (unless you call the data API) as long as you don’t need lazy loading modules. Once loaded, the application no longer needs to send requests to the server. This allows you to browse the Web application just like a simple desktop application.

In SSR, however, requests are always sent to the server. Therefore, the page load time for SSRs is undoubtedly longer than for CSRs. Caching does speed up the content rendering of the SSR because the browser needs to retrieve the necessary scripts from the cache. The following diagram depicts how the browser handles repeated requests for cached scripts:

Note that most scripts are loaded from memory or disk. This significantly reduces load times and prevents overloading on the server.

How to choose the right rendering scheme

Dynamic Content Loading

Servers typically reside on machines with higher computing power and significantly higher network speeds. With this speed and capability, it never runs out of resources to handle the expected number of processing requests. As a result, getting content on the server is relatively fast.

On the other hand, the computing power of the client machine is limited, and getting and rendering dynamic content on the client can take longer. This means that the total time taken to retrieve the rendered content will be longer. Therefore, if your site involves repetitive dynamic content rendering, SSR is a better choice than CSR.

Web Application UX vs Website UX

Although they look almost identical, Web applications and Web sites are two different Web content formats. A Web application is a complete application that can be used for accounting, CRM, human resource management, project management, and other purposes. On the other hand, websites provide informative content.

Web applications involve more user interaction than Web sites. In scenarios where user interaction is high, it is critical to ensure that user interaction does not take a long time. Therefore, CSR is more suitable for Web applications than SSR.

On the other hand, a website that loads a new page with every click is acceptable to the client, since caching is usually responsible for speeding up rendering. In addition, SSR ensures that the correct metadata is provided for the crawler — which makes SSR more suitable for Web sites than CSRs.


CSR and SSR are critical to the UX you plan to provide to your users. I hope this article has helped you understand these concepts from a functional and practical perspective. The choice is ultimately yours. Taking the above factors into consideration, choose wisely. The wrong choice could cause you to redevelop an entire Web site or Web application. The right choice may reduce your future code management effort.

More of Jerry’s original articles can be found on “Wang Zixi “: