The discussion about a web page rendering has come to light only in recent years. Earlier, the websites and web applications had a common strategy to follow. They prepared the HTML content to be sent to the browsers at the server-side; this content was then rendered as an HTML with CSS based styling on the browser.
In this article, we will discuss these technically different approaches on web page rendering. I will explain the major differences between each approach and suggest an approach for you.
Server-side rendering or SSR is the conventional way of rendering web pages on the browser. As discussed above, the traditional way of rendering dynamic web content follows the below steps:
The user sends a request to a website (usually via a browser)
The server checks the resource, compiles and prepares the HTML content after traversing through server-side scripts lying 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 site visible to the end-user
In this process, all the burden of getting the dynamic content, converting it to HTML, and sending it to the browser remains on the server. Hence, this process is called server-side rendering (SSR).
This responsibility of rendering the complete HTML in advance comes with a burden on memory and processing power on the Server. This increases the page load time compared to the page load time for a static site where there is no dynamic content to render.
Client-side rendering or CSR is a different approach to how the web page is processed for display on the browser. In the CSR, the burden of compiling dynamic content and generate HTML for them is transferred to the client browser.
The user sends a request to a website (usually via a browser)
Instead of a Server, a CDN (Content Delivery Network) can be used to serve static HTML, CSS and supporting files to the user
The browser downloads the HTML and then the JS, meanwhile the user sees a loading symbol
After the browser fetches the JS, it makes API requests via AJAX to fetch the dynamic content and processes it to render the final content
After the server responds, the final content is rendered using DOM processing on the client browser
Since this process involves fetching and processing data on the client front, the process is called client-side rendering.
Since both the approaches are different in the way the content is processed, each method has its benefits. Let us compare CSR vs. SSR from a user as well as the web perspective.
The web page load time is the time taken between when a request is sent to the server and when is it rendered on the browser. This is an important aspect when it comes to user experience (UX) for your website or web application. The web page load times for CSR v/s SSR are different in two scenarios:
The first page load time is the average time taken when the user loads your website for the first time. On the first load, in CSR, the browser loads base HTML, CSS, and all the scripts required at once and then compile HTML to usable content on the browser.
This time usually is more than getting a pre-compiled HTML and the corresponding scripts from the server. Thus, SSR takes lesser time normally when it comes to the first page load time.
However, for SSR, the complete request cycle followed in the first-page load is repeated. This means that there is hardly any impact on web page load time when it comes to SSR. Thus, in this scenario, CSR responds faster.
It is important to note here that the above inference does not consider network aspects in depth. We believe that the client and server have comparable bandwidth on the network.
Caching has become the need for the day now. To speed up heavy web applications, every browser, as well as the webserver, employs caching mechanisms to cache the reusable scripts on the client's machine. This improves the load time overall for CSR as well as SSR. However, a major benefit is available for CSR.
In CSR, as long as a lazy module loading is not required, practically CSR based web applications can run without the internet too! (unless you call an API for data). Once loaded, the app does not need to send requests to the server anymore. This allows the web application to be navigated, just like a simple desktop application.
In SSR, however, the request to the server is always sent. Hence, the page load time is undoubtedly higher for SSR compared to CSR. Caching does improve the content rendering speed even for SSR as the scripts would be retrieved by browser from the cache. Below image depicts how the browser handles a repeated request for a cached script-
Notice here that most of the scripts are loaded from the memory or disk cache. This improves the load time considerably and prevents excessive load on the server as well.
For a business website, optimizing it for search engines is essential. Search engines read and understand your websites using automated bots called crawlers. These crawlers are interested in the metadata of your website more than the actual content. Hence, it becomes vital that your web page reflects the right metadata for the search engines.
With CSR, you need to utilize and make an additional effort to ensure that the page metadata changes from one page to the other. This calls for the use of plugins like React Helmet for ReactJS and the use of library modules like Meta from @angular/browser library for Angular framework. You need to put in extra efforts for the metadata to be set for each page and render it on the client-side.
Lesser choices are always the simplest. Conventionally, you had a single choice - SSR. With CSR coming into the picture, the question arises which one is the right one for your application or website. Let us understand where each of them is beneficial.
A server normally resides on a machine with higher compute power and considerably higher networking speeds. With this speed and power, it never runs out of juice while processing the expected number of requests for processing. As a result, the fetching of content on the server front becomes comparatively faster.
Client machines, on the other end, have limited compute power and might take longer for fetching and rendering the dynamic content on the client-side. This means the overall time consumed to get the content rendered will be more. Thus, if your website involves repeated dynamic content rendering, SSR is a better choice over CSR.
Although they appear almost the same, web applications and websites are two different formats of web content. A web application is a complete application that can be used for purposes like accounting, CRM, HR management, Project management, etc. A website, on the other hand, is informative content about the business.
A web application involves far more user interaction compared to a website since the user performs data entry and generate reports in a web application. In a scenario where user interaction is more, it is crucial to ensure that the clicks don't take long. So, CSR works better for web applications compared to SSR.
On the other hand, for a website, a customer is okay if the new web page loads on every click since the caching would typically take care of speeding up the rendering. Moreover, SSR also ensures the right metadata for crawlers - this makes SSR better for websites compared to CSR.
After going through the above, you might be wondering if there were a way to get the benefits of SSR's quick first loads and better SEO performance with a near-native feeling of a CSR. You're in luck! - There are frameworks that work on a hybrid approach such as Gatsby.
What it essentially does it that while the first page is always loaded with SSR, it caches the other pages after the load is done so the rest of the pages are pre-rendered and cached making it feel like you're using CSR approach on the subsequent pages! Check out our website, which is also built using Gatsby.
CSR and SSR are critical to the UX you plan to offer to your user. I hope this article helped you understand these concepts from a functional and practical point of view. The final choice is ultimately yours. Choose wisely considering the above factors. The wrong choice might cost you redevelopment of the entire website or web application too. The right choice might reduce your code management efforts in the future also.