我們都說互聯網內容制勝，但如果網站的響應速度太慢，即使內容再好，也更會造成用戶體驗從“抓狂 - 憤怒 - 永遠離開 - 壞口碑傳播”這樣的毀滅性路線。
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條軍規上的具體表現。