歡迎訪問我的主頁，最新的文章我會首先發布在個人主頁上：
http://blog.guaidm.com/shocky/
原書下載地址：http://pan.baidu.com/s/1pJocRwB
在我的web開發生涯裏，大部分時候我都是作爲一個後臺工程師。這樣一來，我投入了非常多的精力去研究、練習如何通過後臺優化來提升項目產品的性能，諸如編譯器選項，數據庫索引，內存管理等。很多書都花大量篇幅來講述如何在這些方面提高性能，很多人也進而在這方面的優化花了大量時間。說實話，很多WEB網頁，真正花費在web服務器到終端用戶的時間其實往往不超過整個響應時間的一兩成。如果你真的想極大幅度地減少web頁面的響應時間，你應該把注意力放在真正影響終端用戶體驗的另外八九成的內容上。那這80%-90%的時間到底花費在哪了？怎樣才能去減少？基於現如今WEB應用的基本原理，本書的以下章節便將來提供14條加速優化法則。
Tracking Web Page Performance
追蹤網頁性能
爲了能夠找到性能的提升點，我們必須知道用戶的時間花在哪了。圖表A-1展示了當用戶用IE瀏覽器訪問雅虎首頁(http://www.yahoo.com)時的HTTP傳輸情況。每個橫條是一個html請求。第一個名爲html的橫條是表示初始化HTML文檔，瀏覽器解析HTML文本並開始下載其中的文檔元素。在這個例子中，由於瀏覽器的緩存爲空，所以所有的元素都需要進行下載。下載HTML文檔僅僅耗費了全響應響應時間中的5%，所以另外95%的用戶等待時間都用在了下載文檔節點的具體元素內容上。當然，還有很小的一部分時間花在了等待解析HTML、腳本和CSS上，也就是圖中兩個下載條之中的空白區間。
圖標A-2展示了使用IE瀏覽器第二次訪問同一個URL地址時候的情況。HTML文檔初始化依舊只佔用了12%的總響應響應時間，而且絕大部分元素內容不需要再下載了，因爲他們已經在瀏覽器的緩存裏。
不過在第二次訪問時，有5個元素還是被請求進行下載了：
一個重定向：
這個重定向的內容其實之前就下載過，但是瀏覽器還是又請求了一次，這回HTTP響應結果是302（"Found" 或 "move temporarily") ，並且在返回的報頭中並沒有任何緩存信息，所以瀏覽器也沒辦法緩存本次響應結果。關於這個我將在章節B中對HTTP進行討論。
三張未進行緩存的圖片
接下來之所以三個圖片被請求下載了是由於之前第一次訪問時沒有被下載緩存過，這三張圖是新聞圖片和廣告圖片，所以會被頻繁的更換。
一張已經被緩存的圖片
最後一個HTTP請求是一個條件GET請求。這個圖片之前已經被緩存過了，但是由於HTTP的響應報頭中的參數設置，瀏覽器必須在確保圖片是最新版本的圖片後才能給到用戶。關於條件GET請求也會在章節B中進行討論。
Where Does the Time Go?
時間都去哪了？
這麼一來，我們發現：至少80%的響應時間是花在了下載頁面元素內容上。當我們去深度挖掘這些圖表的細節時，我們將會逐漸看到HTTP與瀏覽器之間及其複雜的交互過程。之前，我已經提到過HTTP的狀態碼和報頭是如何影響瀏覽器的緩存操作的。除此之外，我們還能注意到以下幾點：
1. 在使用了緩存的情況下（圖表A-2)，並不會有很多下載請求。相反，你會看到在HTML文檔初始化解析完成後，緊接着出現一段沒有任何下載記錄的空白區域。這一段時間就是用來解析HTML文檔，JS和CSS，同時也包括了從緩存中取出已有的元素內容。
2.時刻變化的並行HTTP請求數。圖表A-2最多時候出現了3個並行的HTTP請求，然而在圖表A-1中卻有了多達6、7個HTTP請求同時出現。這種現象緣於不同域名的數量的影響，並且無論這個使用的協議HTTP/1.0還是HTTP/1.1 。 關於這個問題我們將在章節6“並行下載”中進行深入探討。
3. 並行請求並不會發生在腳本被請求時，這是因爲在絕大多數時候，瀏覽器會對除開下載腳本之外的請求進行阻塞。章節6中對此的原因進行了解釋，並介紹瞭如何利用這種特點來加快頁面加載速度。
精確找出時間到底花在哪了，這很難。但是要找出哪裏沒花時間，卻很容易——下載HTML文檔不費時，與之相關的任何的後臺處理也不費時。既然這些不費時，那麼我們便可以意識到，優化前端中那些費時的東西，是何等重要了。
The Performance Golden Rule
性能優化黃金條例
之前我們提到了只有10-20%的響應時間被花在了下載HTML文檔上，而這種現象並不僅僅只發生在雅虎網站的首頁。之前的這些數據特點能夠非常好的適用於雅虎的幾乎所有功能（除了雅虎的搜索功能，因爲那個搜索頁的元素實在太少了）。並且，這些統計數據同樣適用於絕大部分網站。表格A-1展示了http://www.alexa.com選出的美國十大網站。當然有點小改動：除了AOL以外其他都是美國十大網站，其中Craigslist.org位列其中，但是該網站幾乎沒有圖片，腳本和CSS，所以實在是沒辦法成爲一個好的例子。所以我換做把AOL選入進來了。
同樣的，幾乎所有的網站都是在只將低於20%的響應時間用在下載HTML文檔上，其中唯一的一個列外是在有緩存環境下的Google。這是因爲http://www.google.com總共只有6個文檔元素，除了一個元素以外，其他的所有元素都被設定爲瀏覽器緩存處理。在之後的訪問中，由於這些元素都已經被緩存了，就只剩下HTML文檔請求和一個image beacon。
在所有的性能優化中，最關鍵的是通過刻劃界定當下的性能表現，來指出哪裏纔是真正能夠大幅度提升行性能的要害之處。很明顯，前端纔是我們真正要關注的性能優化點。
首先，優化前端對總體性能的提升蘊藏着巨大的潛力。我們把後臺系統處理的花費時間減半，那終端用戶的響應時間無非就是縮短5-10%；相反，如果我們在前端上將時間減半，將可以縮短總響應時間的40-50% ！
其次，前端性能優化通常花費的時間更少，所需的資源也更少。要縮短後臺的等待時間，我們往往會不可避免地要做各種的事情，比如重新設計架構與代碼，找到並優化有問題的代碼分支，添加或修改硬件設備，數據庫分佈式搭建等等。這些事往往需要花費幾周乃至幾個月時間。而我們之後一些章節要提到的前端性能優化措施，將都是更利於實際操作的最佳實踐方案，諸如修改WEB服務器配置（章節3、4）；變更腳本和CSS在web頁面中的位置（章節5、6）；合併圖片、腳本和CSS（章節1）。而這些工作僅僅花費幾個小時或者幾天——這遠遠低於後臺優化所需的時間。
再有，前端優化的實際價值已經得到印證。在雅虎，超過50個團隊通過使用這些最佳實踐方案，成功降低了終端用戶的響應等待時間，縮減比例很多達到了25%甚至更多。當然，在很多時候，我們必須不拘泥於這些法則，根據網站的具體情況進行更具體的分析與優化，但是一般來說，通過這些最佳實踐，提升25%的性能甚至更高，這都是完全有可能的。
在每一次開始進行行性能優化的時候，我都會畫一個像類似A-1的圖表，然後註明上性能優化的黃金法則：
10-20%的時間其實使用來下載HTML文檔，其他的80-90%時間是在下載頁面元素。
本書的其他部分將會精確仔細的介紹這些如何降低這80-90%的耗費時間。爲了說明清楚這些，我將會囊括很多方面的技術：HTTP請求頭、JavaScript、CSS、Apache 等等。
考慮到HTTP的基礎概念是理解本書的關鍵所在，我將這一塊單獨提升到了章節B來進行講述。
在章節B後便是提升性能的14條法則，每一條法則一個章節。這些法則按照我們通常理解上的優先順序來進行排序，當然，一個法則是否能夠很好的適用於你特定的網站，這個要是具體情況而定。舉例來說，法則2更適應於商業網站而並非適用於個人網站。如果你採用了所有的適合你的網站的優化手段，你將可以讓你的頁面訪問速度提升25-50%，同時大大改善用戶體驗性。本書的最後章節展示瞭如何從性能角度來分析美國的十大網站。