Server Side Rendering and Client Side Rendering

Introduction

Even though, an HTML document with CSS and JavaScript is all it takes to make up a website, it's the rendering process that 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 a progress meter makes the difference. You also don’t want to wait longer for the website to be available for interactions. Hence, 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 is, 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, and 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 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 leveraged these two for optimal use cases. 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 frameworks, 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, and 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 interact, 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.

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 that is ready to be viewed by 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.

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 send 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 product links, you will be routed to the products page 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 the 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 the browser has to download and load JS 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 a large amount of logic and data authorization.

Not-so-good parts:

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

To conclude, use client-side rendering, If your application has more dynamic data, a complex UI, a bigger number of users, and does not emphasize 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 an application with a lot of interactivity

So, when to use Server-side rendering. Use SSR, if your application has with complex UI with fewer interactions or is close to a static page and a smaller 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 these to achieve the behavior they desire. This gave rise to other rendering processes like pre-rendering, static site generation, and 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.