The Industry

Optimizing JavaScript Performance

Again, much information on this subject can be found by using a search engine, but a few techniques that we found that help speed up our JS from 30% to 300% are not mentioned very often, that I could see anyway.

getComputedStyle

The first is to watch the usage of getComputedStyle. This is very, very slow on Google Chrome [assume all webkit-based browsers like Safari as well] and also IE (8 in this case) to some degree as well.

In our case we were accessing, essentially, prototype’s Element.getStyle over and over again to get the values of up to a dozen styles for each element. What we did instead was to make a getStyles method and pass in the list of attributes we wanted. This method created and filled in a hash table [i.e. object] with the names of the attributes mapped to their values. The getStyles method just called getComputedStyle once.

This sped up Chrome by about 3X, IE about 30% and even FireFox [which uses a different method, but one which must still have to do some work behind the scenes] by about 15%.

array.length

Maybe this is well known, but not talked about much, but accessing arrays, again on Chrome (webkit) and somewhat on IE, is freaking slow. Pulling any array.length out of loops and putting the length into a local variable sped up, in our case, things by 30 to 50%. It’s nuts - its ridiculously simple, it kind of clutters the code, but it works.

FireFox seems unaffected by this technique [i.e. they must cache the array length with the array like anyone would who thought people might want to use arrays in their code sometime].

———

That’s about it. Magazines.me was designed to be fairly fast anyway - we knew up front that we were going to have to be executing a lot of JavaScript each time a page was loaded, so we had done the obvious things already. But these two slow pokes were a kind of minor annoyances - but they certainly had a very significant impact on measured performance.