Improve view rendering performance in ember.js

One of the key reasons of ember’s less popularity is poor rendering performance. Almost every ember vs angular articles raises the point of rendering performance with example and shows how angular is better than ember.
Well, but it’s not false that ember is slow; we all know that. We also know that embers does lots of extra things to make binding performance better and to do that it takes the extra time while rendering. HTMLBars may help ember for quick rendering; but for the time being the examples below will help you to render your views faster.

Different tests

I’ve made few examples or you can say small tests to render 1000 views. Using ‘Ember Inspector’ I noticed the rendering time in each of the cases, and the results are as follows:

1. Without any if, else, with or bind-attr

Example Link:
Rendering time in Chrome: 380ms (avg of 5 tests)
Rendering time in Firefox: 460ms (avg of 5 tests)

In this example I didn’t use any conditional blocks in handlebars; neither used any helpers like with or bind-attr. The view has been rendered 1000 times.

2. With if else

Example Link:
Rendering time in Chrome: 650ms (avg of 5 tests)
Rendering time in Firefox: 750ms (avg of 5 tests)

In this example I have used conditional blocks in handlebars. The view has been rendered 1000 times. What if else does is, depending on conditions it completely adds or removes certain parts of the DOM. To do this, ember creates HandlebarsBoundView (a private view) which is heavier one; and thus takes more time to render.

3. With bind-attr (show hide by css class)

Example Link:
Rendering time in Chrome: 415ms (avg of 5 tests)
Rendering time in Firefox: 495ms (avg of 5 tests)

In this example I didn’t use conditional blocks in handlebars; rather I used bind-attr helper to add and remove a class to hide/show a div. The end behavior is similar to the previous test; but in this case, ember will not completely add or remove a portion of DOM; hence it won’t use HandlebarsBoundView and the rendering will be less time consuming.

4. With bind-attr (class show hide) – binding via hbs instead of js

Example Link:
Rendering time in Chrome: 460ms (avg of 5 tests)
Rendering time in Firefox: 520ms (avg of 5 tests)

This test is very similar to the previous one. The only difference is, the binding is given through handlebars now. In this case the time taken for rendering is little higher than example#3 where the binding was given through javascript.


The above examples or tests shows how render time differs in different cases. According to the test results we can come down to the following conclusions:

  1. It’s better to use bind-attr helper and show hide a div on certain condition, rather than doing the thing with handlebars if else.
  2. Try to make the bindings through javascript as much as possible; rather than handlebars.

N.B: The time taken for the tests may vary from computer to computer, but the ratio of delay in different tests will be similar.

Still having issues?

If you still have issues understanding the above article, please leave a comment below and we will try to address that. In case you need help in your projects or understanding anything related to Programming; contact me, Paul Shan for assistance. Thank you for being a reader of VoidCanvas.

About This Author

Hello! I am Paul Shan, a JavaScript Expert, Full Stack and DevOps Engineer cum Consultant based out of Bengaluru, India.

  • ramchiranjeevi

    HI Paul Shan,

    Thanks a lot for your details analysis on view rendering performance.

    You can also use “unbound” handlebars helper, it output the property in the view without binding. So where ever you don’t need to update the property dynamically you can use “unbound” helper.

    By using this the rendering performance increases, but with caution where it does not autoupdates.

    If you have a time can you run with your tests using unbound helper in your view and share the performance increase.


    • metalshan

      Yes, unbound doesn’t deal with any metamorph. It just paste the VALUE as it is. But in this case my examples were basically for view rendering, so didn’t focus on that. But yaa, I should put another point describing how unbound can help us. Will add that soon. Thanks for the advice 🙂