不是所有表格都那么坏。大多数设计者需要使用网格进行设计，所以使用表格就很自然。我们也很喜欢它们的二元性：表格既可以定义布局，又可以应付页面中不可预知的因素。作为一个设计者，既要处理不确定性，又要在你的设计和用户的灵活性（例如，用户要使字体变大）之间取得平衡。不幸的是，表格同时也增加了显示页面的时间，有时这样的时间很长。

　　因为浏览器需要在填充表格的内容之前完全理解表格的结构，在大部分（如果不是全部）表格的内容下载之前，浏览器什么也不能渲染。当表格变大时，需要处理的信息将呈指数性增长。在先前的计算机上，这些处理性工作很不容易，表格渲染需要大量时间幸运的是，可以找到避免这些缺陷的方法。

　　快速表格的技巧处理表格使用表格时间长了，你会发现大量小表格渲染起来比一个有很多行的大表格快。至少看起来是这样-真象那么回事（记住：是感觉到的速度，而不是实际速度）。

　　如果你在用一个九行的表格（每个单元有很多信息），可以把它分成三个各有三行的小表格。如果你的网页很长，这种策略特别有益-在后面的表格下载时用户可以看前面的表格。

　　使用Width属性为使你的HTML尽量对浏览器友好，应该对TABLE和TD标记适当地使用Width属性。这种属性允许你定义整个表格的宽度，也可以定义单元格的宽度。如果事情并没有好起来，你应该怀疑浏览器-是它的原因。所以只要检查你是否算对了就行了- 如果你把一个单元格设为100个像素宽，可是却把一个110个像素宽的图像插入其中，结果是：表格暂时出现，然后当重绘自己以便能容纳图像时又消失了。不用说，浏览器的这种过滤作用同它的慢速一样令人讨厌。

　　把窗体放在表格里不幸的是，不同的浏览器和操作系统对窗体元素的处理方式不同。Mac上的下拉菜单比Windows中的要宽很多。Netscape 4处理可写的文本框和处理文本一样，所以如果增加浏览器的缺省字体大小，所有的文本框都会变大。Netscape 4中的可写文本框比其它浏览器中的宽20%，而且受字体标记的影响。

看看下面的表格：

　　现在假设用户增加了缺省字体的大小。当表格放大以容纳变大了的文字时，布局依然没变。

不要相信所见即所得的编辑器

　　表格真令人痛苦，这就是为什么所见即所得的HTML编辑器流行起来的原因。但是，在这些编辑器使建表格变得容易的同时，它们也产生了一些令人吃惊的低效率的代码。特别是GoLive的CyberStudio使用了一种产生梦魇般臃肿表格的布局系统（尤其当你没有认真按用户手册操作时）。

　　所见即所得编辑器的布局和预览窗口在处理不必要的嵌套表格、没有设置合适大小的表格的列或奇怪的、转弯抹角的HTML代码时感到力不从心。因此，如果你希望你的表格尽可能地苗条和高效，同时又舍不得放弃所见即所得的编辑器，那么只好最后花些时间清理你的代码。一旦所有内容看起来都象那么回事，用文本编辑器打开HTML代码看看，你会发现你的表格漂亮而且干净。

要不要嵌套？

永远不要嵌套表格

　　使网页读起来很慢的首犯是嵌套的表格：即把表格放在另一个表格的单元格里。因为浏览器必须从里到外进行处理-在计算外层表格之前必须先估算内层表格的大小-嵌套表格的表现真令人讨厌。

　　所以尽量避免使用嵌套表格，即使意味着页面布局会有一些小的变化。如果你不得不使用嵌套表格，至少应保持被嵌套表格尽量简单，而且，不要用三层嵌套。我们是在建网站，不是做俄罗斯娃娃。

除非......

　　嵌套表格：最后的禁忌。不过，简单表格之间的嵌套的代码会是简单的几行

This is not that big a deal.

　　下面的西洋跳棋盘不涉及嵌套表格，但是由于它的复杂性，下载起来很慢。

　　通过使用嵌套表格，可以使问题简单。结果相同，但是下载时间会缩短。

　　使用表格的关键是找到安排它们的最有效的方法。有时嵌套表格就是答案，有时却不是。

结构越好，页面越快

　　下面是一个典型网页的例子：商标在顶部，导航在左边，内容在其余部分。对于这样的页，一般用一个大表格定义整个网格。在整个框架表格内嵌套商标、导航和内容表格，使浏览器渲染起来很困难。

　　下面是相同的页面结构，只是商标、导航和内容分别定义在独立的表格内。

　　通过使每个表格独立和简洁，浏览器可以每读完一个元素就渲染之。因此页面的第一个元素最早出现，用户可以马上利用页面最顶端的信息。

　　在上面的第二个例子里，商标表格最早出现，然后是导航表格，然后是内容表格。整个页面下载很快，用户马上就有可以看到的东西。

　　和处理图像一样，使表格达到最佳效果需要试用不同的方案，直到找到令你和你的用户都满意的布局。你可能怀疑为了省几秒钟就要花费这么多的精力是否值得，但是随着对用户的争夺越来越激烈，这些努力还是值得的。