views:

183

answers:

3

I have a page which displays ~300 pages worth of tabular data. Firefox, Chrome, Safari all work fine but IE 7, 8, and 8 Compatibility view all wretch. It lags for several seconds when I try to scroll or press the page up/page down button.

Pagination, smaller data sets, and other usability suggestions will not work for this page. Assume I absolutely have no choice but to display all this data at once... what are some things I can do to tweak it?

The data is being loaded via jQuery/Ajax and that seems to be at least in part suspect here, because when I created a test page to render the results directly it isn't quite as slow, but still not nearly as snappy as other browsers.

I've successfully used jQuery plugins such as SlickGrid to tackle similar problems in the past, but for reasons that would take a long time to explain they are not an option, even with the micro template rendering capabilities. I'm mainly concerned with what tweaks I can make to improve performance without reworking the entire page or introducing third party solutions.

Is a simplified DOM going to make a big difference? Or does IE not handle data brought in via JavaScript/Ajax well?

+2  A: 

Difficult to see without more details or an example... how are you building the content? There are quite a few little catches with building table content: in particular setting innerHTML directly on <table> doesn't work in IE, so jQuery's html() will probably be doing it a long, slow way round if that's what you're using.

But a general-purpose tip for anything with tables, especially larger ones: set the style table-layout: fixed on the <table> element, setting column width styles on either the first row of cells only, or on a set of <col>​s. (Columns without an explicit width will share the remaining width equally between them in a liquid layout situation.)

Since it does not depend on the quantity of content in each cell, fixed table layout is faster and much more predictable than the default auto table layout algorithm.

bobince
A: 

I've found that when you're dynamically inserting large, complex content into an existing page, IE is much (much) faster at setting innerHTML than at programmatically creating dozens or hundreds of DOM nodes and inserting them, whether you're using a client-side library or not. If you render your HTML server-side and send it down as a string instead of sending JSON data and rendering client side, you're using more bandwidth, but your IE users will probably have a better experience.

IE's javascript performance is currently pretty terrible, so if you want to make your site faster in IE, minimizing large-scale DOM manipulation is a good start. It shouldn't be too difficult to make a simple test case for comparison, to see if such a change will benefit your particular situation.

Joel Mueller
A: 

use innerHTML and minimise js / dom interaction. Js isn't that slow in IE but the js/dom bridge is very slow. Also avoid to select elements in the html you are about to insert. If you do so, jQuery will have to walk through each element and test against the id or css attribute. This is very slow.

In itself inserting a few thousands elements in the DOM in IE is doable. but if you start doing some changes on this html, you may runs into severe perf issues.

Beyond that, your code is needed in order to tell how to make it faster. also a test page that can be profiled would be great.

FYI, the only performance profiling tool available for IE is dynatrace ajax version. Its free and an excellent quality software. Use it !

Olivvv