我們都說互連網內容制勝，但如果網站的響應速度太慢，即使內容再好，也更會造成使用者體驗從“抓狂 - 憤怒 - 永遠離開 - 壞口碑傳播”這樣的毀滅性路線。
- 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的Proxy 伺服器軟體也很出色，如 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做Proxy 伺服器緩衝，可以不使用ETags，Squid做Proxy 伺服器有啥好處，可以參考此文：http://blog.csdn.net/kthq/archive/2009/08/17/4456385.aspx
- Make AJAX cacheable - 注意AJAX緩衝
！AJAX還要去緩衝？是的，根據你的實際需要去防止AJAX緩衝。做AJAX請求的時候往往還要增加一個時間戳記去避免其緩衝。It’s important to remember that “asynchronous” does not imply “instantaneous”.（記住“非同步”不是“瞬間”，這一點很重要）。要明白，即使AJAX請求是動態產生的且只對一個使用者起作用，其依然可以被緩衝。
（本文始發於CSDN，作者胡奇的部落格：http://blog.csdn.net/kthq
）
最後，友情贈送：在Firefox下有一個外掛程式 yslow（by Yahoo.com），這個外掛程式是整合在大名鼎鼎的Firebug中的，你可以使用它很方便的觀察自己網站在這14條軍規上的具體表現。
