views:

1405

answers:

10

I have come to find that using jquery to create html client-side can be a huge performance booster if done properly. I use ajax returning json to retrieve dynamic content and then I build the relevant html and insert it using jquery. The first time I messed with this technique I found that the string concatenator in IE's javascript performed really slowly so that building a dynamic table with more than 50 or so rows performed terribly.

var shtml = '<table>';
for(var i=0;i<100;i++) shtml += '<tr><td>A bunch of content</td></tr>';
shtml += '</table>';
$('#myTable').append(shtml);

Then I found a technique for string concatenation that changed everything. Instead of using the sting += operator use arrays to do concatenation;

var shtml = ['<table>'];
for(var i=0;i<100;i++) shtml.push('<tr><td>A bunch of content</td></tr>');
shtml.push('</table>');
$('#myTable').append(shtml.join(''));

I found that performance improved significantly. Now, however, there is a ceiling of about 100 rows before I start to see the browser itself struggle with dynamically inserting so much content at once. Does anyone have any pointers or techniques that can be used to help me achieve the next performance boost for large sets of dynamic html?

A: 

You would probably get better performance if you do the HTML generation on the server side, and then use Ajax to retrieve the html and append it to your DOM. (I'm assuming you're getting all the data from the server using Ajax anyway.)

davogones
Actually, I have found that performance is MUCH better generating the html client-side. The biggest bottleneck with html pages is using bandwidth, not CPU. Try appending large amounts of html to the DOM. You will see it is not very efficient.
MonkeyBrother
Depends on how you append it. innerHTML is pretty fast.
Dave Ward
+1  A: 

Have you considered using a templating library? PURE has very good performance, for instance (try out the 500 row example).

Dave Ward
A: 

i was messing around with appending large amounts of html yesterday. i think rendering on server side and inserting is the way to go, also i may add, that not using jquery is faster by 50-100ms in my tests, which are here:

http://programmingdrunk.com/playground

you will need to enable firebug console to see speed results

mkoryak
+3  A: 

Be aware that often the speed bottleneck is not creating the DOM, but inserting the DOM. This is especially true on IE with complicated style sheets and when the new content contains many levels of nested tags.

See: http://bitkickers.blogspot.com/2008/12/ajax-grid-performance-in-ie.html

Chase Seibert
+1  A: 

Try cloning parts of the dom itself rather than generating it on the fly (ie, append actual DOMElements so they don't have to be created).

Matt Gardner
A: 

Chase is right, it doesn't matter how fast you can generate the HTML via JavaScript, it's the DOM insertion that will kill you. Tie any programming language with the DOM and it'll be slow.

My only suggest is to have the table paginated so you don't load so many at once, or maybe not to use AJAX at all.

jay_soo
A: 

There's a performance issue with jQuery and inserting a large string of html to the DOM, due to its $.trim function.

I sometimes find plain old dom scripting much faster than using jquery. Try something like

document.getElementById('id').innerHTML = myarray.join('')
snz3
"I sometimes find plain old dom scripting much faster than using jquery." this goes for most any JS framework, I think - too many things going on under the covers when all you want is simple DOM creation/insertion
matt b
A: 

In my case,document.getElementById('id').innerHTML = myarray.join('') is also a killer since array have 10 HTMl strings. The joins would create a big long string and nnerHTML performance varies significantly between 100ms to 1200ms on IE 7.

any cluses?

A: 

I recently add a blog entry regarding this topic at http://geeks.netindonesia.net/blogs/jimmy/archive/2009/04/23/how-to-display-huge-amount-of-data-in-a-web-grid-quickly.aspx

Jimmy Chandra
Oops, I guess I should have read the first answer first :)
Jimmy Chandra
+1  A: 

Interestingly, I found that array push has not saved me any significant time compare to string concatenation on FF. and even the little time that it saved was lost to array.join('') at the end. Has anyone experience the same thing?

David
Agreed -- in my tests FF was marginally *slower* with array.join (15%) but IE sped up by 80%. So I used a small closure "StringBuilder" class, which worked fine.
NVRAM