轉載一篇實用文章，幹活多多

今日大體瀏覽了一下《High Performance Web Sites》。本書的中文版是《高性能網站建設指南》。本書另有對其中個別問題深刻探究的進階篇《Even Faster Web Sites》，中譯《高性能網站建設進階指南》。

　　這本書中給出了14條網站性能提高的原則，每一個原則獨立成章，配有示例。這些原則大多數都很是實用，適合站點架構師、前端工程師。其中對於前端工程師的意義更大一些。

　　此次看的是原版。我對於Web開發較缺少實踐經驗，加之看得匆忙，所以可能存在遺漏、表述不當之處，但願廣大網友不吝指正。

　　原則1 減小HTTP請求數

　　構造請求、等待響應須要時間，所以請求數量越少越好。減小請求的整體思路就是合併資源，減小顯示一個頁面須要的文件數。

　　1. Image Map

　　經過設置<img>標籤的usemap屬性與使用<map>標籤能夠在一幅圖片上切分出多個區域，指向不一樣的連接。比起使用多幅圖片分別構造連接減小了請求數。

　　2. CSS Sprite（CSS貼圖整合/貼圖拼合/貼圖定位）

　　經過設置元素的background-position樣式作到。通常用於界面圖標。典型的能夠參考TinyMCE編輯器上方的那些小按鈕。多個小圖實質是從一個統一的大圖經過不一樣的偏移量裁剪而來，這樣加載界面上的衆多按鈕實際上只要請求一次（請求大圖一次），從而減小HTTP請求數。

　　3. Inline Image（內聯圖片）

　　在<img>的src中不指定外部圖片文件的URL，而是直接將圖片信息放入。例如src=」data:image/gif;base64,R0lGODlhDAAMAL...」某些特殊狀況下有用（例如一個不大的圖片僅在當前頁面用到）。

　　原則2 利用多線路CDN

　　爲你的站點提供多種線路（例如國內電信、聯通、移動）、多個地理位置（北方、南方、西部）的訪問，使得全部用戶都可以快速訪問。

　　原則3 利用HTTP Cache

　　給不頻繁更新的資源（例如靜態圖）加較長的Expires頭信息，這些資源一經緩存，將來很長時間均可以再也不重複傳輸了。

　　原則4 使用Gzip壓縮

　　使用Gzip壓縮HTTP報文，減少體積，減小傳輸時間。

　　原則5 將樣式表置於頁面前部

　　先加載樣式表，這樣頁面渲染得以較早開始，給用戶頁面加載較快的感受。

　　原則6 將腳本置於頁面尾部

　　緣由同5，先處理頁面顯示，頁面渲染較早完成，而腳本邏輯稍後執行，這樣給用戶頁面加載較快的感受。

　　原則7 避免使用CSS表達式

　　過於複雜的JavaScript腳本邏輯、DOM查找、選擇操做將會下降頁面處理效率。

　　原則8 將JavaScript與CSS做爲外聯資源

　　這彷佛與原則1中的合併思想相悖，但其實否則：考慮每一個頁面都引入了一個公共的JavaScript資源（例如jQuery或是ExtJS這樣的JavaScript庫），單就一個頁面的表現來看，內聯（即將JavaScript嵌入HTML）頁面將比外聯（使用<script>標籤引入）頁面加載更快（由於其較少的HTTP請求數）。但若是有不少頁面都引入了這個公共JavaScript資源，那麼內聯方案會形成重複傳輸（由於這個資源內嵌在每一個頁面中了，因此每次打開一個頁面都要將這部分資源傳輸一遍，從而形成網絡傳輸資源的浪費）。而將這種資源獨立出來外聯引用能夠解決這個問題。

　　因爲JavaScript和CSS相對穩定，咱們能夠對其對應的資源設置較長的失效期（參考原則3）。

　　原則9 減小DNS查找

　　做者給出的建議是：

　　1. 使用Keep-Alive保持鏈接

　　若是鏈接斷開，那麼下次鏈接又要執行DNS查找，即便對應的域名-IP映射已被緩存，查找也是要消耗一些時間的

　　2. 減小域名

　　每次請求新域名都須要進行經過DNS查找不一樣的域名，且DNS緩存沒法發揮做用。所以應該儘可能將站點組織在一個統一域名下，避免使用過多子域名

　　原則10 壓縮你的JavaScript

　　使用JS壓縮工具壓縮你的JavaScript吧，頗有效哦。看看jQuery的兩個不一樣的發行版本就知道區別了：

　　http://code.jquery.com/jquery-1.6.2.js 閱讀版jQuery代碼，230KB
　　http://code.jquery.com/jquery-1.6.2.min.js 壓縮版jQuery代碼（用於實際部署），89.4KB

　　原則11 儘可能避免重定向

　　一次重定向意味着在你真正訪問到想要看到的頁面前加入了一輪額外的HTTP請求（客戶端發起HTTP請求→HTTP服務器返回重定向響應→客戶端對新URL發起請求→HTTP服務器返回內容，下劃線部分爲額外的請求），所以消耗更多的時間（也就給人反應更慢的感受）。所以除非必要，不要隨意使用重定向。幾個「必要」的狀況：

　　1. 避免URL失效

　　舊站點遷移後，爲了不舊的URL失效，一般將對舊URL的請求重定向至新系統的對應地址。

　　2. URL美化

　　在可讀性好的URL與實際資源URL之間轉換，例如對於Google Toolbar，用戶記得住http://toolbar.google.com這個對人類富有語義的地址，卻很難記住http://www.google.com/tools/firefox/toolbar/FT3/intl/en/index.html這個真正的資源地址。所以有必要保留前者，而且將對前者的請求重定向至後者。

　　原則12 移除重複的腳本

　　不要在一個頁面中重複引入相同的腳本。例如腳本B和C都依賴於A，那麼在使用了B和C的頁面中就有可能存在對A的重複引用。解決方法，對於簡單的站點手動檢查依賴性，消去重複引入；對於複雜的站點則須要構建本身的依賴管理/版本控制機制。

　　原則13 當心處理ETag

　　ETag是除Last-Modified以外的另外一種HTTP Cache手段。經過hash的辦法辨識資源是否被修改。但ETag存在一些問題，例如：

　　1. 不一致：不一樣Web服務器（Apache, IIS等）定義的ETag格式不一樣

　　2. ETag的計算是不穩定的（因爲考慮過多因素），例如：

1) 相同資源在不一樣服務器上計算出來的ETag不同，而大型Web應用一般由不止一臺服務器提供服務，這就致使客戶端在服務器A緩存好的資源明明仍然有效，而在下次請求B時因爲ETag不一樣而被認定爲失效，致使相同資源的重複傳輸。

2) 資源不變，而因爲一些其餘因素的變化，例如配置文件更改，致使ETag變化。直接後果是系統更新後客戶端大規模發生Cache失效，致使傳輸量大增，站點性能降低。

　　做者給出的建議是：要麼根據你的應用特色改進已有的ETag計算方法，要麼乾脆就不用ETag，而改用最簡單的Last-Modified. 

　　原則14 在Ajax中利用HTTP Cache

　　Ajax是異步請求，異步請求不會阻塞你如今的操做，並且當請求完成時，你立刻就能夠看到結果。但異步不表明可以瞬時完成，也不表明可以容忍它花無限多的時間完成。所以對於Ajax請求的性能也須要重視。有不少Ajax請求訪問的是一些相對穩定的資源，所以別忘了對Ajax請求利用好HTTP Cache機制，具體參見原則三、13.