Welcome to WebmasterWorld Guest from 188.8.131.52
Forum Moderators: incrediBILL
I was having some serious rendering problems in netscape (over a minute to render) and through a few tweeks was able to get it down under ten seconds... added the 'cols' attribute to my table tags (I never knew this mattered sooo much) and got rid of a few tables.
I had a form with hidden varibles within one of my tables... just moving this out of the table got me about a 30% savings in rendering time!
Any other weird tweeks anyone has come across for netscape are more than welcome.
I never heard about the COL element speeding up rendering before, but it makes total sense. Along with COLGROUP it is a senior element -- the place where browsers look first when rendering a table. I have a some pages where I'm going to put that one into use.
Your FORM tip surprises me a bit, since the W3C explicitly says that one use of tables is to align form elements. But, given other problems with Netscape, maybe nothing should surprise me.
I've also noticed that setting (accurate) widths for tables and cells can also speed up rendering in Netscape (especially) and in Explorer. Here's a quote from W3C
Authors may specify column widths in three ways:
A fixed width specification is given in pixels (e.g., width="30"). A fixed-width specification enables incremental rendering.
A percentage specification (e.g., width="20%") is based on the percentage of the horizontal space available to the table (between the current left and right margins, including floats). Note that this space does not depend on the table itself, and thus percentage specifications enable incremental rendering.
Proportional specifications (e.g., width="3*")refer to portions of the horizontal space required by a table. If the table width is given a fixed value via the width attribute of the TABLE element, user agents may render the table incrementally even with proportional columns.
However, if the table does not have a fixed width, user agents must receive all table data before they can determine the horizontal space required by the table. Only then may this space be allotted to proportional columns.
If an author specifies no width information for a column, a user agent may not be able to incrementally format the table since it must wait for the entire column of data to arrive in order to allot an appropriate width.
These last two points are the situations to be avoided in our code, because we want the browser to be able to render the table incerementally rather than all at once.
Be careful to pay attention to the difference between Navigator (4.x and earlier) and NS6 rendering engines. The two are basically unrelated and have very different performance (and rendering) characteristics.
As with other browsers, CSS is the way to go for speed.
On NS6, stay as far away from FONT elements and nested tables as you can. Be absolutely sure you close all your FONT elements, since unclosed FONTs slow the renderer to a crawl if you have enough of them. Some changes have been made in Mozilla to speed up the FONT problem dramatically, but those didn't make it into NS6.0. Nested tables get you O(n^2) behavior currently due to a bug that hasn't been fixed yet. NN4 doesn't do well with them either. NN4 does handle unclosed FONT elements much better, though.
COL elements work on NS6, but are ignored by NN4 (AFAICT).
Splitting up tables helps with most older browsers, including NN4 I believe (but probably isn't a huge gain with NS6 and IE5 due to their thorough support for incremental rendering--there may cases where it helps a lot, though, since they can't afford to update the display every time a new chunk comes in).
Amen to that.
I have been undoing tables for layout as fast as I can and positioning the page elements with CSS. The pages seem to fly onto the page by comparison.
Now I try to use tables just for true tables -- after all, they were not originally intended for layout. But I still find times when I need a layout table to hold the pieces of a sliced up graphic together.
You can find netscape's documentation of it at...
It is a pretty hairy definition that they give. And from reading it I realize that I wasnt using the attribute as intended... (it is for indicating the number of *equal* width columns that should fit in the window)... I used it just to tell the browser how many columns there were (mine were not equal width).
Anyway... this doesnt matter what matters is that adding the attribute did knock 40 or so seconds off my rendering time.... so if you ever find yourself in a netscape bind this obscure attribute could help. It is very good advise to minimize the levels of tables when dealing with netscape I have learned.
This site has been a lesson in what to NOT do with netscape and tables.... we are hitting a db and bringing back a large table of results. this table is embedded within several tables that were layout related. Each level of table addes quite a bit to the rendering time I have learned (the hard way).
Unfortunately, I do not have time to change over to style sheets. A few tweeks (and lowering the number of records returned pre page) has got us closer to acceptable rendering times in netscape.
>since unclosed FONTs slow the renderer to a crawl
As in so that explains why webmaster world renders so slow in moz? I use it habitually around here. I've been doing a great deal of work with CSS to see if I can move us to full CSS. I'm almost ready to do it - I have to get over the "css fear" factor first :) We probably have as wide array of browsers used here as anywhere. Every time I make a little change here or there, I hear about it from someone. I also like to give people as much control over their screen as possible. CSS tends to 'shove pages' at them without remorse.
Anyone know of articles on "degrading gracefully"? The main issue on quality degrading for me, is that the page ends up actually LARGER than it did before the CSS was added.
btw: the col attribute is not supported by Opera [opera.com]. (as I've banged my head for 4 hours last night, trying to figure out why a table wouldn't work...lol)
First, if you set a table cell to a relative width <td width="xx%"> realize that this was not part of the original W3C recommendation, and it is deprecated in HTML 4 (see W3C [w3.org]).
Even so, Netscape and Explorer both read the code. However, Explorer always interprets it as a percentage of the table's width, but some versions of Netscape try to interpret it as a percentage of the window's width. This often throws Netscape into an error handling sub-routine and slows down the rendering.
If you set the cell to an absolute width <td width="nn"> (which is deprecated as well) you can also trip off error handling. If the cell widths don't add up exactly to the table width, including any cellpadding and cellspacing, you've got problems. And sometimes the cell contents require a wider cell than you may have planned for, especially if the browser is overriding your font sizes.
Explorer may start rendering the table incrementally, and then redraw the whole thing when it finds an error. Netscape 4.7 will often just show a blank screen until all the calculations are finished -- if your visitor waits around, that is. The back button is always nearby.
All of this piles up to say, it's often better to let the browser figure out table cell widths on its own if you want speedy rendering of your page.