网页大小与响应速度的关系

网页大小/网络带宽/传输耗时对照表：

此处的数据基于如下的一系列假设：

• 该应用对于本机而言并不是第一次访问，即相关的客户端缓存已建立。
• GZIP压缩算法已被启用。
• 网络比较稳定，其他客户机对网络资源的抢占并不严重。
• 本表中给出的数据是相对保守的，考虑了系统底层的带宽消耗和带宽共享等因素。

我们一般所讲的带宽都是以Bit为单位，而我们评估网页大小时使用的是Byte为单位的。所以在进行计算之前需要利用带宽换算出真正的"数据带宽"。
例如：512Kbit / 8 = 64Kbyte。
在通常情况下，基于Dorado的网页的原始大小一般在100K以内，并且经过GZIP算法压缩后，其产生的通信量约为20K左右。
有了上述数据之后，我们就可以在设计阶段根据前面提到的各种调研结果，对最终开出来的页面大小做出一个大致的限定。

初始化耗时与CPU的关系

为了方法不同CPU之前的差异，我们特别使用了一个特别耗时的测试页面作为基准。http://61.151.239.187/dorado5/performance/test-performance1.jsp。

网页复杂度与网页大小的关系

网页复杂度与网页大小之间的关系是很难量化的。因此这里只能举几个例子。

• 简单查询页面。其中带有10条记录。页面原始大小为12.8K，GZIP压缩后为2.8K。

• 较简单的合同维护页面。其中带有10条记录。页面原始大小为17.1K，GZIP压缩后为3.9K。

• 复杂的测试页面（不含数据）。总共包含：6个多页标签、300个编辑框、3个各有20列的表格、以及60条记录，每条记录包含100个含值的字段。页面原始大小为184K，GZIP压缩后为9.2K。压缩比例高达95%！

• 复杂的测试页面（含数据）。该页面其他配备同上，但其中又额外包含了60条记录，每条记录中包含100个含值的字段。页面原始大小为240K，GZIP压缩后为49.5K。

由于该页面中使用的随机字符，这类信息的是很难被压缩的，因此与上一个页面的测试结果比较后可以得知，对于页面中数据部分的压缩率只有约30%。不过，在实际应用中，对于真实的数据而言，其压缩比例应该高于这个数字。经过我们的对大量真实数据的分析，通常的压缩率应在66%左右。

实例分析

假设目前系统的最终将有一部分用户通过256K宽带网络来使用系统。他们需要频繁的操作一组订单录入的功能，每天最多可能会录入50笔订单。考虑到网络状况不是很好，因此他们希望经常单个订单页面的打开时间不要超过3秒。而客户机的CPU配置以P4 2.4为主。
先来分析一下我们如何分配这3秒钟。对于页面打开的环节，服务器上不会有特别复杂的处理逻辑，因此我们可以假设服务端的处理时间可以控制在0.5秒以内。P4 2.4的CPU目前属中档的配置，只要页面将来不是太过复杂，那么客户端的初始话时间应该不会超过1秒。这样，页面在网络传输环节上的还有大约1.5秒的余地。从上表中可以看出256Kbit带宽下1.5秒可以传输40Kbyte的数据量。这里的40Kbyte是指经GZIP压缩后的数据量，对于大多数页面我们基本可以将其X4换算出页面的原始大小（对于数据较少的页面，乘4倍是很保守的估算策略），40Kbyte * 4 = 160Kbyte。因此，我们最终应该将页面的大小严格控制在160Kbyte以内。
事实上160K对于一个Dorado的网页而言，其实已经是相当复杂的了。对于订单录入的界面而言，在打开时应不会包含多少数据，因此我们完全可以保证此页面最终的尺寸不超过150K。