内容再丰富的网站，如果慢到无法访问也是毫无意义的; SEO做的再好的网站，如果搜索蜘蛛抓不到也是白搭; UE设计的再人性化的网站，如果用户连看都看不到也是空谈。
所以网页的效率绝对是最值得关注的方面。如何才能提高一个网页的效率呢?Steve Souders(Steve Souders的资料提出的提高网页效率的14条准则，而这些准则也将是我们下篇中介绍到的YSlow工具的理论基础：
第一条：Make Fewer HTTP Requests 尽可能的减少HTTP的Request请求数。
80%的用户响应时间都是浪费在前端。而这些时间主要又是因为下载图片、样式表、javascript脚本、flash等文件造成的。减少这些资源文件的Request请求数将是提高网页显示效率的重点。
这里好像有个矛盾，就是如果我减少了很多的图片，样式，脚本或者flash，那么网页岂不是光秃秃的，那多难看呢?其实这是一个误解。我们只是说尽量的减少，并没有说完全不能使用。减少这些文件的Request请求数，当然也有一些技巧和建议的：
1：用一个大图片代替多个小图片。
这的确有点颠覆传统的思维了。以前我们一直以为多个小图片的下载速度之和会小于一个大图片的下载速度。但是现在利用httpwatch工具的对多个页面进行分析后的结果表明事实并不是这样。
第一张图是一个大小为40528bytes的337*191px的大图片的分析结果。
第二张图是一个大小为13883bytes的280*90px的小图片的分析结果。
一个大小为40528bytes的337*191px的大图片分析结果
一个大小为13883bytes的280*90px的小图片的分析结果(点击图片可以查看完整大图片)
第一张大图片花费时间为：
Blocked：13.034s
Send：0.001s
Wait：0.163s
Receive：4.596s
TTFB：0.164s
NetWork：4.760s
功耗时：17.795s
真正用于传输大文件花费的时间为Reveive时间，即4.596s，多数的时间是用来检索缓存和确定链接是否有效的Blocked时间，供花费13.034s，占总时间的73.2%。
第二张小图片花费时间为：
Blocked：16.274s
Send：小于0.001s
Wait：0.117s
Receive：0.397s
TTFB：0.118s
NetWork：0.516s
功耗时：16.790s
真正用于传输文件的花费时间是Reveive时间，即0.397s，这的确要比刚才大文件的4.596s小很多。但是他的Blocked时间为16.274s，占总时间的97%。
如果这些数据还不够说服你的话，让我们看看下面这张图。这里列出了某个网页中所有图片中的花费时间示意图。当然，里面的图片有大有小，规格不一。
大约80%以上的时间是用来检索缓存和确定链接是否有效的Blocked时间。其中藏青色的为传输文件花费的Reveive时间，而前面白色的为检索缓存和确认链接是否有效的Blocked时间。铁一样的事实告诉我们：
大文件和小文件下载所需时间的确是不同的，差异的绝对值不大。而且下载所需时间占总耗费时间比例很小。
大约80%以上的时间是用来检索缓存和确定链接是否有效的Blocked时间。无论文件大小，这个时间的花费大致是相同的。而且所占总耗费时间的比例是极大的。
一个100k的大图片总耗费时间绝对大于4个25k的小图片的总耗费时间。而且主要差别就是4个小图片的Blocked时间绝对大于1个大图片的Blocked时间。
所以如果可能还是使用大图片来替代过多的琐碎的小图片吧。这也是为什么翻转门的效率要高于图片替换实现的滑动门的原因。
但是，请注意：也不能用太大的单张图片，因为那样会影响到用户体验。例如个几兆的背景图片的使用绝对不是一个好主意。
2：合并你的css文件。
图:合并与融合我以前犯了一个错误，你在看我《样式表的组织与规划》的系列文章中会知道。当时，我为了方便组织和规划样式表，将用于不同用途的样式表文件分离开来，形成不同的css文件。然后在页面中根据需要引用多个css文件。
根据“尽可能的减少HTTP的Request请求数”准则我们知道，那样的确是不合理的，因为那样会产生更多的HTTP的Request请求数。从而降低网页的效率。所以，从提高网页效率的角度上而言，我们还是应该将所有的css写在同一个css文件中。但是问题又来了。那么怎么来很好的组织和规划样式表呢?这的确是个矛盾。我现在的做法是采用两套版本。编辑版和发布版。编辑版仍然使用多个css文件以便于规划和组织。而等到发布的时候，再将多个css文件合并到一个文件中去，从而达到减少HTTPRequest请求数的目的。
3：合并你的javascript文件。
原因和处理方法同上，不再赘言。
