我们都说互联网内容制胜，但如果网站的响应速度太慢，即使内容再好，也更会造成用户体验从“抓狂 - 愤怒 - 永远离开 - 坏口碑传播”这样的毁灭性路线。
Make fewer HTTP requests - 减少http请求次数 。例如首页嵌套了4个iframe，那么就是4+1=5个http请求，如果去掉iframe或改成服务器端包含的话……那么就只剩一个http请求啦。所以，对于访问量巨大的网站首页来说，把CSS和JS直接写在页面里，也许是个不错的选择，尽管这违反了第8条军规，但规矩是死的，实际情况是活的。
Use a CDN - 使用内容分发网络 。特殊资源走特殊的网络连接从而获得特殊的加速，例如：网通/电信/教育网分别加速、为北京或上海的用户建立本地的CDN以加速这种特定地域的访问、为软件下载专门加速、为流媒体直播专门加速、为静态资源下载提速（css/js/html）……
Add an Expires header - 尽量让客户端浏览器缓存网站的资源 ，那么就不用每次都从服务器下载了，这能极大减轻网站服务器的负担，但是如果资源更新了而客户端得不到及时通知的话……所以请谨慎设计、变更你的Web资源头部过期标记，最大化重用客户端浏览器缓存的同时又不至于使用户看不到最新的更改。
Gzip components - 启用Gzip压缩已经是网站服务公认的标准了 ，Gzip能极大的压缩网站数据包的体积（一般压缩率可达到85%！也就是说服务器端100K 的页面可以压缩到15K 左右再发送到客户端），传到客户端再解包，一般的浏览器、搜索引擎爬虫都支持。强烈建议网站上所有的文本内容都走Gzip压缩，例如：js css html txt 等等。支持Gzip的代理服务器软件也很出色，如 Nginx——简单好用，性能一流，吐血推荐。
Put stylesheets at the top - 把样式表放在页面顶端 。如果把样式表放在底部，如果网络稍有延迟的话，页面样式得不到及时渲染，将惨不忍睹啊！
Put scripts at the bottom - 把脚本（如javascript）放在页面底部 。有的脚本很大，如果放在顶部半天下载不下来的话，页面将是一片空白，你肯定不想用户半天都看着白花花的屏幕发呆吧——用户也不想！脚本一般是响应页面载入后的行为，所以放到底下去慢慢下载比较好，让用户尽快的看到页面——这个体验对用户来说比较好。脚本引起的另一个问题是它阻塞并行下载数量。HTTP 1.1规范建议Web浏览器的并行下载数不超过2个（IE只能为2个，其他浏览器如Firefox等都是默认设置为2个，不过IE8可以达到6个），因此如果您把图像文件分布到多台机器的话，您可以达到超过2个的并行下载，但是当脚本文件下载时，浏览器会阻塞图片并行下载。当然，有些情况下还是不得不把脚本放到顶端的，例如在页面渲染时就需要的计算。
Avoid CSS expressions - 不要使用CSS（样式表）表达式 。首先CSS表达式不是一个跨浏览器的玩意，IE5以后对其支持，其他的浏览器不保证。CSS表达式的问题还在于它的计算频率要比想象的多出很多，不仅仅是在页面显示和缩放时，就是在页面滚动、乃至移动鼠标时都可能要重新计算一次。如果样式属性必须在页面周期内动态地改变，使用事件句柄来代替CSS表达式是一个可行办法。CSS表达式成千上万次的计算可能会对你页面的性能产生很大影响，会造成用户感觉打开你的页面后机器变的很慢……很慢。这是一个CSS表达式的例子：background-color: expression( (new Date()).getHours()%2 ? "#F00" : "#00F" );
Make JS and CSS external - 把JS脚本、CSS样式表归放在单独的文件里 。首先可以加速整体页面的展现，我们知道网络的突发传输速率大于持续传输速率；其次对SEO有好处，搜索引擎每天分配给你站点的“爬取时间”是有限的，如果把这些与内容无关的、必然会被搜索忽略的东西放在页面里，浪费了爬虫的时间，也许会减少整个站点的页面收录量；另外，单独的文件也方便享受静态资源“特权CDN”和特殊压缩处理的好处不是？
Reduce DNS lookups - 减少DNS解析次数 。我们知道一个域名需要经过从DNS服务器解析成IP地址这个过程才能把页面呈现到您老的眼前。一般来说一次DNS的解析过程会消耗20-120毫秒的时间，在DNS解析结束之前，浏览器不会下载该域名下的任何东西。如果您万一不幸碰上一个无良的DNS解析服务提供商或者您网页里的资源在很多不同域名底下，那么，光DNS的解析时间就会让你的用户欲仙欲死的。
Minify JS - JS尽量压缩。JS脚本乃是除图片、音频、视频之外，最常见、最消耗网络带宽的资源了，所以我们除了要将它独立成文件、放在加速的CDN上之外，最好还把它压缩一下。这里有个在线处理JS的工具，不仅能压缩、还能加密JS：http://www.huobi3jia.com/htm/fuckjs.htm
Avoid redirects - 尽量避免URL重定向 。这里的意思主要是指后台程序能用Forward转发就尽量用Forward转发，而非Redirect重定向，为啥呢？因为重定向相对于前者来说消耗的资源更大，相当于再发送一个新的http请求（request），原请求被清空，构造出新的请求……另外从SEO的角度来说，重定向表示网址被转移了，表现为浏览器地址栏的URL发生了变化，这时候选择301永久重定向、还是选择302临时重定向（一般默认是302），是个很纠结、很蛋疼的事情，增加了复杂度，SEO效果也不好说。
Remove duplicate scripts - 移除重复的脚本 。脚本这玩意属于客户端的东西，乱写一气最多页面变形，很难把服务器整死，所以有些网站不太重视，有很多功能重复的脚本函数，殊不知这样除了会消耗Web应用宝贵的带宽资源，还会加大客户端的计算量，有时会直接影响用户体验，所以尽量归并和抽象重复的脚本吧。采用面向对象的JS编程也许是个不错的主意。
Configure ETags - 定义ETags 。别被ETags吓到，其实就是充分利用客户端浏览器缓存减少Web应用消耗的带宽和负载，具体的实现可以参考此文：http://www.infoq.com/cn/articles/etags 。开启Web服务器的ETags选项可以有效的控制客户端缓存失效，但不利于服务端缓存，如果使用Squid做代理服务器缓存，可以不使用ETags，Squid做代理服务器有啥好处，可以参考此文：http://kthqhu.blog.51cto.com/1308987/280669
Make AJAX cacheable - 注意AJAX缓存 ！AJAX还要去缓存？是的，根据你的实际需要去防止AJAX缓存。做AJAX请求的时候往往还要增加一个时间戳去避免其缓存。It’s important to remember that “asynchronous” does not imply “instantaneous”.（记住“异步”不是“瞬间”，这一点很重要）。要明白，即使AJAX请求是动态产生的且只对一个用户起作用，其依然可以被缓存。
Use a CDN - 使用内容分发网络 。特殊资源走特殊的网络连接从而获得特殊的加速，例如：网通/电信/教育网分别加速、为北京或上海的用户建立本地的CDN以加速这种特定地域的访问、为软件下载专门加速、为流媒体直播专门加速、为静态资源下载提速（css/js/html）……
Add an Expires header - 尽量让客户端浏览器缓存网站的资源 ，那么就不用每次都从服务器下载了，这能极大减轻网站服务器的负担，但是如果资源更新了而客户端得不到及时通知的话……所以请谨慎设计、变更你的Web资源头部过期标记，最大化重用客户端浏览器缓存的同时又不至于使用户看不到最新的更改。
Gzip components - 启用Gzip压缩已经是网站服务公认的标准了 ，Gzip能极大的压缩网站数据包的体积（一般压缩率可达到85%！也就是说服务器端100K 的页面可以压缩到15K 左右再发送到客户端），传到客户端再解包，一般的浏览器、搜索引擎爬虫都支持。强烈建议网站上所有的文本内容都走Gzip压缩，例如：js css html txt 等等。支持Gzip的代理服务器软件也很出色，如 Nginx——简单好用，性能一流，吐血推荐。
Put stylesheets at the top - 把样式表放在页面顶端 。如果把样式表放在底部，如果网络稍有延迟的话，页面样式得不到及时渲染，将惨不忍睹啊！
Put scripts at the bottom - 把脚本（如javascript）放在页面底部 。有的脚本很大，如果放在顶部半天下载不下来的话，页面将是一片空白，你肯定不想用户半天都看着白花花的屏幕发呆吧——用户也不想！脚本一般是响应页面载入后的行为，所以放到底下去慢慢下载比较好，让用户尽快的看到页面——这个体验对用户来说比较好。脚本引起的另一个问题是它阻塞并行下载数量。HTTP 1.1规范建议Web浏览器的并行下载数不超过2个（IE只能为2个，其他浏览器如Firefox等都是默认设置为2个，不过IE8可以达到6个），因此如果您把图像文件分布到多台机器的话，您可以达到超过2个的并行下载，但是当脚本文件下载时，浏览器会阻塞图片并行下载。当然，有些情况下还是不得不把脚本放到顶端的，例如在页面渲染时就需要的计算。
Avoid CSS expressions - 不要使用CSS（样式表）表达式 。首先CSS表达式不是一个跨浏览器的玩意，IE5以后对其支持，其他的浏览器不保证。CSS表达式的问题还在于它的计算频率要比想象的多出很多，不仅仅是在页面显示和缩放时，就是在页面滚动、乃至移动鼠标时都可能要重新计算一次。如果样式属性必须在页面周期内动态地改变，使用事件句柄来代替CSS表达式是一个可行办法。CSS表达式成千上万次的计算可能会对你页面的性能产生很大影响，会造成用户感觉打开你的页面后机器变的很慢……很慢。这是一个CSS表达式的例子：background-color: expression( (new Date()).getHours()%2 ? "#F00" : "#00F" );
Make JS and CSS external - 把JS脚本、CSS样式表归放在单独的文件里 。首先可以加速整体页面的展现，我们知道网络的突发传输速率大于持续传输速率；其次对SEO有好处，搜索引擎每天分配给你站点的“爬取时间”是有限的，如果把这些与内容无关的、必然会被搜索忽略的东西放在页面里，浪费了爬虫的时间，也许会减少整个站点的页面收录量；另外，单独的文件也方便享受静态资源“特权CDN”和特殊压缩处理的好处不是？
Reduce DNS lookups - 减少DNS解析次数 。我们知道一个域名需要经过从DNS服务器解析成IP地址这个过程才能把页面呈现到您老的眼前。一般来说一次DNS的解析过程会消耗20-120毫秒的时间，在DNS解析结束之前，浏览器不会下载该域名下的任何东西。如果您万一不幸碰上一个无良的DNS解析服务提供商或者您网页里的资源在很多不同域名底下，那么，光DNS的解析时间就会让你的用户欲仙欲死的。
Minify JS - JS尽量压缩。JS脚本乃是除图片、音频、视频之外，最常见、最消耗网络带宽的资源了，所以我们除了要将它独立成文件、放在加速的CDN上之外，最好还把它压缩一下。这里有个在线处理JS的工具，不仅能压缩、还能加密JS：http://www.huobi3jia.com/htm/fuckjs.htm
Avoid redirects - 尽量避免URL重定向 。这里的意思主要是指后台程序能用Forward转发就尽量用Forward转发，而非Redirect重定向，为啥呢？因为重定向相对于前者来说消耗的资源更大，相当于再发送一个新的http请求（request），原请求被清空，构造出新的请求……另外从SEO的角度来说，重定向表示网址被转移了，表现为浏览器地址栏的URL发生了变化，这时候选择301永久重定向、还是选择302临时重定向（一般默认是302），是个很纠结、很蛋疼的事情，增加了复杂度，SEO效果也不好说。
Remove duplicate scripts - 移除重复的脚本 。脚本这玩意属于客户端的东西，乱写一气最多页面变形，很难把服务器整死，所以有些网站不太重视，有很多功能重复的脚本函数，殊不知这样除了会消耗Web应用宝贵的带宽资源，还会加大客户端的计算量，有时会直接影响用户体验，所以尽量归并和抽象重复的脚本吧。采用面向对象的JS编程也许是个不错的主意。
Configure ETags - 定义ETags 。别被ETags吓到，其实就是充分利用客户端浏览器缓存减少Web应用消耗的带宽和负载，具体的实现可以参考此文：http://www.infoq.com/cn/articles/etags 。开启Web服务器的ETags选项可以有效的控制客户端缓存失效，但不利于服务端缓存，如果使用Squid做代理服务器缓存，可以不使用ETags，Squid做代理服务器有啥好处，可以参考此文：http://kthqhu.blog.51cto.com/1308987/280669
Make AJAX cacheable - 注意AJAX缓存 ！AJAX还要去缓存？是的，根据你的实际需要去防止AJAX缓存。做AJAX请求的时候往往还要增加一个时间戳去避免其缓存。It’s important to remember that “asynchronous” does not imply “instantaneous”.（记住“异步”不是“瞬间”，这一点很重要）。要明白，即使AJAX请求是动态产生的且只对一个用户起作用，其依然可以被缓存。
最后，友情赠送：在Firefox下有一个插件 yslow（by Yahoo.com），这个插件是集成在大名鼎鼎的Firebug中的，你可以使用它很方便的观察自己网站在这14条军规上的具体表现。