Server Side Rendering and Client Side Rendering

Web Development Jun 29, 2022

Introduction

Even though, an HTML document with CSS and JavaScript is all it takes to make up a website, it's the rendering process which gives the user a good experience when interacting with the website.

Staring at a blank screen till the website is built up by the browser gives a bad user experience. A loading screen with progress meter makes the difference. You also don’t want to wait longer for the website to be available for interactions. Hence, the web developers take a call on how to render a website to give a smooth and uniform experience to the user.

A web developer makes the choice of how to render a page, depending on factors like, how complex the UI of a website, how much information has to be presented on the website, is the page more dynamic or closer to a static page and others.

To look into what happens when you visit a website, you enter the URL of a website you want to visit, your computer (Client Computer) sends an HTTP request to a backend computer called a server, asking to provide the required data to view that website.

Depending on what the server sends (an already rendered HTML file or data like for the client to render the webpage on its own), the rendering can be classified as either client side rendering or server side rendering.

There are other ways of rendering a website, but these two are the most popular, and all others have just leveraged these two for optimal use case. Most times, you would take the best of both for a user experience you would want to achieve.

Let's try to understand what server side rendering and client side rendering really are, and the pros and cons of using each.

Client Side Rendering

From the beginning of web development, Server Side Rendering was the go-to rendering process, owing to the web technologies and their capabilities at the time, but with the rise of single page application framework, client side rendering gained popularity.

In client side rendering, a server will send raw data to the client and the client will take care of rendering it from scratch. The server would send a near-to-empty HTML document and the links to the JavaScript. Once, the client has all the data from the server, it will start building the HTML page and load up the CSS, JavaScript for viewing and interacting. This may result in a slow load of the page in the first render, but it would be faster for the subsequent renders as it already has the data available locally to interaction, and it does not have to make a new request to the server.

Unlike the server side rendering, the user would not be able to view the page until the above process of rendering is completed. While in the server side rendering process, the user would have a pre-rendered HTML page to view, whilst the browser is loading up the scripts for interactions.

So on the client side rendering process, you won’t have the viewable page until the scripts are executed. The final rendered page is both viewable and intractable. The below image from Walmart’s Tech Blog shows us how the client side rendering process works.

Client Side Rendering from Walmart Global Tech Blog

Server Side Rendering

Let’s look at Server Side Rendering now. In this rendering process, the client makes a request to the server, asking for the files to view the website, just like the client side rendering process, but now, the server sends an HTML document which is ready to be viewed on the client. On the first render itself, you will have a viewable HTML document. Simultaneously, the browser will download the required JavaScript from the server. Once you have the scripts, the framework gets executed, making the page intractable.

The below diagram from the Walmart Tech Blog gives a pictorial representation of the same.

Server Side Rendering from Walmart Global Tech Blog

For every other routing, a new request will be sent to the server for an HTML page. The server will go through the entire process of building the viewable HTML page and sends the JavaScript files as and when the client requests.

So the server side render will give you a viewable page faster, but it won’t be intractable right away, whereas the client side render will take time on the initial load but give you a completed intractable page.

Differences and good parts:

In client side rendering, every route will be dynamically handled by the client itself, meaning it would not make frequent requests for every routing. As an example, if you are on the home of a website, and you click on the products links, you will be routed to the products page and this product page is dynamically built by JavaScript on the client itself with the data it has, rather than making a new request to the server to provide the products page data.

As you may notice, the client saves time by not waiting for a server response, thus giving a good user experience in the second and subsequent renders. This is done by the framework, on the client. The server sends most of the data on initial request, such that the framework can do the routing by dynamically building pages.

By this, the subsequent rendering of pages is faster as it is done locally.

Whereas in the server side rendering, for every route to a new page, a fresh request is made to the server. Then, you will have a ready to view HTML document and browser has to download, load JS all again.

That implies, the server side rendering is slower on the subsequent renders.

Good parts of Client Side Rendering:

Fast rendering once the website loads up.
Can handle big amount of logic and data authorization.

Not so good parts:

poor for Search Engine Optimization
initial loading takes time compared to server side rendered page.

To conclude, use client side rendering, If your application has more dynamic data, complex UI, bigger number of users and does not emphasize on SEO content.

Good parts of Server Side Rendering:

Initial load up is faster than the client side rendering.
Good for Search Engine Optimization

Not so good parts:

Makes a lot of server requests.
Full page loading takes time and reloads.
Bad choice for application with a lot of interactivity

So, when to use Server side rendering. Use SSR, if your application is with complex UI with fewer interactions, or close to a static page and a less number of people use it.

Hope this introductory article on client side rendering and server side rendering, gave you a basic understanding. But a point to be made, developers use an amalgamation of both of this to achieve the behavior they desire. This gave raise to other rendering processes like pre-rendering, static side generation, isomorphic. We will get into this later when we deep dive into the details of rendering in future articles.

Resources and References:

Medium blog by Walmart Global Tech - Server Side Rendering over Client Side Rendering

Stack Overflow answer to Client Side vs Server Side Rendering - Client Side Rendering vs Server Side Rendering

If you want to stay up-to-date with the latest insights in Artificial Intelligence, DevOps, Cloud, Linux, Programming, Blockchain, Productivity, and more, subscribe to my Weekly Newsletter. You’ll also get access to my tutorials, tips, and guides, as well as resources from other experts in these fields.