網頁的資源載入最佳化

標籤：部分   選擇   相同   就是   技術   api   下載   導致   inf   

移動開發中很重要的一塊是資源的載入最佳化。移動開發由於網速低頻寬，高延遲，行動裝置小記憶體，低處理器效能的原因，因此很多時候不得不通過最佳化前端頁面的效能來滿足使用者對網頁載入的預期。

前段時間做了相關方面的最佳化，發現網上的中文教程比較少，都是照著chrome開發人員網站上一步一步看下來，找問題來解決，因此將部分有用的網頁整理翻譯了一下。

一、查看網頁載入速度

網頁載入時間長度受到網速影響，一般採用瀏覽器類比一個特定網速進行測試，這樣最佳化前與最佳化後的結果會有一個較準確的對比。

方法：開啟調試面板—選擇網速，一般我們Mobile Testing用的是regular 3g.然後重新整理頁面，開始查看頁面載入時間。

 

資源載入順序與耗時就會依次顯示出來，紅線表示DOM載入的時間。

 

 

二、資源載入的順序與說明

資源請求的生命週期如下：

 

重新導向 - 應用程式緩衝 - DNS - TCP - 請求 - 響應

對於某一個資源，點擊資源載入進度條可以看到具體每一階段的載入時間。或者可以在console面板中，通過timing api擷取。

performance.getEntriesByType(‘resource‘).filter(item => item.name.includes("style.css"))

 

具體解釋如下：

• Queueing（排隊）：瀏覽器有串連限制，當網頁資源很多時就會出現排隊的現象，排隊的資源要等到上一個資源載入完畢釋放後才能開始請求。比關鍵資源（如javascript與css）低優先順序的請求會被瀏覽器延遲，一般延遲的都是圖片。在許多資源同時發起請求時瀏覽器預設先載入css,然後javascript，最後才是圖片。

• Stalled(阻塞)：請求在發送前的時間被成為阻塞。阻塞的原因有很多種，導致排隊的原因或是Proxy Negotiation都能造成阻塞。

• DNS Lookup（DNS查詢）：DNS尋找的時間，網頁資源中請求每一個新域都需要做一次完整的DNS查詢。

• Initial Connection（初次串連）：初次建立串連需要花費的時間。

• Request Sent(請求發送時間)：網路請求發送的時間。

• Waiting(TFFB)(等待時間)：等待伺服器初始響應的時間。

• Content Downloading（下載時間）:資源下載的時間。

三、診斷原因與解決方案

通過chrome網路面板調試，經常會看到每次載入的時間都不太相同，造成載入慢會有許多原因。前端需要最佳化，但很多時候是後台或者網路的問題。

1. 排隊問題

最長見的問題就是資源排隊問題。在HTTP1.0/1.1串連中，chrome最多允許對同一host一次有6個串連，如果網頁種有12個資源，那後面的6個就需要排隊，直到前面的下載完畢，才能按次序發起請求。解決這個問題，首先要減少網頁的請求，例如css sprite、js/css壓縮、採用緩衝、按需載入等等。

還有一種方法，將資源放在不同的子網域名稱下，比如將圖片資源與靜態資源分開可以大大加速網頁載入時間，但這個方法對HTTP2的串連不適用。

 

2. TFFB時間慢

 

TFFB時間通常建議在200ms以下，如果超過推薦值，會引起隊列中其他資源下載都跟著變慢。TFFB高主要有兩個原因：一是用戶端和伺服器之前網路情況比較差；二是伺服器應用響應比較慢。首先排除網路因素，在本地環境看一下是否仍舊存在TFFB情況，如果有，需要最佳化應用程式的回應時間，例如最佳化資料庫查詢、實現資源緩、修改web伺服器配置等等。
如果是由於網路引起的，那伺服器與用戶端的每一個節點都有可能引起這個問題，最簡單的方法是把應用遷移至其他伺服器看看是不是存在這個問題，然後一個節點一個節點查明原因。

3. 下載時間過久

 

如果大量的時間花在下載上，那提高伺服器響應也沒用，還是應該將檔案進行壓縮

網頁的資源載入最佳化