AjaxLine

Everyday dealing with creating and animating web sites I began to notice a very unpleasant peculiarity — one at the same JavaScript code works with the different speed on different sites. The cause of such strange behavior was found very promptly: speed of a script execution depended directly on the way the site was HTML coded. Searching of solutions of the arised problems was quite exciting but unfortunately I couldn't share the results of my investigations because of the local character of all the solutions. For example a certain site was working slowly but it was enough to change one construction to another for it to work twice quicker. Getting such an explanation the only thing a reader can do is to be happy for me as there is very little practical benefit from the offered solutions. This fact became the first reason of my researching of the up-to-date browsers general problem places.

The second reason is buzz around a new versions of browsers. I guess there is no secret in the fact that JS code in browsers works quite slowly (in comparison with, for example, the same program written in C++). Developers realized this comparatively recently and started rewriting JS engines of their products for increasing of their performance (V8 in Google Chrome, TraceMonkey in Firefox and so on). Plenty of tests for their engines performance measurement appeared in the Internet. The most well known of them are SunSpider and Dromaeo. This tests are of quite high quality but many users just don't pay attention that these are namely JavaScript Performance Test and not Browser Performance Test. In my opinion their results are far not objective for up-to-date web applications. Is it correctly to assert that one browser is going to be faster then another one in all possible cases?

Let's look at an example. In Dromaeo there is such a test as DOM style. I am not going to pay match attention to it's implementation, I just want to mention that it selects all div elements from the page and and tries to change their color and display properties (I interested exactly in a style modification). And what is going to happen if we put this elements in other environment (i.e. on a page HTML coded in another way)? Thus we have a different result. And what if this element will be not div but an image? It will be already the third result. And what if certain CSS styles will be set to this elements? So you've got it :-)

As the result performance of a web application depends not only on JS engine but also on the browser engine. To demonstrate this I created several simple tests.

The methods of testing

1. In the compared examples a user should see one and the same result. That is let's keep in mind the fact that one and the same goal can be reached in different ways.
2. Simple JavaScript animation is used in all the example and as the result there is quantity of frames per second (FPS).
3. The higher result the better.
4. In the process of testing it was very difficult to obtain identical results per several iterations of one and the same test in one browser. That's way for a measurement error I assumed 3 FPS. I.e. if result of one test differs on ±3 FPS from another one I consider they are equal.
5. All tests were run several times and the average result of all the runs was accepted as the final one.
6. Test computer : MacBook Pro @ 2.16 Ghz Intel Core 2 Duo, 2 GB RAM. Windows-browsers were tested in Paralells Desktop 3, various versions of IE were run on various Virtual machines.

Results

position: relative vs position:absolute

For a long time I have been interested what works faster: an element with position: relative or position: absolute?

position:relative

position:absolute

As you can see from the results, Opera is the only browser which performance depends on the way the element being modified is positioned.

position: relative vs position:absolute with big amount of elements

In the Internet one can often meet advice to decrease amount of elements in DOM tree. There are such uncertain arguments said in their favour as "Why garbage DOM?", "The less elements the quicker site is loaded" and so on.

Lets check how this affects performance. For running this test I wrapped each word in the content block with a span element. As the result the total amount of DOM elements on the page is 942. Compare (warning: Russian :-):

• Result of search in Google — 384 elements
• Result of search in Yandex — 555
• The main page of mail.ru — 1196
• The main page of lenta.ru — 2669

In this test the examples were compared with the first test but not with each other. We just want to demonstrate dependency of performance from the quantity of elements but not dependency from the way of the elements positioning.

position:relative

This test

position: relative vs position: absolute

position:absolute

This test

position: relative vs position: absolute

So small amount of elements in DOM tree is not only aesthetics but significant increasing of up-to-date browsers performance.

position: relative vs position:absolute with big amount of elements with border

Now lets make the previous test a little bit more complicated: lets add to all span wrappers CSS property border: 1px solid #fff and see how it affects performance. Keeping in mind that a user should see the same result in all the tests. Lets block border effect with the help of margin: -1px property.

position:relative

This test

position: relative vs position: absolute with big amount of elements

This test

position: relative vs position: absolute with big amount of elements

At the first look Firefox has significant failures in performance, but the overall result does not differ a lot from the previous test.

I really believe that the guys from Microsoft will get rid of such failure in performance in the final version of their new browser.

Depth Of DOM Tree

Using analogy with the test of big amount of elements lets check dependence depth of tree on performance. For this purpose I created a structure consisted of 30 nested in each other elements. In the first case I wrapped the whole template with this structure and in the second case just appended this structure to the end of the template (to normalize amount of page elements). To justify appearance of these elements (they are added not for fun),
I set their CSS styles margin: -1px; padding: 1px; width: 100%;

Deep tree

Shallow tree

Animation of semitransparent image

What is faster — a nontransparent image with CSS opacity property or a semitransparent image?
IE6 was excluded from the test on purpose: the only way to show a semitransparent image to use filter AlphaImageLoader which increases animation performance by itself.

opaque

transparent

Definetly animation with a semitransparent image is much smoother in up-to-date browsers than animation of a nontransparent image with opacity property. Speed increase of a new WebKit is impressive.

Despite not bad result, animation in Google Chrome works rather slow.

Image vs background image

Task: to put an image as background with animation running on top of it. What is going to work faster: obvious CSS background-image property or img element?

Background

Image

 

As you can see from the examples obvious (for such task) use of background-image resulted in serious decrease of performance in both Safari and Opera. And the problems were indicated namely in the Mac versions of this browsers.

Despite the high result animation in Opera (Mac) looks very unpleasant (strong jerks are visible).

In reality in some cases img works faster than background-image also in Firefox (in this test it is not noticeable).

Stretched image

What will happen if background image from the previous test will be enlarged on 1 pixel in HTML?

Normal state

Stretched state (+1 pixel in width)

It looks like up-to-date browsers are not able meanwhile to optimize such tasks and redraw stretched image with the every change on the page. Problems appear namely in those browsers that smooth stretched images.

Even Firefox 3 page scroll goes slow on big images.

Conclusion

As seen from the above mentioned tests situation with up-to-date browsers is not definite. At the end of this article I would like to summarize all advice that can help with a project optimization.

1. It is better to use position:absolute for interactive elements.
2. Big amount of elements on a page can decrease performance but it does not worth reducing them not to lose reliability of the template.
3. Don't do very deep nested structures of elements.
4. Before starting HTML coding you should better learn which interactive mechanisms are to be here thus you are going to get rid of many problems already on the first stage of your work on the project.
5. Don't let silly stereotypes catch you. Only developers themselves and not others need validity and semantics.
6. Don't stretch images without necessity. But if you need to do this use canvas.
7. As the rule img element will work faster than CSS background-image property.
8. Remember the main rule: only those things which require optimization should be optimized.

About the author

This article was written by Sergey Chikuyonok front-end developer and author of Good Sense in Web Development blog.

Psd to Html service

Quality Psd to xhtml service