At a recent UI/UX MeetUp that I attended, I gave some feedback on a website that used Javascript (jQuery) for its interaction and UI - it was fairly simple animations and manipulation, but the performance on a decent computer was horrific.

It actually reminded me of a lot of sites/programs that I've seen with the same issue, where certain actions just absolutely destroy performance. It is mostly in (or at least more noticeable in) situations where Javascript is almost serving as a Flash replacement. This is in stark contrast to some of the webapps that I have used that have far more Javascript and functionality but run very smoothly (COGNOS by IBM is one I can think of off the top of my head).

I'd love to know some of the common issues that aren't considered when developing JS that will kill the performance of the site.

  • Likely the same as with every other program: Doing more work than necessary and doing the same work over and over again, often hundreds of times. – user7043 Jul 1 '11 at 14:46
  • 1
    @delnan that's very true, but it seems like it is a lot more prevalent in JS. Perception maybe? – Nic Jul 1 '11 at 14:48
  • 1
    It's getting to be somewhat passe to speak of 'the site' when talking about JavaScript. It's everywhere and being used for everything these days. – Adam Crossland Jul 1 '11 at 14:50
  • @Adam Crossland you're absolutely right - in that same instance I think I helped a developer with a native app that heavily relied on jQuery as well. – Nic Jul 1 '11 at 14:52
  • 1
    Not exactly an answer to your question, so I make it a comment: I've experienced situations where JavaScript did a lot of rendering, and it was actually the rendering engine of the browser that used up the seconds. Therefore, to handle a performance bottleneck, I would look for unnecessary rendering operations first. – user281377 Jul 1 '11 at 15:48

A common performance killer is calling .length on an HTMLCollection inside a for loop:

function foo(collection) {
    for (var index = 0; index < collection.length; index++) {
        // do something awesome here

That anti-pattern causes the size of the collection to be calculated on each pass through the loop. The better approach is to calculate the length outside the loop:

function foo(collection) {
    var collectionLen = collection.length;
    for (var index = 0; index < collectionLen; index++) {
        // do something awesome here
  • 3
    Depends on the browser. Take this benchmark as an example: In FF 5, the "normal" one runs in pretty much the same time as the "optimized" version. And even in really old and sluggy browsers, something like this likely won't be a bottleneck if the JS actually does anything of interest with the elements. – user7043 Jul 1 '11 at 14:55
  • 1
    Hmm! Perhaps the highly-optimizing JIT compilers of today are making this bit of wisdom obsolete. – Adam Crossland Jul 1 '11 at 14:59
  • 4
    I'm not a real expert here, but from ECMA spec it appears that length is just a property of array object. So calling it just returns value instead of counting all the elements. No idea if all implementations follow the spec, but if they do, your code don't improve performance at all. – Jacek Prucia Jul 1 '11 at 15:36
  • 4
    @JacekPrucia He said collection, not array - usually, in real code, this would mean a list of DOM elements returned by functions such as document.getElementsByTagName. The function returns a live nodeList which re-calculates its length every time the .length property is accessed. – Yi Jiang Jul 1 '11 at 15:55
  • 2
    @JacekPrucia benchmark it's a performance improvement. Property lookup is not cheap. – Raynos Jul 1 '11 at 16:36

No, the problem does not come from JS used as flash replacement. If you are not convinced with that, document yourelf about actionscript : it's very close to JS.

As performances killer, you can find several bad practices :

  • Attach event handler on continuous event, like scrolling, mouving the mouse or similar stuffs. This has 2 drawback : if the event is not triggered enough, your application will not be reactive. If it's triggered too much, you will have an huge CPU load for nothing.
  • Making synchronous AJAX calls. Javascript isn't multithreaded, then, when a part of JS is waiting for something, your application is frozen. You's better use asynchronous AJAX calls, and the same way use setTimeout/setInterval to split a long computation phase and keep your application reactive.
  • High algorithm complexity like in any other languages.
  • I've seen more than a few apps try to rotate, ease, or animate full-browser images and fail miserably in the process - that's where the Flash replacement comment stems from :) – Nic Jul 1 '11 at 14:58
  • Since the first A in AJAX stands for asynchronous, technically it's not AJAX if it's synchronous, but your point is still a good one. – Karl Bielefeldt Jul 1 '11 at 15:12
  • Yes right, it's not strictly AJAX. But anyway, this must be avoided :D – deadalnix Jul 1 '11 at 17:41

I gave some feedback on a website that used Javascript (jQuery) for its interaction and UI - it was fairly simple animations and manipulation, but the performance on a decent computer was horrific.

The one biggest problem with performance is using high level abstractions (like jQuery) without understanding the underlying DOM model and CSS3 animation model (or canvas, or svg).

If you do not know how to do it without the abstractions then you have absolute zero knowledge of what techniques are fast or slow.

Learn JavaScript, Learn the DOM. Once you know those two and you know what your abstractions do under the hood then you can use them efficiently. Of course most of the time you realise the abstraction is to slow and just do it manually without a library.


The beauty and drawback of Javascript is that it is extremely flexible. That being said, it actually allows you to do things that you probably shouldn't do in a lot of cases.

From the code reviews that I have been a part of, the major concerns tend to be related to CSS rendering. For newer JS developers, we tend to see way too many variables being used in the global scope.

Also, improper closures can often cause memory leaks. However, most modern Javascript frameworks prevent these kinds of problems as long as your code follows the framework.


Here is a quick link that I found a year or so ago about writing better jquery code: http://net.tutsplus.com/tutorials/javascript-ajax/10-ways-to-instantly-increase-your-jquery-performance/

One thing I just found in a co-workers code that was killing performance was caching data that didn't need to cached.


var table = $("#data").dataTable(.....);

DataTables is a jQuery plug-in that we use to make nice grids. Anyway, the table had nearly 5k rows in it, applying the DataTables plug-in and then saving it in the table variable actually caused both FireFox and IE to warn that a script was taking too long. Moral of the story, only cache the data if you need to.

  • 1
    Sounds like DataTables being a really inefficient / poor plugin rather then a problem with caching. 5k is nothing. – Raynos Jul 1 '11 at 16:02
  • @Raynos: He said 5k rows, not 5 kilobytes of data. A "row" could be a very large thing. – Chris Farmer Jul 1 '11 at 20:44
  • @ChrisFarmer If a "row" is a very large thing then you've got a different problem. – Raynos Jul 1 '11 at 20:51

From what I've heard for loops are computationally faster than jQuery's $.each().

  • 3
    Is this a joke answer? – Raynos Jul 1 '11 at 16:37

Not the answer you're looking for? Browse other questions tagged or ask your own question.