I have a large "grid" of data that takes about 40 seconds to generate and dump as plain text. If I wrap the text with html table formatting (with fixed td widths) it takes over 200 seconds to completely display in IE7, and under a minute to display in Safari. Small "grids" display in under 5 seconds in either browser, so I don't think it's related to anything other than data volume. Is there anything I can do on the server side to speed up IE7 display? Telling the users to stop banging their heads against the wall is not an option.
+10
A:
Set the css attribute for table-layout: fixed on the table. IE will then not have to recompute the table size for each additional row / column that's added and it will speed up dramatically.
BTW, the w3schools link has some good info about this.
table-layout takes one of three values: auto, fixed, and inherit.
auto is the default. The browser has to load the entire table before it can compute the sizes and start rendering. This ranges from slow to very slow depending on the rendering engine of the browser.
fixed. The first row defines the width of the columns. Because of this the browser can render content as it's downloading. Hence the speed increase. As a minor side note, because all width's other than the top row are ignored, you don't have to send the width data down for remaining columns... Which means your page size can be a bit smaller.
inherit. Basically, get it's value from the parent.
Chris Lively
2009-06-25 20:27:02
In his question he said he had fixed td widths. Does it help to put "fixed" on all the table tags? table? td? tr? tbody? thead? etc.
Nosredna
2009-06-25 21:22:10
table-layout only applies at the table level. so the definition should read <table style="table-layout:fixed"> Even though he has hard set the td widths, the browser still has to load the entire table before the layout manager can determine that everything is in fact fixed width. Unless you have that css tag applied.
Chris Lively
2009-06-25 22:35:00
This sounds good, but I already had <table style="table-layout:fixed"> in there. I summed up the <td> widths and put that in the table style too, but the benchmarks on IE are still ugly.
Ross Morrissey
2009-06-26 17:14:25
+1
A:
I'm sorry, but IE7 is just an old browser, and thus isn't quite as fast as Safari...they might see some performance increase if they upgraded to IE8, or Firefox, or Chrome...
Thomas
2009-06-25 20:27:54
Age has nothing to do with it, really. Trident has just never been all that great at table layout. It was most likely a design trade-off... the IE team didn't feel the need to optimize for ridiculously large tables.
jeffamaphone
2009-06-25 20:36:16
I would love to know what they were optimizing when they were busy not optimizing huge tables.
Nosredna
2009-06-25 21:23:40
+1
A:
Perhaps paginate the grid, probably will make it more readable, and faster on both browsers?
Kazar
2009-06-25 20:30:43
+1
A:
Why is IE7 so slow compared to Safari?
Because they have different HTML engines, that work differently, different algorithms, different etc's
Is there anything I can do on the server side to speed up IE7 display?
Perhaps you could try using Ajax. That way the perceived speed will be much better.
OscarRyz
2009-06-25 20:31:54
"Perhaps you could try using Ajax. That way the perceived speed will be much better." Really? I don't think my perceived speed is going to be high if the page loads quickly, but then spends about 200 seconds getting (via XHR) then rendering the table I actually care about.
Matthew Flaschen
2009-06-25 20:34:47
@Matthew: In case you're being serious you could do the following: a) load a subset of the data in the server, something that takes 10 seconds rather than 200. Pull those records in the client with ajax, and request for the next chunk. Repeat until you get it all
OscarRyz
2009-06-25 20:45:10
+3
A:
Even the Safari "under a minute" seems unbearable. Wherever I have anything that slow I put up a progress bar and some stats about the data.
Kazar's pagination idea may be the way to go, or progressive loading as Oscar Reyes suggests.
Just how many rows and columns is this data that it takes that long?
Nosredna
2009-06-25 20:39:08
61 Rows, 5 columns, 64k. Note that it takes probably 30 seconds to generate the table (but that's a different problem). I dump out a padded header to get things looking responsive ASAP, but it's just that the final result takes way longer in IE. 1400 Rows, 5 Columns, 1.4 mb download.
Ross Morrissey
2009-06-26 17:59:12
Just an idea: Have you tried NOT using a table? Just to see what the speed is? What happens if you just put all the info out as fixed-width text in <p></p>?
Nosredna
2009-06-26 18:25:21
+1
A:
Since you're programmatically generating this data anyway, you might try using <pre> tag which will display the text in a monospaced font. This way, you can quickly calculate cell width and height yourself. It won't look the prettiest, but it will avoid any layout time.
If you don't want to do this by hand, and you have no links in your table, you can use the elinks web browser to render the HTML to plain text and place that output in <pre> tags.
elinks -dump ./localfile.html
On a secondary note, if you haven't already, you should insure that you are gzipping the data on the server side, so that transfer time is reduced. For IIS, instructions to enable gzipping can be found here. For Apache, instructions to enable mod_gzip can be found here. For Apache, try Apache's own documentation on mod_deflate.
Conspicuous Compiler
2009-06-25 21:14:00
A:
These are all great suggestions - but I found the smoking gun! When IE renders the page, a process called Mcshield.exe takes over the machine. Since the server is on the same box, it slows the page generation as well as the rendering. Now the question is "why does McAfee crush IE and not Safari?" - and I'll research that one. Thanks again Stack Overflow!
Ross Morrissey
2009-06-26 18:18:21