Impossible tri-bar

Digital Phenomena - Your first stop for internet consultancy 
Site Building

Overview

Lesson 1

Lesson 2
1  Site Optimization Tutorial — Lesson 2
2  Tables: Past Performance, Future Returns
3 Bring it to the Table
4 Better Structure, Faster Page
5 CSS: An Overview for Optimizers
6 Code Size

Lesson 3

Lesson 4




Site Optimization Tutorial
Lesson 2

by Jason Cook

Page 2 — Tables: Past Performance, Future Returns

Historically, browsers needed to understand a table's structure before drawing the table's contents, so that nothing was put on-screen until all of the table's content was downloaded. How dumb! Even with 99% of a page downloaded, some stubborn browsers wouldn't even think about laying out a table, until receiving a concluding </table> tag. This foot-dragging was the anathema of dial-up modem users everythwere. Well, back in '96, it might've briefly been celebrated as "cyber" foot-dragging.

Since the advent of IE 5.x, Mozilla 1, and Netscape 6.x, this performance pitfall is automatically avoided. Today's newer browsers use progressive or "incremental" rendering by default, and will attempt to render tables on a row-by-row basis, rather than pausing and waiting for the </table> tag to begin the process. If a page's source code relies heavily on tables, and the page downloads in fits and starts, modem users at least have a decent chance of seeing some content on the screen quickly.

Tables perform lamely for another reason, though. As tables get bigger, and nested into one another, the amount of info that needs processing increases exponentially. On slower computers, all this processing-intensive work doesn't come easy, and serious time can pass before a table renders to the screen. Back when we wrote the first edition of this tutorial, this issue was far more pressing -- a 300 Mhz Pentium II wasn't a half-bad computer, and a 300 Mhz P2 didn't munch table-layout algorithms as voraciously as a 3 Ghz P4 does.

But don't fool yourself -- circa-2003 operating systems require more CPU overhead, and the codebase of today's Web browsers sure ain't getting smaller. Even Mozilla, once a browser, is suddenly a "platform". And don't forget the flyweight "thin clients", such as Web-enabled cell phones and PDAs, valiantly attempting to take on the wild Web. They lack CPU muscle, and don't show much spirit for parsing table-heavy layouts. Basically, you still need to do whatever you can to optimize table code. Or, better yet, avoid it altogether.

Accelerating fixed-width tables

If you've got a fixed-width table where you've explicitly set the TABLE WIDTH attribute to so-and-so many pixels, check this out:

Appling a CSS-1 style of {table layout: fixed} to a fixed-width table speeds up the display process in Netscape 6+ and IE5+. With {layout:fixed} present, browsers use a simpler, faster rendering method to draw a table's contents, trusting your assertion that everything's been properly sized-up, already. If you'd like to see a side-by-side performance comparison, check out this page from Microsoft's Developer Network.

Here's a code example of {layout:fixed} applied to a table:



<TABLE STYLE="table-layout: fixed" WIDTH="600">
<TR HEIGHT="30">
<TD WIDTH="150">happy</TD>
<TD WIDTH="200">happy</TD>
<TD WIDTH="250">happy</TD>
</TR>


Now, don't go abusing the browser's trust! If you apply the {table layout:fixed} style incorrectly, with WIDTHS that don't quite add up, the browser will catch the error during the rendering process and start things over from scratch. Do that, and your tables will appear slower, not faster.

next page»


|Home|About Us|Services|Search|
|Software|Products|Support|Links|Latest|
W3C validatedW3C validated CSSCompatible with all browsers