The Performance Cost of a Perfect Look July 20, 2014

High performance has been a definitive characteristic of our software products - be it public facing websites or backend management systems. Optimized database queries, efficient application architecture and fine-tuned servers are some of the reasons why our applications run much faster than the competition. Moreover, when it comes to working with the creative team, our engineers negotiate every visual element that might have a performance impact. We often shower the designers with questions like "Is this absolutely necessary or just nice to have?", or "What are the alternatives to this layout?"

That appearance is part of the functionality is usually the reason why we have to overload a web page with custom fonts and layers of transition effects, which often results in a heavy page. Sometimes we have skew browser support, so that the page looks perfect on one browser, but suffers from slight sluggishness on another browser though looks identical. It is also important to understand that the converse is also true - a responsive functionality is part of the overall experience.

First, let's clarify what being responsive means. It has nothing to do with a "responsive design", in which the layout of a web page transforms gracefully to accommodate various device monitors. Here we take the word's original meaning - reacting quickly and positively. When you click a button, it should respond to your command right away. When scrolling down a page, the elements on the page should move up all in sync without jerky delays.

For example, the following input field turns yellow when it is focused. Its background turns green when losing focus:



The color of the above input box changes instantly as you interactive with it. It is being responsive to user input. Now open this page in Chrome and see the difference in responsiveness when 3000 input fields are displayed.

Now open this optimized page in Chrome. The input fields are responsive again! Even the initial page load was much faster.

The difference between the two pages is surprisingly subtle. When we first observed the slow reaction in a reporting component in Chrome, we thought that the sheer number of DOM elements was the culprit. It turns out that the number is just a magnifier. After ruling out other usual suspects such as dynamic elements, clipping, hash table collision (induced by specific class names), we arrived at this line:


At this point we have a technical solution: do not use right-adjusted text in the any of the input fields if the page is to be viewed in Chrome. Also we have a user solution: do not use Chrome, so that the input field can be right-aligned.

Clearly, the first option is more reasonable. We chose to drop the text alignment in favour of better browser support, especially when the said browser is a popular one. Having said that, we strongly recommend our customers to use Firefox instead. Although we performance test our web products with all major browsers, it is not the case with other vendors. Chrome (v36.0) uses both too much CPU and RAM, and is therefore not suitable for heavy-duty usage.