Client vs serverside rendering – the big battle?

render_mwayblog

When it comes to the development of a single page web application for mobile devices performance is a big deal. Smartphones are significantly less powerful than a desktop PC. Therefore, a test was setup to measure the time for different approaches in creating html on the client.

A single page web application offers a better user experience and reduces the traffic. The server only needs to send small JSON objects and the JavaScript code on the client has the responsibility to create the html structure. Through the power of AJAX content can be loaded in the background while the user can still interact with the page. The creation of the html structure by JavaScript is also called client side rendering. On the contrary is the server side rendering. The server creates the HTML structure and sends it back to the client as a whole document.

Javascript Frameworks like AngularJS and BackboneJS make it easier to create a single page web application. They structure the JavaScript code and offer a toolset of important functions to boost the development of applications. For mobile devices there are frameworks like The-M-Project v2 Absinthe available that makes the development of cross browser web applications with the look and feel of a native application possible.

The problem of all of these frameworks is that they have to render the HTML. There are a lot of interesting blog posts, which discuss the pros and cons of client and server side rendering (e.g. the post of Karl Seguin). Most of the authors are saying that client side rendering is very slow and should be rather done on the server. However, client side rendering brings some positive points so it become an established procedure especially when an app with smooth page transitions and less data transfer has to be developed.

Test setup

For the test a simple NodeJS server was set up. The intention of the test is to render the same HTML structure by different approaches. The following approaches were tested:

  • server side rendering with jade templating
  • client side rendering with string concatenation
  • client side rendering with underscore as templating engine

Also the performance of the following JavaScript Frameworks were measured:

  • BackboneJS
  • AngularJS

For testing purposes a local database is set up and seeded with tweets from Twitter. These local saved entities have to be rendered. The time measurement starts as soon as the requested entities are available: either fetched from the database (server side rendering) or the Ajax request (client side rendering). It ends as soon as the last entity is rendered as html. The test starts with rendering one entity with each component and finishes with rendering 1000 entities. The entities have to render the following markup:


Test results

