簡單聊聊網頁的資源加載優化

移動開發中很重要的一塊是資源的加載優化。移動開發因爲網速低帶寬，高延遲，移動設備小內存，低處理器性能的緣由，所以不少時候不得不經過優化前端頁面的性能來知足用戶對網頁加載的預期。

前段時間作了相關方面的優化，發現網上的中文教程比較少，都是照着chrome開發者網站上一步一步看下來，找問題來解決，所以將部分有用的網頁整理翻譯了一下。

1、查看網頁加載速度

網頁加載時長受到網速影響，通常採用瀏覽器模擬一個特定網速進行測試，這樣優化前與優化後的結果會有一個較準確的對比。

方法：打開調試面板—選擇網速，通常咱們移動測試用的是regular 3g.而後刷新頁面，開始查看頁面加載時間。

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

2、資源加載的順序與說明

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

重定向 - 應用程序緩存 - 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（下載時間）:資源下載的時間。

3、診斷緣由與解決方案

經過chrome網絡面板調試，常常會看到每次加載的時間都不太相同，形成加載慢會有許多緣由。前端須要優化，但不少時候是後臺或者網絡的問題。

1. 排隊問題

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

還有一種方法，將資源放在不一樣的子域名下，好比將圖片資源與靜態資源分開能夠大大加速網頁加載時間，但這個方法對HTTP2的鏈接不適用。

2. TFFB時間慢

TFFB時間一般建議在200ms如下，若是超過推薦值，會引發隊列中其餘資源下載都跟着變慢。TFFB高主要有兩個緣由：一是客戶端和服務器以前網絡狀況比較差；二是服務器應用響應比較慢。首先排除網絡因素，在本地環境看一下是否仍舊存在TFFB狀況，若是有，須要優化應用程序的響應時間，例如優化數據庫查詢、實現資源緩、修改web服務器配置等等。
若是是因爲網絡引發的，那服務器與客戶端的每個節點都有可能引發這個問題，最簡單的方法是把應用遷移至其餘服務器看看是否是存在這個問題，而後一個節點一個節點查明緣由。

3. 下載時間太久

若是大量的時間花在下載上，那提升服務器響應也沒用，仍是應該將文件進行壓縮。

最後

前端優化路漫漫，敵人是毫秒，卻須要十八般武藝才能攻克。且行且思考吧。

參考資料：https://developers.google.com/web/tools/chrome-devtools/profile/network-performance/understanding-resource-timing#diagnosing-network-issues