網站加速的14條軍規 （轉載）

若是網站的響應速度太慢，即便內容再好，也更會形成用戶體驗從「抓狂 - 憤怒 - 永遠離開 - 壞口碑傳播」這樣的毀滅性路線。

   
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.

   
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條軍規上的具體表現.

 

http://briteming.**.kr