提高网页的效率

Steve Souders提出了提高网页效率的14条准则，而这些准则也将是我们下篇中介绍到的YSlow工具的理论基础：

•Make Fewer HTTP Requests
•Use a Content Delivery Network(CDN)
•Add Expires header
•Compress components with gzip
•Put CSS at the top
•Move JavaScript at bottom
•Avoid CSS expressions
•Make JavaScript and CSS external
•Reduce DNS lookups
•Minify JavaScript and CSS
•Avoid URL redirects
•Remove duplicate JavaScript and CSS
•Configure entity tags(ETags)
•Make AJAX cacheable
•Use GET for AJAX requests
•Reduce the number of DOM elements
•Avoid HTTP 404(Not Found) error
•Reduce cookie size
•Use cookie-free domains
•Avoid AlphaImageLoader filter
•Do not scale images in HTML
•Make favicon small and cacheable
最后8条为YSlow新版本中增加的准则，这里我们将逐一的讲解这些准则,对其中开发者密切相关的准则我将详细讲解。由于个人技术实在有限，错误和无知在所难免，还请高人指点。

第一条：Make Fewer HTTP Requests 尽可能减少HTTP的Request请求数
  80%的用户响应时间都是浪费在前端。而这些时间主要又是因为下载图片、样式表、JavaScript脚本、flash等文件造成的。减少这些资源文件的 Request请求数将是提高网页显示效率的重点。要做到这一点有很多方法，比如使用CSS Sprites整合图片、合并CSS文件（不需要划分为什么色彩样式、布局样式、文字样式之类的）、合并JS文件。

1：用一个大图片代替多个小图片。
以前我一直以为多个小图片的下载速度之和会小于一个大图片的下载速度。但是现在利用httpwatch工具的对多个页面进行分析后的结果表明事实并不是这样。

 
一个大小为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，这的确要比刚才大文件Reveive时间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文件。
原因和处理方法同上，不再赘言。

第二条：Use a Content Delivery Network 使用CDN
CDN的全称是Content Delivery Network，即内容分发网络。其目的是通过在现有的Internet中增加一层新的网络架构，将网站的内容发布到最接近用户的网络”边缘”，使用户可以就近取得所需的内容，解决Internet网络拥挤的状况，提高用户访问网站的响应速度。从技术上全面解决由于网络带宽小、用户访问量大、网点分布不均等原因所造成的用户访问网站响应速度慢的问题。 如果一个北京的电信用户试图从广东的网通服务器上打开一个类似《壁纸合集》帖子的网页时，你就能很深刻的理解。鉴于这个不是我们开发人员力所能及的准则，这里也就不多言了。

第三条：Add Expires header 添加周期头
为静态资源文件增加过期时间，让用户通过本地缓存来更快的访问网站。这个也不是开发人员来控制，而是网站服务器管理员的职责，所以作为开发人员的你不了解和明白也没有关系。

第四条：Compress components with gzip 启用Gzip压缩
Gzip的思想就是把文件先在服务器端进行压缩，然后再传输。这对于体积较大的纯文字型的文件有特效。Gzip格式是一种很普遍的压缩技术，几乎所有的浏览器都有解压Gzip格式的能力，而且它可以压缩的比例非常大，一般压缩率为85%，就是说服务器端100K的页面可以压缩到25K左右的Gzip格式的数据发给客户端，客户端收到Gzip格式的数据后自动解压缩后显示页面。

第五条：Put CSS at the top 把CSS样式放在页面的上方
无论是HTML还是XHTML还是CSS都是解释型的语言，而非编译型的。所以CSS到上方的话，那么浏览器解析结构的时候，就已经可以对页面进行渲染。这样就不会出现，页面结构光秃秃的先出来，然后CSS渲染，页面又突然华丽起来，这样太具有“戏剧性”的页面浏览体验了。

第六条：Move JavaScript to the bottom 将脚本放在底部
一般情况下JS的下载是阻塞模式的，放在页面顶部会阻塞其他资源的下载。跟上一条一样，很多人都习惯了把JS也放在头部，这样不仅会阻塞其它资源的下载，而且JS一般都是用来交互的，如果页面都还没有出来，何来的交互呢？所以JS还是要放到底部加载。

第七条：Avoid CSS expressions 避免使用CSS中的expressions
expressions其实就像是其它语言中的if……else……可以在CSS中进行逻辑判断。举个简单的例子——

< style >
input { background-color : expression((this.readOnly && this.readOnly==true)?"#0000ff":"#ff0000") }
</ style >
< INPUT  TYPE ="text"  NAME ="" >
< INPUT  TYPE ="text"  NAME =""  readonly ="true" > 这样css就可以根据一些情况分别使用不同的样式了。但是CSS中Expressions 的代价却是极高的，当你的页面需要根据判断来渲染效果的元素很多的时候，那么你的浏览器将长期处于假死状态，从而给用户带来极差的用户体验。

