What to Choose for a Website? Server-side Rendering vs. Client-side Rendering

In this article, we'll discuss the differences, advantages, and disadvantages of both of these solutions. However, before this happens, we'll briefly remind you how websites work and how it’s possible that, regardless of what device we use to surf the web, we only need an internet connection and any device with a browser.

Beginnings of HTML

In the early 1980s, when the internet was still in its infancy (in the form of ARPANET), and long before the first websites appeared, scientists were working on creating a system that would allow for remote viewing of documents located on another computer. This system had to be reliable and work on any computer, regardless of the operating system and specifications. It turned out that the simplest solutions are the best, and sending data using text with appropriate tags such as header, footer, or strong is the best option. This is how HTML, which is still used in our browsers to display web pages, was created.

What is server-side rendering?

Now that we know what HTML is, we need to answer the question of where it comes from. How is it possible that when visiting a given website the server returns a specific code?

The moment the server receives a request from our browser, it must process a lot of information, including checking whether we have sent any cookies together with the request. If so, the server verifies:

• what files they are,
• whether they contain information that we're logged-in users,
• whether they contain information that we've visited the given website in the past and kept any of its settings.

Then the server collects information from other sources (e.g. a database) on what is to be displayed to the user. In the case of a blog, this will include the content of the latest or featured articles.

Having all the necessary information, the server in response sends us the HTML code which our browser converts from text into graphic form.

Source: Duomly

When we click on a link to open another blog article, we send another request to the server and the whole process starts over.

Pros and cons

The above-described standard for generating HTML code has remained in effect almost since 1991, i.e. from the moment when the first website was presented to the world. It's an old but also proven solution. By choosing server-side rendering, we can be almost sure that our web page will be displayed correctly anytime and anywhere, regardless of the operating system or browser.

However, attentive readers may already see one severe drawback of this solution. Let's go back to the article page example. After reading the post, we were interested in another text that appeared in the Recommended for you section. We click on the link, and what is happening? We send a request to the server to generate the HTML code of the entire page, along with the content of the new article. But we actually needed only the content of a new article! The rest of the HTML code was unnecessarily generated again. This leads to an additional load on the server, which in the event of high traffic on the website may lead to performance issues.

When should you choose server-side rendering?

It's worth choosing such a solution when we want to be sure that our website will be displayed correctly, regardless of who'll view it . Let us keep in mind that nowadays not only actual people browse the internet. Every day, web pages are visited by Google bots, whose task is to determine whether the content on them is valuable and how high it should be ranked in the search results. Until recently, these robots were completely unable to cope with websites that were rendered client-side (which we'll describe further down the text), and Facebook bots are still not able to do this.

What is client-side rendering?

In this case, the server handling the request performs only the bare minimum of the necessary work and in response, it returns JavaScript code instead of HTML code . What's important, is that the JS code isn’t generated "on the fly" by the server. It's a static file that has been saved there earlier.

The returned code contains the information on which HTML should be generated. This time, our browser generates this code locally and displays the website graphically.

Source: Duomly

Pros and cons

As you can probably guess, the first advantage is reducing the load on the server. It doesn't have to generate the whole HTML code every time . Our browser is doing it now. This allows the server to handle more requests at the same time. It also allows us to reduce the costs related to infrastructure.

Due to the fact that all information on how the HTML code should be generated can be found in our browser, going to a new subpage doesn't require reloading it. HTML code is changed locally by our browser, thanks to which the user has the impression that the website works much faster and operates more like a desktop or mobile application than a traditional website.

The JavaScript code that our browser receives in the case of client-side rendering is very similar to the code in mobile or desktop applications. Thanks to this, in most cases we’re able to expand the operation of our web page in a very simple way and at a low cost. It will become both a website and a mobile application (PWA).

Unfortunately, this solution isn't without its drawbacks. Due to the fact that we receive JavaScript code in response from the server, we must have this code enabled in the browser. We won't see any content without it. It's true that nowadays every newer and older browser supports such code, but as we've mentioned earlier, the internet is browsed not only by people. Handling such code is still a problem for bots. If we want the website to be ranked as high as possible in the search results, and the shared links to our web page to be presented in a modern way (with graphics, title, and page description), client-side rendering may not be the best solution .

In which cases is it better to choose client-side rendering?

Client-side rendering is perfect in the case of reactive websites where the user can perform many actions . Google Calendar or Gmail are good examples of such web pages. This solution will also work well if we care about the users using mobile devices, who will be able to install the website on a smartphone in the form of an application.

Client- and server-side rendering

Both solutions presented here have their advantages and disadvantages. This doesn't mean, however, that by choosing one we have to give up on the advantages of the other. It's possible to combine these methods.

When visiting a website for the first time, the HTML code is generated on the server's side in a traditional way and returned in this form to the client. However, JavaScript is also sent together with this code. Further interactions on the web page are performed via the uploaded JS code, the same as in the case of client-side rendering.

Thanks to this, we’re able to combine the advantages and eliminate the disadvantages of both of the abovementioned solutions. Is it the perfect option then? Unfortunately, no. The hybrid solution we are presenting here is much more difficult to implement, and therefore requires more skilled employees and takes more time . This, in turn, translates into higher implementation costs.

Server-side rendering vs client-side rendering - summary

Client-side rendering allows us to create modern websites whose operation more resembles applications than traditional web pages. Unfortunately, this has a negative impact on the search results. The halfway solution is also not without its drawbacks. Therefore, if you plan to implement any of these solutions on your web page, it's best to consult with web development specialists. After a thorough analysis of your needs and specifications, they'll be able to choose the best solution for you.