[Front End] Client-side rendering vs Server-side rendering

Do you ever wonder - what can a website not do? You can chat, play games, work on Google Doc.etc. 

Server-Side Rendering

Traditional way of rendering a website.

How it works?
  • Server generates HTML files and sends it to browser (client), where it is displayed as a website.
  • Doesn't matter if new page has one difference than the current page, the browser will ask for the entire page, and re-render everything.

Client-Side Rendering

Didn't become popular until JavaScript libraries started using this development style; examples are Vue.js and React.js

How it works?

  • Instead of getting the generated HTML files from the server, you download the data you need, template HTML(s) and Javascript (libraries). Then, the browser renders the data into the template HTML using Javascript or Javascript Libraries.
  • Server is responsible for less processing (doesn't need to generate the HTML) - this responsibility is pushed to the client (browser).
  • When navigating through 2 similar pages, where only the data points are different, instead of requesting the entire HTML of the new page, the browser will request just the changes in the data. Then the browser will render the data into the template HTML.
    • This is usually faster than Server-side rendering because there is less network traffic between client and server.

Comparisons

There is no clear answer as to whether Client-side or Server-side rendering is better. They both have their pros and cons, so we will explore how they are better than the other in different areas. 

A: SEO (Search Engine Optimization)

Search engines work by crawling websites ahead of time and indexing them. They don't "read" a website like a human does, but rather, they access the DOM (Document Object Model). DOM is what you see when you "inspect element" in a browser.

In the past, the clear winner in this category is server-side rendering. That was when Search Engine crawlers could only read static html files. In 2015, Google released an announcement saying:
"Times have changed. Today, as long as you're not blocking Googlebot from crawling your JavaScript or CSS files, we are generally able to render and understand your web pages like modern browsers. To reflect this improvement, we recently updated our technical Webmaster Guidelines to recommend against disallowing Googlebot from crawling your site's CSS or JS files." (https://webmasters.googleblog.com/2015/10/deprecating-our-ajax-crawling-scheme.html)
Referencing a blog I found, it did tests into searching client-side rendered pages on popular search engines, such as Google, Yahoo, Bing, GoGoDuck.etc. In short, SEO does look into client-side rendered pages as well, but whether it prefers one over the other is in discussion.

Furthermore, there are several ways a mis-configured client-side rendered page can make itself 'less' SEO. For example, if the search engine crawler is unable to access the Javascript, then it basically can't "read" the page.

The answer to "who's the winner" for this category is - "it depends".

B: Performance

There are 4 sections in performance to discuss:

  • initial loading time
  • overall loading time
  • consistency across devices
  • Interactivity

Firstly, the initial loading time on client-side rendered sites are usually longer, because the Javascript (library) has to be downloaded as well. Assuming the server is capable of the traffic, it is often faster for the server to generate the final HTML, than the browser (client). 

Secondly, the overall loading time is often shorter on client-side rendered sites. Client-side rendered sites are often known as SPA (Single Page Applications) because they download all of the HTML files initially. By doing this, navigating to other pages within the website usually takes a shorter time because there's less data that needs to go to the server and back. Furthermore, when you have pages with a similar structure, a client-side rendered site will be much more efficient because it can dynamically load and unload data into the template HTML; it might need to do request for data from the server though. A server-side rendered site, in this situation, will have to do a HTML request from the server; which usually takes more time than just fetching data (client-side). 

Thirdly, client-side rendered sites are usually less consistent in their performance, because a large part of the processing is done on the client-side (browser). The resources on the client-side will make a difference (eg. running the website on an old phone vs a gaming PC). On the other hand, in a server-side website, all the processing is done on the server. The browser only needs to display the HTML; which is not an intensive task.

Lastly, the coolest feature of client-side rendered sites is the immense amount of interactivity it has introduced to websites. Compare webpages today to the ones in the 2000s. Today, you can pretty much have anything running on a website; ranging from text editors (Google Doc) to multiplayer first-person shooters. While you can argue that this is due to increase in network speed and upgrades in Javascript libraries, all this will not be possible if the data isn't processed on the client-side.

I think the winner in this category is undecided. While you can have the largest scale website doing incredible things, it might not run a mobile phone because of inconsistent performance across devices. When a page does not run, it just "does not run"; the purpose of a website has failed.

Verdict

By now, you probably can guess the answer - "it depends". It really depends on what your website's purpose is for. 

If your website is full of changes in structure or the scale of it is very small, then a server-side rendered site is probably a better solution. You can benefit from the consistent performance and fast initial load time. You don't need the re-usability of HTMLs or the intensive data processing and interactivity that client-side rendered sites offer.

However, if you are building the next amazon website or stock exchange website, then definitely, go for the client-side rendering solution as you will need the features of reusability of the html and site interactions offered by client-side rendering.

Sources:


  • https://hackernoon.com/server-side-vs-client-side-rendering-in-react-apps-443efd6f2e87
  • https://medium.freecodecamp.org/what-exactly-is-client-side-rendering-and-hows-it-different-from-server-side-rendering-bd5c786b340d
  • http://openmymind.net/2012/5/30/Client-Side-vs-Server-Side-Rendering/
  • https://medium.com/@adamzerner/client-side-rendering-vs-server-side-rendering-a32d2cf3bfcc
  • https://moz.com/blog/javascript-seo
  • https://www.quora.com/How-do-you-accomplish-SEO-with-a-client-side-framework-like-Backbone

Comments

Post a Comment

Popular posts from this blog

[Redis] Redis Cluster vs Redis Sentinel

1) In-Depth Guides to Redis Cluster and Sentinel For more in-depth explanation for Redis Cluster or Redis Sentinel, please read my other posts: Sentinel:  https://notafraidofwong.blogspot.com/2019/05/redis-redis-sentinel.html Cluster:  https://notafraidofwong.blogspot.com/2019/05/redis-redis-cluster.html 2) Deciding between Redis Sentinel and Redis Cluster Similarities : Both solutions provide high availability for your system. 2.1) Redis Cluster 2.1.1) Pros Shards data across multiple nodes Has replication support Has built-in failover of master 2.1.2) Cons Not every library supports it May not be as robust (yet) as Standalone Redis or Sentinel Setup and maintenance is more complicated 2.2) Redis Sentinel 2.2.1) Pros Automatically selects new master in case of failure Easy to setup, (seems) easy to maintain 2.2.2) Cons No data sharding; master might be overutilized. Another distributed system to maintain. 3) So how do I decide? In
Read more

[Unit Testing] Test Doubles (Stubs, Mocks....etc)

Image
In unit testing, isolation is key. The goal of unit testing is to test individual components, and not an entire system . The class/object/function you are testing is System Under Test (SUT) , and the other components of the system are Collaborators or Dependencies. Test Double  is a generic term for any kind of 'pretend' object used in place of a real object for testing purposes.  There are several types of Testing Doubles. We will start with: Fake Stub Mock Command Queries Mocks vs Stubs And then: Dummy Spies Spies vs Mocks I) Basic Testing Doubles a) Fake Fake are objects that have working implementations, but not same as production one. Usually they take some shortcut and have simplified version of production code. Note that Fake is a generic term - that can point to anything; usually mock and stubs. An example of this is an in-memory implementation of a database. This fake implementation will not access the actual database, but will u
Read more

[Node.js] Pending HTTP requests lead to unresponsive nodeJS

This is a recap conclusion to the potential problems of a NodeJS program I worked on previously. The program simulates thousands of clients navigating a website by sending thousands of http requests to a given API . The idea is to load test a particular API to make sure they can handle high traffic. Because we are simulating clients, it's important to keep track of the state of the simulated client as well. The problem with this program is it is buggy and becomes unresponsive from time to time (the only solution is to restart it). The problem was fixed by re-writing the entire program in Java, but it was regretful that I never had enough time to find the exact reason the nodeJS version of it failed. The following are potential causes I suspect: 1. Exceptions The NodeJS program was not written very neatly and stacked callbacks on top of callbacks on top of callbacks. This made it very difficult to keep track of exceptions and unexpected http responses are prone to happen. So
Read more