今天大致瀏覽了一下《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機制，具體參見原則3、13。
作者：楊夢冬
文章來源：楊夢冬的部落格轉載請註明出處連結。