Chrome調試工具NetWork模塊

Chrome調試工具NetWork模塊

在項目開發中,不可避免須要調用不少後臺服務,資源加載,這些全部的Http請求以及資源加載都能在Chrome的調試工具中的NetWork模塊上進行觀察,熟練掌握這個NetWork模塊,可以更好的完成先後端接口聯調,進行一些簡單的性能分析,甚至據此做出性能優化,下面將簡單介紹我對NetWork模塊認識和簡要理解。css

1.模塊概覽

2.控制模塊

控制模塊的概覽如圖所示,將其劃分紅了9個功能點,下面一一介紹。

2.1 中止記錄

中止記錄就是個紅色的按鈕,當點擊後NetWork模塊就不會再進行任何的Http請求記錄,從新點擊後又能夠打開記錄。前端

2.2 清除記錄

點擊清除記錄按鈕後,資源及服務調用列表中已經記錄的全部請求將會被清除。json

2.3 截屏模式

截屏模式爲一個攝像機的標誌,點擊後開啓截屏模式的功能,當從新刷新頁面後,會對你的可視區域進行定時捕獲截屏,同時當鼠標移動到截屏圖片上時,在時間軸模塊中會展現黃色豎線,表示截取這張圖片時所處的時間節點。 後端

2.4 過濾欄顯示隱藏

點擊該按鈕能夠控制過濾欄的顯示隱藏。緩存

2.5 請求列表大圖標模式

點擊該按鈕後資源及服務調用列表每一行的圖標變大,一樣可視區域所能同時瀏覽的http請求記錄變少,實際用處不是很大。性能優化

2.6 時間軸顯示隱藏

控制時間軸的顯示隱藏服務器

2.7 刷新頁面記錄列表更新

點擊該按鈕後控制頁面刷新以後,資源及服務調用列表中記錄的各類請求信息是否會刷新,默認狀態下刷新後將會從新記錄新的http請求,可是點擊該按鈕後,刷新頁面後會將上一次的http請求也一併保留下來。cookie

2.8 是否使用緩存

默認狀態下,當打開F12調試工具後是不會使用緩存的,這樣設置方便記錄一些資源的獲取狀況,由於若是資源都是從緩存獲取的話,根本看不出資源獲取的快慢性能等。點擊後,緩存爲可用狀態,在F12調試工具狀態下亦可以使用緩存。網絡

2.9 網速模式

在這個選項下可選擇不一樣的網速,方便測試網站在不一樣網速下的一些實際操做狀況。併發

3. 過濾

過濾模塊能夠經過輸入或選擇一些條件篩選出各類類型的http請求。篩選類型我簡單列出以下幾種(不完整,有待補充)

  • 經過名稱進行模糊篩選
  • 經過Http請求的status狀態進行篩選,好比說統一篩選出404的請求或500的請求
  • 經過Http請求的請求方法進行篩選,如GETPOST
  • 經過Http請求的文件類型進行篩選,如cssjpgjs
  • 經過協議進行篩選,如httphttps

4. 時間軸

這個模塊展示了各類資源加載的時間線,多個時間線出現堆疊是由於進行了同時加載,能夠進行框選,選擇某個時間段的資源加載以及請求進行查看,其中比較重要的就是時間軸中出現的藍線和紅線,藍線表明的是DomContentLoaded,紅線表明的是Load事件。

DomContentLoaded:Dom加載徹底,此時樣式表、js、圖片等都還沒有加載完成,可是此時已經能夠對dom元素進行操做了。

Load:此時全部資源都已加載完畢。

5. 資源加載及服務調用列表

這個能夠說是整個NetWork模塊中最重要的地方了,裏面不只包含了初始化時各類資源加載的具體時間分佈,同時也能夠在此查看調用後臺服務時的具體信息,不管時在頁面首屏渲染調優或是在接口聯調中,這部分都是很重要的部分,必須瞭解其中的具體含義。

5.1資源加載時間分佈

這部分是比較重要的部分,經過將鼠標放置在Waterfall列上能夠看見某個資源的具體加載時長分佈狀況,經過分析資源加載時間能夠了解到某些資源爲何長時間沒法加載的緣由,從而定位首屏時間慢的具體問題,針對這個問題做出優化改進。

下面,詳細介紹一下各個字段的含義,以及某一項耗時過長的緣由分析:

Queueing:這個字段表示等待時間,Chrome默認同一時間最多同時加載6個資源,因此當同一時刻請求資源過多時就須要排隊等待;若是這個等待時間過長,可能須要考慮進行資源合併了,好比使用精靈圖,減小資源的訪問次數。

Stalled:這個字段表示HTTP鏈接創建到請求可以被髮送出去的時間;若是這個時間過長可能須要考慮是否訪問的服務器那邊阻塞了?對高併發處理不到位。

Proxy negotiation:這個字段表示與代理服務器鏈接所花的時間。

DNS Lookup:執行DNS查詢的時間,網頁上每個新域名都要通過DNS查詢,當第一次打開頁面時這個查詢時間會比較長,可是第二次打開後就會有緩存,這個時間會降爲0。

Initial connection:創建鏈接話費的時間,包含了TCP握手及重試時間。

SSL:SSL是在https的加密證書,當訪問的資源路徑協議爲https時就須要加載SSL證書,完成SSL握手。

Request sent:發起請求的時間。

Waiting(TTFB):服務器接收到請求之後直到返回第一個字節的時間;若該時間較長,則能夠考慮是否網絡條件較差,或服務器響應慢,這個基本上是網絡問題或服務器問題,好比是否發送的某些特定條件致使服務器陷入較深的循環等,須要考慮對網絡或服務器進行性能優化了。

Conetn Download:服務器已將數據返回到Response中,獲取Response中的數據所花費的時間;若該時間較長,則應該是返回的資源字節數較大,須要較長時間才能下載完成。

5.2資源詳細信息

這一樣是很重要的部分,當咱們點擊某一個資源的Name時就會展開該資源的詳細信息,這些信息包括Http頭信息,返回資源預覽,返回資源,cookie信息,資源分佈時間。

下面,詳細介紹一下各個字段的含義,以及實際調試過程當中如何根據這些信息進行調試:

Headers:這其中包含了這個資源訪問請求的HTTP頭信息,包括請求頭、響應頭、General和Request-payload。請求頭和響應頭的具體使用狀況就不過多贅述了,這裏說一下General和Request-payload。在General中,咱們能夠看到請求的地址,請求的方式等,有時候一些接口調用404的緣由就是Request URL錯誤了,這是個簡單的排錯思路。而在Request-payload中則能夠看到調用服務或獲取資源時前端向後端發送的數據以及數據格式,這點其實挺重要的,在先後端聯調中使用較多,方便前端查看是否有向後端傳輸正確格式的數據。

Preview:這其中就是返回數據的一個預覽狀況,它和Response的不一樣之處就在於,返回的數據若是是個json串,在Preview中會被格式化成爲前端規範的層疊嵌套的json格式方便瀏覽查看,而在Response中就是個一長串的字符串,不方便瀏覽。下面經過圖片能夠看出二者的區別。

Cookies:若是選擇的資源在Request和Response過程當中存在Cookies信息,則能夠在其中查看具體的cookie消息,暫時使用的較少,沒有什麼比較多的理解。

Timing:其實就是5.1小節的資源加載時間分佈。

6. 當前頁面請求信息概覽

這一行周其實就籠統的歸納了當前頁面總共發起了多少個請求,交換了多大的數據量,完成事件,以及觸發DOMContentLoaded的時間和觸發Load事件的時間。

相關文章
相關標籤/搜索