如何打造亞秒級加載的網頁2——網絡性能 過程解讀

對於咱們前端來講，頁面的加載速度是直接影響到用戶的體驗度

這一篇是第二篇關於提升網頁加載速度的博客了，

第一篇能夠在我之前的博客中找到

附上連接：

http://www.javashuo.com/article/p-ywbpgluf-dr.html

PS：本篇博客中我沒作太多樣式處理，若是你對這方面有興趣的話請耐着性子看完，畢竟是有點枯燥的

 

頁面加載速度影響因素——網絡性能   

過程解讀

 

在瀏覽器中輸入 http://www.thinks.com/ 並按下回車後，

瀏覽器首先經過DNS查詢解析該域名對應的IP地址

訪問每一個域名都須要進行這樣的查詢

 

在得到IP地址後，瀏覽器發起一個到服務器的TCP鏈接，TCP握手須要2次往返（1次可以使用TCP Fast Open）。

對於安全的SSL鏈接，TSL握手須要額外的2次往返（1次可以使用TLS False Start 或 Session Resumption）。

 

初始鏈接完成後，瀏覽器發出的實際請求並等待返回的數據。得到首個字節所須要的時間主要取決於客戶端和服務器之間的距離，

其中還包括服務器呈現網頁（包括回話查詢、數據庫查詢、模板呈現等環節）所需的時間

 

最後一步須要下載資源（本例中爲HTML）這一過程須要屢次往返，尤爲是新鏈接一般須要更多往返，

由於初始擁塞窗口很小。這意味着TCP並不能在一開始就全面使用全部可用帶寬，而是會隨着時間流逝逐漸增長帶寬用量（可參閱TCP擁塞控制）。

具體速度受制於啓動速度緩慢的算法，這種狀況下會讓每一個往返的擁塞窗口內片斷數量翻倍，直到數據包真正開始丟失。

在移動和WiFi網絡中，由於這種狀況致使的數據包丟失會對性能產生極大影響。

 

另外還要注意：在使用HTTP/1.1 的狀況下，最多隻能建立6個併發鏈接（若是瀏覽器依然沿襲了最初的標準，則最多隻能建立2個鏈接）。

 

頁面加載速度影響因素——網絡性能 

一、 持久鏈接是必須的。HTTP是基於TCP應用協議進行數據請求的，TCP是服務器握手的協議

若是每次請求數據，都須要從新進行TCP握手，請求速度會有很大的影響，使用websocket能夠保證持久鏈接

 

二、 儘量避免重定向，重定向會大幅度下降頁面初始加載速度。例如請儘可能連接至完整URL（例如連接至www.thinks.com 而不是 thinks.com）

 

三、 可行的狀況下使用HTTP/2。該標註可經過服務器推送一個請求傳輸多個資源，並可經過頁頭壓縮下降請求和迴應數據大小，

同時可經過管道化（Pipelinling）和多路複用（Multiplexing）藉助一個鏈接發送任意數量的並行請求，

例如在使用服務器推送的狀況下，服務器能夠在發送HTML的同時，無需等待實際發出請求，

直接將網頁所需的CSS和JS發送給客戶端

 

四、 爲靜態資源（CSS  JS  徽標等圖片）設置明確的緩存標頭。藉助能夠告訴瀏覽器將這些資源緩存多久，什麼時候從新驗證。

緩存機制可大幅減小往返次數以及須要下載的字節數。

若是未設置明確的標頭，瀏覽器將會進行啓發式（Heuristic）緩存，

雖然是權宜之計，但這總歸併不是最優化的作法

 

五、 使用內容交付網絡（CDN）緩存圖片、CSS、JS和HTML。這種分佈式緩存網絡能夠大幅拉近用戶與資源之間的距離，

實現更快速的資源交付。同時這種技術也能夠加快初始化鏈接速度，由於此時將會與距離最近的CDN節點進行TCP和TLS握手，

同時這種節點會與網絡後端創建快速持久的鏈接。在客戶端緩存資源

 

六、 考慮構建單頁面應用，其中只包含小體積的初始頁面，並經過異步方式加載其他內容。

爲此可使用可緩存的HTML模板，經過小請求加載動態數據，並只在導航過程當中對頁面中的部分區域進行更新

 

七、 在客戶端緩存資源：緩存必要的應用資源，避免每次都重複請求相同的內容，例如多圖片下載能夠考慮使用緩存

 

 

 

呼~枯燥的知識普及到這總算是告一段落了

下次更新爲你們作一個小總結

敬請期待： 

 　　如何打造亞秒級加載的網頁3——用戶體驗  總結