views:

198

answers:

3

The things I'm trying to get my website to do are getting fairly complex, some of the things that need to be done take long enough that it gives visible delays.

Mainly, adding content to the document slows things down as well as jquery animations that I'm using.

I create elements using document.createElement("div") rather than just doing document.write(""), and the animations are the custom animation using .animation();

I'm wondering how I can continue to add content as I am but prevent the browser from freezing every time I want to add something.

Any suggestions for speeding things up so there is less of a delay? Tips on what to avoid in javascript programming that gives increased delay would be really helpful.

Thanks, Matt

+2  A: 

This sounds more like you want to improve the DOM interaction performance rather than javascript, so in that vein:

  • Yes, document.write is bad, it blocks additional loading (any JS executing before your pages has finished loading basically requires all other processing to stop -- modern browsers like Safari (and by proxy Chrome) and Firefox do a degree of content preloading in order to prevents loads from blocking but subsequent style resolution, etc is largely blocked.
  • document.createElement is in general the best solution, although their are certain cases where just manipulating innerHTML on an element may be faster -- but that is not yet cross browser compatible (i think innerHTML doesn't exist till Firefox 3.5) and the perform characteristics are tricky.
  • Reduce the amount of content you load initially -- eg. if you have lots of content (or content that requires large scripts) attempt to delay loading until after the initial page load has completed.
  • Oh, for animations you should look at CSS animations and they perform much better than any JS implementations, but they're only present in Safari (and by proxy Chrome) and Firefox 3.5 -- definitely not in IE :-(

In terms of JavaScript performance, avoid with and getters/setters like the plague and you should be fine in most modern JS implementations.

olliej
How much do getters/setters hinder performance? The way I was taught to program you shouldn't just leave variables public, but I guess if getters and setters take a lot of computing power then it may be worth the sacrifice...
innerHTML definitely exists in Firefox 3.0.4 and later, and in Safari 3 as well. I've used it. Even though it very well may not be the best cross platform method of manipulation, it is not quite as limited as you think.
A. Levy
@A. Levy: Maybe i was thinking of innerText?@Matt: use a function rather than the ECMAScript getter/setter features. Getters and setters defeat property caching and result in an unexpected function call that catastrophically impacts performance -- in Safari4 for instance i believe getters/setters are around 10x slower than an ordinary function call.
olliej
Just as an example i banged together this simple testcase -- http://nerget.com/jstests/performance/getters-setters.html
olliej
+1  A: 

JQuery is great for manipulating the DOM. I'd take a look at their code in order to get some ideas. Or, seeing how I'm way lazy, I'd just use their stuff.

In one of the podcasts Jeff Atwood mentioned you'd have to be crazy to write your own javascript... after using JQuery, I'd have to agree with him.

Esteban Araya
A: 

What surprises most people is that using innerHTML is, actually, the fastest way there is to manipulate the DOM.

You can see one benchmark here for example.

Itay Moav
it depends entirely on the use case, the engine being used (IE has a horrifically slow DOM implementation), and the length of code in the html -- modifying innerHTML requires the whole string to be reparsed and the dom to be reconstructed. If there are many elements in the string, or if the string is long then modifying innerhtml will be slower. Also if you're holding references to the elements in the innerHTML block those elements will stay around but will not reference the new nodes created in their place.
olliej
more elements in InnerHTML means more elements to create also if you want to use the "prefered" DOM methods. Not sure you are right in this point. As for the other problems...Never said it was the perfect solution, just the fastest. I encountered many cases where it was more convenient NOT to use innerHTML (You must admit innerHTML is the most straight forward way there is).
Itay Moav
The point i was making is that innerHTML is not always fastest -- if you have a piece of html,`<li>...</li><li>...</li>...`if you add html to the end of the list with foo.innerHTML += "<li>" +text+"</li>". The engine has to reparse the entire string, and reconstruct the DOM for all of it, so parsing isn't free, creating elements isn't free, there is a point when adding a new dom-created element is faster than adding to innerHTML, and if you want to reference elements in the list, then modifying innerHTML will require you to re-get those elements.
olliej
A testcase: http://nerget.com/jstests/performance/dom-manipulation.html the DOM API has (to all intents) O(1) insertion, innerHTML has O(length of innerHTML) complexity
olliej
Good point [thumbs up] (will they add icons?)
Itay Moav