WEB性能優化
寫在前面
Web性能優化是一個近年來新興的一個產業，該發展迅速主要取決於企業越來越重視用戶體驗。用戶也越來越重視速度方面的體驗，很多企業證實網站越快，用戶的黏性，忠誠度，轉化率纔會越來越高。
對web性能的優化主要就是優化其速度，而要優化速度就要研究影響速度提升的各種因素。對於速度來講，對其有影響的無外乎帶寬與延遲。
延遲 ：分組從信息源發送到目的地所需的時間。
帶寬 ：邏輯或物理通信路徑最大的吞吐量。
頁面加載時間與帶寬和延遲的關係
曾有人對互聯網上最熱門的一些站點的頁面加載時間和帶寬與延遲做過一些測試，結果如下圖：
頁面加載時間與帶寬和延遲的關係
在第一個測試中，連接的延遲時間固定而帶寬遞增，從 1 Mbit/s 依次遞增至 10Mbit/s。注意一開始，從 1 Mbit/s 升級到 2 Mbit/s，頁面加載時間幾乎減少了一半，這也是我們希望看到的結果。可是，在此之後，帶寬遞增，加載時間減少得越來越不明顯。而當帶寬超過 5 Mbit/s 時，加載時間的減少比例只有幾個百分點，從 5Mbit/s 升級到 10 Mbit/s，頁面加載時間僅降低了 5%。
由此可知，靠提高帶寬不會給用戶瀏覽網頁帶來多大的性能提升。或許用戶下載大文件、看視頻的速度很快，但加載包含這些文件的頁面的時間不會明顯縮短。換句話說，增加帶寬沒有那麼重要。然而，在延遲以 20 ms 遞減的試驗中，頁面加載時間呈線性減少趨勢。
當我們的帶寬提高已不能快速提升站點性能時，就應該圍繞延遲這一因素來對其進行優化。我們無法掌握用戶與服務器端的網絡狀況，和用戶手持怎樣高級或者怎樣爛的一個終端設備來訪問我們的站點，但是除此之外的一切都應該是我們所能夠操控的。OSI協議模型的有七層結構，每一層都會有一些不必要的延遲產生，讓我們對這七層的每一層都做到滴水不漏的優化顯然是不可能的。但是努力追求去做到對每一層的優化顯然是值得的。
對於通信信道來講，其物理屬性顯然是一個比較硬性的限制，在無法打破光速這個‘天道極限速度’時，只有縮短其數據傳輸的距離了。
既然不能讓數據跑的更快，那麼只能去優化其傳輸層與應用層。我們可以去消除不必要的往返，請求。縮短傳輸距離—把數據放置在最後一公里。
對性能優化的建議
說到底，無論什麼網絡或者網絡協議版本，所有應用都應該致力於消除或者減少不必要的網絡延遲，將其需要傳輸的數據壓縮至最少。這兩條標準纔是最爲經典的性能優化建議。
對其優化前人已總結有十條優化準則：
1 減少DNS查找
每一次主機名解析都需要一次網絡往返，從而增加請求的延遲時間，同時還會阻塞後續請求。
2 重用TCP連接
儘可能使用持久連接，以消除 TCP 握手和慢啓動延遲；
3 減少HTTP重定向
HTTP 重定向極費時間，特別是不同域名之間的重定向，更加費時；這裏面既有額外的 DNS 查詢、TCP 握手，還有其他延遲。最佳的重定向次數爲零。
4 使用 CDN（內容分發網絡）
把數據放到離用戶地理位置更近的地方，可以顯著減少每次 TCP 連接的網絡延遲，增大吞吐量。這一條既適用於靜態內容，也適用於動態內容；
5 去掉不必要的資源
任何請求都不如沒有請求快。說到這，所有建議都無需解釋。延遲是瓶頸，最快的速度莫過於什麼也不傳輸。然而，HTTP 也提供了很多額外的機制，比如緩存和壓縮，還有與其版本對應的一些性能技巧。
6 在客戶端緩存資源
應該緩存應用資源，從而避免每次請求都發送相同的內容。
7 傳輸壓縮過的內容
傳輸前應該壓縮應用資源，把要傳輸的字節減至最少：確保每種要傳輸的資源採用最好的壓縮手段。
8 消除不必要的請求開銷
減少請求的 HTTP 首部數據（比如 HTTP cookie），節省的時間相當於幾次往返的延遲時間。
9 並行處理請求和響應
請求和響應的排隊都會導致延遲，無論是客戶端還是服務器端。這一點經常被忽視，但卻會無謂地導致很長延遲。
10 針對協議版本採取優化措施
HTTP 1.x 支持有限的並行機制，要求打包資源、跨域分散資源，等等。相對而言，HTTP 2.0 只要建立一個連接就能實現最優性能，同時無需針對 HTTP 1.x 的那些優化方法。