Client-vs-Server--(Tested-on-Macbook-Pro-2013-(i7-processor-8gb-ram)

Server side rendering needed almost a constant amount of time for rendering the HTML document while the client side rendering defines a linear increase. A huge benefit of server side rendering is that you have the control of the performance of the server hardware whereas client side rendering is dependent of the performance of the device on which you do not have any control. The application can be accessed by a high-end device like a desktop PC or by a smartphone with little performance. Performance is a crucial factor for the test result. In another test two different smartphones were used to measure the time for client side.

Clientside-rendering-on-mobile-device-(used-approach-was-string-concatenation)-

The smartphones are clearly slower than the PC because of lacking hardware performance. One major advantage of client side rendering is that the server can generate JSON faster than a complete HTML template. The JSON is also smaller than the rendered HTML document. This is big advantage for the vendor of the application. He can reduce server and traffic costs by sourcing out the rendering on the client. This has especially an effect for pages with a lot of visitors. For visitors who access the page with a smartphone, less traffic by serving a JSON object instead of a HTML document is also a big plus.

HTML-Rendering-vs-JSON-Rendering

AngularJS is by far the slowest solution for the client side rendering, but the development of the angularjs app was the fastest one. The application requires only a few lines of code (about 30 lines) whereas the BackboneJS counterpart needed more than 100 lines of code.

Résumé

For pages where the initial page load has to be very fast (e.g. for E-Commerce pages) server side rendering is the better solution. If you want to offer an app with a fancy page transitions, lazy loading of content and less traffic you can consider client side rendering. If you want to reduce the working costs of your server client side rendering is the right choice as well. For the development of a single page application a javascript framework is a must have. Without a framework your client side code ends up in spaghetti code and is hardly maintainable. For mobile single page applications BackboneJS is the better choice because it is faster than AngularJS. If you want to create an application with a few lines of code and performance is a nice to have feature AngularJS is the perfect framework for you.

The test is open source available at Github. Feel free to contribute. You can see the full client vs server performance test and its documentation in here: GitHub: Zarlex/Client-Vs-Server-Performance-Test

18 thoughts on “Client vs serverside rendering – the big battle?

  1. Pingback: JS Sources | Tech Raider

  2. Pingback: It’s time to look back over the blog highlights 2015 | Thinking Mobile

  3. Pingback: AngularU Day 2 - Viewpoint - Rightpoint Consulting

  4. Yogesh

    Thanks for the great post!

    I am unclear about something you mention towards the end: “For pages where the initial page load has to be very fast (e.g. for E-Commerce pages) server side rendering is the better solution”. The graphs show that for initial load time, client side and server side rendering have comparable load times. NodeJS (jade) server side templating and BackboneJS client side have similar performance for upto 100 entities and the differences start to become noticeable from about 300 entities.

    For an e-commerce site, I would expect loading (and caching) the first few entities ASAP is crucial and the rest can be loaded in the background while the user browses through the first few. Given this, and the fact that client side rendering reduces server load, wouldn’t it be the better choice? What am I not understanding correctly?

    Cheers!

    Reply
    1. Alexander Zarges

      The issue of client side rendered pages is that the performance depends on the hardware power of the device. You can not assume that every customer has a powerful device. When you are using a lot of JavaScript for your page to fetch content in the background the JavaScript file has to be fetched and executed by the browser. The browser is locked during the time when it is executed. The more javascript, the longer it takes to execute it, the longer the user has to wait until he can browse your page. On powerful devices you will not notice that time. However as you can see on the second graph, mobile devices especially older ones need much more time. Another factor that slows down the performance of your page are DOM-manipulations. When you append content via JavaScript you are making a DOM manipulation and DOM-Manipulations are quite performance expensive.

      When you are taking the server side render approach you are in control of the power of your server. The time it takes to generate the page on the server can be optimised by better hardware or more servers.
      The client has just to fetch the html document and stylesheet and then the page is ready to use. The browser doesn’t have to make any DOM manipulation stuff because the structure has been created already on the server. When the page doesn’t use JavaScript at all you are also saving the time where the browser has to execute the JavaScript files. The only time you can not control is the transmission time.

      For e-commerce pages milliseconds can have a huge impact if the customer stays on your page and buys a product or if she leaves your page because she is annoyed of the loading spinner.

      But smartphones are getting more powerful day by day and some of them are already more powerful then a desktop pc so you are right with the hybrid approach. My recommendation would be to generate static content that can be cached and has all the required information that is needed by the user like product information, price, purchase button,… on the server. Dynamic generated content like personalised recommendations for the user can be loaded in the background via JavaScript.

      Reply
  5. Pingback: Play Framework has lost its relevance. Or has it? | Knoldus

  6. tony

    Excellent! One reason using client rendering is json is easier to parse than html in native app.

    Reply
  7. Sigmund_Jung

    Were these tested with one client accessing one server? How about 1000 clients? I bet the server load would start becoming a problem — while the client rendering will remain the same. Maybe if you expect too much concurrency, client-side is preferrable.

    Reply
  8. Xingjian Shu

    nice post!
    May I ask what tools do you use to draw the figures? very thanks.

    Reply
  9. David Amend

    Thanks for the post! Really nice!
    Some comments:

    Consider using e.g. bindonce for angular, because it’s slowing down performance a lot.

    By using e.g. ng-init of Angular and passing data within the first html call, you make angular render the html, before it gets bootstrapped.

    How about the actual user experience? Is it a valid use-case to show up 1000 user entries at once? (As you stated already)
    The same for the mobile case. I would not show up 1000 entries in a mobile app, at once.
    Probably pagination would be slower on the server, because of http latency.

    How about gzipping use-case, caching & pre-loading/Lazy loading of content of pages ( like jquery mobile does by Ajax and you mentioned, already),
    because these are the biggest performance hits.

    Less traffic sounds like an argument for end user performance as well on mobile devices.
    Most apps are offline compatible, because it’s just faster and realiable, right?

    Reply
    1. Alexander Zarges

      Your right, you would never display 1000 entries or more on one page. But this was a stress test to show up the different rendering times. Lazy loading of content is for a real world applications the preferred way.
      The idea of using ng-init and pass all the required data for the template could make sense for small applications. But if you have a complex application with many templates and something like a router it justs speeds up the initial page request because you would not have to make an additonal ajax request. For all the other templates you would still have to make the ajax request.

      Reply
    1. Alexander Zarges

      The classical meaning of a SPA is to render it completely on the client, but you can follow a hybrid a approach like twitter does (https://blog.twitter.com/2012/improving-performance-on-twittercom). That means instead of delivering json data and baking them into the template on client side, you could render the template on server side. So your ajax call has to append html templates to the dom instead of processing json data.
      The advantage of this approach is that you would eliminate the performance issue of client side rendering. On the other hand it takes more effort to implement it because you have to move the templating stuff back to the server and you would have to deal with the performance on the server (which i mentioned in the post)

      Reply
  10. Pingback: Pure client rendering vs. server-side rendering | Alex Chin

  11. dskanth

    Thanks for throwing light on client side rendering vs server side rendering. I feel to go ahead with client side rendering.

    Reply
  12. Pingback: So long 2013 – looking back at this year’s blog highlights | Thinking Mobile Blog

Leave a Reply

Your email address will not be published. Required fields are marked *