本来这是个老生常谈的问题，上周自成又分享了一些性能优化的建议，我这里再做一个全面的Tips整理，谨作为查阅型的文档，不妥之处，还请指正。
一、 Yahoo的军规条例：
谨记：80%-90%的终端响应时间是花费在下载页面中的图片，样式表，脚本，flash等；
详细的解释来这里查：http://developer.yahoo.com/performance/rules.html
也可以直接firebug上一项项比对，如下图：
简单翻译解释下：
1、尽量减少HTTP请求个数——须权衡
合并图片（如css sprites，内置图片使用数据）、合并CSS、JS，这一点很重要，但是要考虑合并后的文件体积。
2、使用CDN（内容分发网络）
这里可以关注CDN的三类实现：镜像、高速缓存、专线，以及智能路由器和负载均衡；
3、为文件头指定Expires或Cache-Control，使内容具有缓存性。
区分静态内容和动态内容，避免以后页面访问中不必要的HTTP请求。
4、避免空的src和href
留意具有这两个属性的标签如link，script，img，iframe等；
5、使用gzip压缩内容
Gzip压缩所有可能的文件类型以来减少文件体积
6、把CSS放到顶部
实现页面有秩序地加载，这对于拥有较多内容的页面和网速较慢的用户来说更为重要，同时，HTML规范清楚指出样式表要放包含在页面的<head />区域内；
7、把JS放到底部
HTTP/1.1 规范建议，浏览器每个主机名的并行下载内容不超过两个，而问题在于脚本阻止了页面的平行下载，即便是主机名不相同
脚本带来的问题就是它阻止了页面的平行下载。HTTP/1.1 规范建议，浏览器每个主机名的并行下载内容不超过两个。如果你的图片放在多个主机名上，你可以在每个并行下载中同时下载2个以上的文件。但是当下载脚本时，浏览器就不会同时下载其它文件了，即便是主机名不相同。
8、避免使用CSS表达式
页面显示和缩放，滚动、乃至移动鼠标时，CSS表达式的计算频率是我们要关注的。可以考虑一次性的表达式或者使用事件句柄来代替CSS表达式。
9、将CSS和JS放到外部文件中
我们需要权衡内置代码带来的HTTP请求减少与通过使用外部文件进行缓存带来的好处的折中点。
10、减少DNS查找次数
我们需要权衡减少 DNS查找次数和保持较高程度并行下载两者之间的关系。
DNS解析的过程也是需要时间的。一般情况下返回给定域名对应的IP地址会花费20到120毫秒的时间。而且在这个过程中浏览器什么都不会做直到DNS查找完毕。缓存DNS查找可以改善页面性能。减少主机名的数量可以减少DNS查找次数。减少主机名的数量还可以减少页面中并行下载的数量。减少DNS查找次数可以节省响应时间，
但是减少并行下载却会增加响应时间。
11、精简CSS和JS
目的就是减少下载的文件体积，可考虑压缩工具JSMin和YUI Compressor。
12、避免跳转
为了确保“后退”按钮可以正确地使用，使用标准的 3XXHTTP状态代码；同域中注意避免反斜杠 “/” 的跳转；跨域使用 Alias或者 mod_rewirte建立 CNAME（保存一个域名和另外一个域名之间关系的DNS记录）
例如，当我们要访问http: //astrology.yahoo.com/astrology 时，实际上返回的是一个包含301代码的跳转，它指向的是http://astrology.yahoo.com/astrology/（注意末尾的斜杠）。
13、剔除重复的JS和CSS
重复调用脚本，除了增加额外的HTTP请求外，多次运算也会浪费时间。在IE和Firefox中不管脚本是否可缓存，它们都存在重复运算JavaScript的问题。
14、配置ETags
Entity tags（ETags）（实体标签）是web服务器和浏览器用于判断浏览器缓存中的内容和服务器中的原始内容是否匹配的一种机制（“实体”就是所说的“内 容”，包括图片、脚本、样式表等），是比last-modified date更更加灵活的机制，单位时间内文件被修过多次，Etag可以综合Inode(文件的索引节点(inode)数)，MTime(修改时间)和 Size来精准的进行判断，避开UNIX记录MTime只能精确到秒的问题。 服务器集群使用，可取后两个参数。使用ETags减少Web应用带宽和负载。
15、使AJAX可缓存
利用时间戳，更精巧的实现响应可缓存与服务器数据同步更新。
16、尽早刷新输出缓冲
尤其对于css，js文件的并行下载更有意义
17、使用GET来完成AJAX请求
当使用XMLHttpRequest时，浏览器中的POST方法是一个“两步走”的过程：首先发送文件头，然后才发送数据。在url小于2K时使用GET获取数据时更加有意义。
18、延迟加载
确定页面运行正常后，再加载脚本来实现如拖放和动画，或者是隐藏部分的内容以及折叠内容等。
19、预加载
关注下无条件加载，有条件加载和有预期的加载。
20、减少DOM元素个数
使用更适合或者在语意是更贴切的标签，要考虑大量DOM元素中循环的性能开销。
21、根据域名划分页面内容
很显然， 是最大限度地实现平行下载
22、尽量减少iframe的个数
考虑即使内容为空，加载也需要时间，会阻止页面加载，没有语意，注意iframe相对于其他DOM元素高出1-2个数量级的开销，它会在典型方式下阻塞onload事件，IE和Firefox中主页面样式表会阻塞它的下载。
23、避免404
HTTP请求时间消耗是很大的，有些站点把404错误响应页面改为“你是不是要找***”，这虽然改进了用户体验但是同样也会浪费服务器资源（如数据库等）。最糟糕的情况是指向外部 JavaScript的链接出现问题并返回404代码。首先，这种加载会破坏并行加载；其次浏览器会把试图在返回的404响应内容中找到可能有用的部分当作JavaScript代码来执行。
404错误：服务器找不到指定的资源，请求的网页不存在
410错误：请求的网页不存在(注意：410表示永久性，而404表示临时性)；
24、减少Cookie的大小
去除不必要的coockie
使coockie体积尽量小以减少对用户响应的影响
注意在适应级别的域名上设置coockie以便使子域名不受影响
设置合理的过期时间。较早地Expire时间和不要过早去清除coockie，都会改善用户的响应时间。
25、使用无cookie的域
确定对于静态内容的请求是无coockie的请求。创建一个子域名并用他来存放所有静态内容。
26、减少DOM访问
缓存已经访问过的有关元素
线下更新完节点之后再将它们添加到文档树中
避免使用JavaScript来修改页面布局
27、开发智能事件处理程序
有时候我们会感觉到页面反应迟钝，这是因为DOM树元素中附加了过多的事件句柄并且些事件句柄被频繁地触发。这就是为什么说使用event delegation（事件代理）是一种好方法了。如果你在一个div中有10个按钮，你只需要在div上附加一次事件句柄就可以了，而不用去为每一个按 钮增加一个句柄。事件冒泡时你可以捕捉到事件并判断出是哪个事件发出的。你同样也不用为了操作DOM树而等待onload事件的发生。你需要做的就是等待树结构中你要访问的元素出现。你也不用等待所有图像都加载完毕。你可能会希望用DOMContentLoaded事件来代替 事件应用程序中的onAvailable方法。
28、用<link>代替@import
在IE中，页面底部@import和使用<link>作用是一样的，因此最好不要使用它。
29、避免使用滤镜
完全避免使用AlphaImageLoader的最好方法就是使用PNG8格式来代替，这种格式能在IE中很好地工作。如果你确实需要使用 AlphaImageLoader，请使用下划线_filter又使之对IE7以上版本的用户无效。
30、优化图像
尝试把GIF格式转换成PNG格式，看看是否节省空间。在所有的PNG图片上运行pngcrush（或者其它PNG优化工具）
31、优化CSS Spirite
在Spirite中水平排列你的图片，垂直排列会稍稍增加文件大小；Spirite中把颜色较近的组合在一起可以降低颜色数，理想状况是低于256 色以便适用PNG8格式；便于移动，不要在Spirite的图像中间留有较大空隙。这虽然不大会增加文件大小但对于用户代理来说它需要更少的内存来把图片解压为像素地图。 100×100的图片为1万像素，而1000×1000就是100万像素。
32、不要在HTML中缩放图像——须权衡
不要为了在HTML中设置长宽而使用比实际需要大的图片。如果你需要：<img width=”100″ height=”100″ src=”mycat.jpg” alt=”My Cat” />
那么你的图片（mycat.jpg）就应该是100×100像素而不是把一个500×500像素的图片缩小使用。这里在下文有更有趣的分析。
33、favicon.ico要小而且可缓存
favicon.ico是位于服务器根目录下的一个图片文件。它是必定存在的，因为即使你不关心它是否有用，浏览器也会对它发出请求，因此最好不要返回一 个404 Not Found的响应。由于是在同一台服务器上，它每被请求一次coockie就会被发送一次。这个图片文件还会影响下载顺序，例如在IE中当你在 onload中请求额外的文件时，favicon会在这些额外内容被加载前下载。
因此，为了减少favicon.ico带来的弊端，要做到：文件尽量地小，最好小于1K。在适当的时候（也就是你不要打算再换 favicon.ico的时候，因为更换新文件时不能对它进行重命名）为它设置Expires文件头。你可以很安全地 把Expires文件头设置为未来的几个月。你可以通过核对当前favicon.ico的上次编辑时间来作出判断。Imagemagick可以帮你创建小巧的favicon。
34、保持单个内容小于25K
因为iPhone不能缓存大于25K的文件。注意这里指的是解压缩后的大小。由于单纯gizp压缩可能达不要求，因此精简文件就显得十分重 要。
35、打包组件成复合文本
页面内容打包成复合文本就如同带有多附件的Email，它能够使你在一个HTTP请求中取得多个组件（切记：HTTP请求是很奢侈的）。当你使用这条规 则时，首先要确定用户代理是否支持（iPhone就不支持）。
二、Yahoo军规之外的场景？
1、 使用json作为数据的交换格式
Json在浏览器解析的效率至少高于XML一个数量级，高级浏览器中内置的有生成和解析json的方法，IE6中要用额外的方法（http://json.org）,不要用eval，容易引发性能和安全问题。
2、 尽可能对images和table设定宽高值
针对Yslow的不要在HTML中缩放图像——第33条，有人会误解为不要对图片加宽高值，其实这条建议本身的意思是不要为了获取一个特定大小的图片，而去强行通过设置宽高值拉伸或者压缩一个既有的图片。建议是另存一张符合尺寸的图片替代。
对图片和table是设定宽高，是考虑到如果浏览器能立刻知道图片或者tables的宽高，它就能够直接呈现页面而不需要通过计算元素大小后重绘，而且即便是图片损毁而没有展现，也不会进而破坏了页面本来的布局。
有一些应用场景需要注意：
a、批量图片，图片源可控同时页面图片宽高值不可变，比如数据库有100张100*100的图片要在页面中全部展示，那么建议是都写上
<img width=”100″ height=”120″ src=”" alt=”" />
b、批量图片，图片源不可控同时页面图片宽高值不可变，比如数据库有100张图片，而已知图片有的尺寸是97*100，有的100*105，而又不可能去一张张修改另存。这里视情况而定，根据图片尺寸与要求尺寸的偏离度，在保证图片不拉伸变形同时不影响页面布局的情况下，可以对图片单独设定宽度 100，同时对其包裹的容器设定100*100的宽高来隐藏多出来的部分，注意不能同时设置宽高以防止变形。c、批量图片，图片源不可控，页面图片宽高值不定，比如数据库有100张各种尺寸偏差较大的，此时可不对图片设置宽高；
其他情况不一一罗列，原则是在最大程度保证图片不变形与图片最大面积展现的前提下，尽可能为图片设置宽高值，总之就是权衡。
Tables的宽高值同图片，尽可能设置。
3、 拆离内容块
尽量用div取代tables，或者将tables打破成嵌套层次深的结构；
避免用这样的嵌套
<table>
<table>
<table>
...
</table>
</table>
</table>
采用下面的或者div重构：
<table></table>
<table></table>
<table></table>
4、 高效的CSS书写规则
众所周知，CSS选择符是从右向左进行匹配的。
通常一个图片列表的的小模块
<div id="box">
<div class="hd">
<h3>我的旅途</h3>
</div>
<div class="bd">
<h4>旅途1</h4>
<ul id="pics">
<li>
<a href="#pic" title=""><img src="" alt="" /> </a>
<p>这是在<strong>图片1</strong></p>
</li>
</ul>
</div>
</div>
为了代码上缩进后内层的整洁性，我们html有可能这样写之外，更喜欢看这样的css写法：
.box{border:1px solid #ccc }
.box .hd{border-bottom:1px solid #ccc }
.box .hd h3{color:#515151}
.box .bd{color:#404040 }
.box .bd ul{margin-left:10px}
.box .bd ul li{border-bottom:1px dashed #f1f1f1}
.box .bd ul li a{text-decoration:none}
.box .bd ul li a:hover{text-decoration:underline}
.box .bd ul li a img{border:1px solid #ccc}
.box .bd ul li p{text-align:left;}
.box .bd ul li p strong{color:#ff6600}
其实写到这里，问题已经显而易见了。深达五层抑或六层的嵌套，同时右边的选择符都是采用标签，在满足我们视觉平整与代码结构系统化的时候，付出的是性能的代价。
不做进一步的代码书写方式的探讨，受个人习惯与应用场景影响。这里对css选择符按照开销从小到大的顺序梳理一下：
ID选择符 #box类选择符 .box类型选择符 div相邻兄弟选择符 h4 + #pics子选择符 #pics li后代选择符 .box a{}通配选择符 *属性选择符 [href=”#pic”]伪类和伪元素 a:hover
参考《高性能网站建设-进阶指南》，有如下建议：
避免使用统配规则；不要限定ID选择符；不要限定类选择符；让规则越具体越好；避免使用后代选择符；避免使用标签-子选择符；质疑子选择符的所有用途；依靠继承；
还要注意到，即便是页面加载后，当页面被触发引起回流（reflow）的时候，低效的选择符依然会引发更高的开销，显然这对于用户是不佳的体验。
三、Yahoo军规再度挖掘会怎样？
在网站性能优化的路上，是不会有终点的，这也是前端工程师永不会妥协的地方。
想看到更牛P的优化建议么，请移步这里来关注李牧童鞋的分享：
- 使用combo合并静态资源
- Bigpipe技术合并动态数据
- Comet:基于http的服务端推技术
- 使用DataURI减少图片请求
- 使用良好的JS,CSS版本管理方案
- 尝试仅作必要的JS更新
- 利用本地存储做缓存
- 关于最小化HTML
- 进一步讨论Gzip
- 进一步讨论域名划分
- 打开keep-alive,重用HTTP连接
- 使用JSON进行数据交换
- 保障页面可交互性
- 缩短最快可交互时间
- 异步无阻脚本下载
- 优化内存使用,防止内存泄露
- 高效的JavaScript
- 第三方代码性能问题
- Inline脚本不要与CSS穿插使用
- 使用高效的CSS选择器
- 进一步讨论及早Flush
- 关于视觉和心理学