第八条：Make JavaScript and CSS external 将JS和CSS独立成外部文件
这一条好像和第一条有点矛盾。如果从HTTP的request请求数来讲的话，这样做的确是降低了效率。但之所以这么做，是因为另外一个重要的考虑因素——缓存。因为外部的引用文件会被浏览器缓存，所以如果javascript和css体积较大的时候，我们将它们独立成外部文件。这样当用户只要浏览一次以后，这些体积较大的js和css文件就能被缓存起来，从而极高地提高用户再次访问时的效率。而某些大站比如yahoo，会把CSS及JS都写在页面里，那是因为访问量太大，尽可能的减少请求数。如果你的网站访问量还不是那么地惊人的话，还是独立出来比较好。

第九条：Reduce DNS lookups  减少DNS查询
那这一条对我们到底有什么真正意义上的指导意义呢？其实有两条：
1：如果不是必须，请不要把网站放到两台服务器上。
2：网页中的图片、css文件、js文件、flash文件等等，不要太多的分散在不同的网络空间中。这就是为什么那种只发一个网站中的壁纸图片的帖子，要比壁纸图片来源于不同网站的帖子显示要快得多的原因。

第十条：Minify JavaScript and CSS  减少JS和CSS文件的体积
这点很好理解。在你的最终发布版本中把没有必要的空行、空格和注释全部去掉。显然手工去处理效率太低，好在网上到处都是用于压缩这些东西的工具。压缩JavaScript代码体积的工具随处可见，我便不再列举了，这里我只提供一个用于压缩css代码体积的在线工具网站——http://www.cssdrive.com/index.php/main/csscompressor ，它提供了多种压缩方式，可以适应多种要求。

第十一条：Avoid redirects 避免跳转
这里有一种现象常常会被开发者所忽略，这种现象发生在当URL本该有斜杠（/）却被忽略掉时，这时候会返回一个301的状态码，然后浏览器重新发起一次请求，这其中就浪费掉了时间。

第十二条 Remove duplicate JavaScript and CSS 移除重复的JS和CSS
这个准则的道理很浅显，但是真正在工作中，很多人却因为“项目时间紧”、“太累了”、“初期没有规划好”……这样的理由搪塞过去了。你的确可以找很多的理由不去处理这些多余重复的脚本代码，如果你的网站不需要更高的效率和后期维护的话。

第十三条：Configure ETags 配置你的实体标签
Etag（Entity tags ）实体标签。这个tag和你在网上经常看到的标签云那种tag有点区别。这个Etag不是给用户用的，而是给浏览器缓存用的。Etag是服务器告诉浏览器缓存，缓存中的内容是否已经发生变化的一种机制。通过Etag，浏览器就可以知道现在的缓存中的内容是不是最新的，需不需要重新从服务器上重新下载。这和 “Last-Modified”的概念有点类似。很遗憾作为网页开发人员对此无能为力。他依然是网站服务器人员的工作范畴。

第十四条：Make Ajax Cacheable 设置AJAX的缓存
当前AJAX的应用越来越广泛，AJAX的信息读取是异步的，这也表示用户不一定会等待这异步的响应，为避免重复的AJAX请求，设置缓存是优化性能的一个好方法。

第十五条：Use GET for AJAX requests 用GET获取AJAX请求

AJAX的传值可用GET跟POST，在这里建议使用的是GET。

第十六条：Reduce the number of DOM elements 减少页面DOM节点

讲究页面代码的简洁，一个复杂的页面不仅增大页面的体积，也会对JS访问DOM元素产生影响。

第十七条：Avoid HTTP 404 (Not Found) error 避免404错误页面的出现

这个应该不用怎么解释了，不管从服务器资源还是用户体验上来说，都是不好的。

第十八条：Reduce cookie size 减少cookie的大小

cookie一般用于身份验证等用途，一般说来cookie被限制在4K以内，尽量控制 Cookie 的大小，不要塞入一些无用的信息。

第十九条：Use cookie-free domains 使用域名无关性的cookie

这里是有关静态服务器的问题，主要是指一些静态文件比如说图片、CSS等等，比如说YAHOO，他的静态文件都在 yimg.com 上，客户端请求静态文件的时候，减少了 Cookie 的反复传输对主域名的影响。

第二十条：Avoid AlphaImageLoader filter 避免AlphaImageLoader滤镜的使用
这个几乎都是用在IE6下解决PNG透明的问题上的。而为了实现此效果而牺牲的性能来说，是很不合算的。

第二十一条：Do not scale images in HTML 不要对图片进行缩放
也就是图片的实际大小大于他的显示必要，比如一个800*600的图片，而我们在页面上只显示的是400*300的大小，那么这便是一种服务器资源的浪费。

第二十二条：Make favicon small and cacheable 使图标尽可能小并使用缓存
这里指的是favicon.ico了，设置favicon.ico缓存可以避免频繁的页面请求

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/chenhongxin/archive/2010/10/13/5938541.aspx