性能優化的十條最經典的建議

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 的那些優化方法。