使用chrome開發者工具中的network面板測量網站網絡性能

前面的話

　　Chrome 開發者工具是一套內置於Google Chrome中的Web開發和調試工具，可用來對網站進行迭代、調試和分析。使用 Network 面板測量網站網絡性能。本文將詳細介紹chrome開發者工具中網絡面板network的使用

 

概述

【打開方式】

　　打開方式有如下三種

　　一、在Chrome菜單中選擇 更多工具 > 開發者工具

　　二、在頁面元素上右鍵點擊，選擇 「檢查」

　　三、使用 快捷鍵 Ctrl+Shift+I (Windows) 或 Cmd+Opt+I (Mac)

 【做用】

　　Network 面板記錄頁面上每一個網絡操做的相關信息，包括詳細的耗時數據、HTTP 請求與響應標頭和 Cookie，等等

　　它有以下做用

　　一、使用 Network 面板記錄和分析網絡活動

　　二、總體或單獨查看資源的加載信息

　　三、過濾和排序資源的顯示方式

　　四、保存、複製和清除網絡記錄

　　五、根據需求自定義 Network 面板

【組成】

　　Network 面板由五個窗格組成：

　　一、Controls。使用這些選項能夠控制 Network 面板的外觀和功能

　　二、Filters。 使用這些選項能夠控制在 Requests Table 中顯示哪些資源。提示：按住 Cmd (Mac) 或 Ctrl(Windows/Linux) 並點擊過濾器能夠同時選擇多個過濾器

　　三、Overview。 此圖表顯示了資源檢索時間的時間線。若是看到多條豎線堆疊在一塊兒，則說明這些資源被同時檢索

　　四、Requests Table。 此表格列出了檢索的每個資源。 默認狀況下，此表格按時間順序排序，最先的資源在頂部。點擊資源的名稱能夠顯示更多信息。 提示：右鍵點擊 Timeline 之外的任何一個表格標題能夠添加或移除信息列

　　五、Summary。 此窗格列出了請求總數、傳輸的數據量和加載時間

　　默認狀況下，Requests Table 會顯示如下列。能夠在表頭欄上點擊右鍵來添加和移除列

Name。資源的名稱。
Status。HTTP 狀態代碼。
Type。已請求資源的 MIME 類型。
Initiator。發起請求的對象或進程。值爲如下選項之一：
    Parser。Chrome 的 HTML 解析器發起請求。
    Redirect。HTTP 重定向發起請求。
    Script。腳本發起請求。
    Other。某些其餘進程或操做發起請求，例如用戶經過連接或者在地址欄中輸入網址導航到頁面。
Size。響應標頭（一般爲數百字節）加響應正文（由服務器提供）的組合大小。
Time。從請求開始至在響應中接收到最終字節的總持續時間。
Timeline。Timeline 列能夠顯示全部網絡請求的可視瀑布。 點擊此列的標題能夠顯示一個包含更多排序字段的菜單。

【記錄】

　　在 Network 面板打開時，DevTools 在默認狀況下會記錄全部網絡活動。 要記錄活動，只需在面板打開時從新加載頁面，或者等待當前加載頁面上的網絡活動

　　能夠經過 record 按鈕指示 DevTools 是否記錄。 顯示紅色代表 DevTools 正在記錄。 顯示灰色 代表 DevTools 未在記錄。 點擊此按鈕能夠開始或中止記錄，也能夠按鍵盤快捷鍵 Cmd/Ctrl+e

【幻燈片】

　　Network 面板能夠在頁面加載期間捕捉屏幕截圖。此功能稱爲幻燈片。點擊攝影機圖標能夠啓用幻燈片。圖標爲灰色時，幻燈片處於停用狀態。若是圖標爲藍色，則說明已啓用。從新加載頁面能夠捕捉屏幕截圖。屏幕截圖顯示在概覽上方

　　將鼠標懸停在一個屏幕截圖上時，Timeline 將顯示一條黃色豎線，指示幀的捕捉時間

　　雙擊屏幕截圖可查看放大版本。在屏幕截圖處於放大狀態時，使用鍵盤的向左和向右箭頭能夠在屏幕截圖之間導航

 

事件

　　Network 面板突出顯示兩種事件：DOMContentLoaded 和 load。 解析頁面的初始標記時會觸發 DOMContentLoaded。 此事件將在 Network 面板上的兩個地方顯示：

　　一、Overview 窗格中的藍色豎線表示事件；

　　二、在 Summary 窗格中，能夠看到事件的確切時間

　　頁面徹底加載時將觸發 load。此事件顯示在三個地方：

　　一、Overview 窗格中的紅色豎線表示事件

　　二、Requests Table 中的紅色豎線也表示事件

　　三、在 Summary 窗格中，能夠看到事件的確切時間

 

詳細信息

　　點擊資源名稱（位於 Requests Table 的 Name 列下）能夠查看與該資源有關的更多信息

　　可用標籤會因所選擇資源類型的不一樣而不一樣，但下面四個標籤最多見：

Headers。與資源關聯的 HTTP 標頭。
Preview。JSON、圖像和文本資源的預覽。
Response。HTTP 響應數據（若是存在）。
Timing。資源請求生命週期的精細分解。

【網絡耗時】

　　點擊 Timing 標籤能夠查看單個資源請求生命週期的精細分解。

　　生命週期按照如下類別顯示花費的時間：

Queuing
Stalled
若是適用：DNS lookup、initial connection、SSL handshake
Request sent
Waiting (TTFB)
Content Download

　　將鼠標懸停到 Timeline 圖表內的資源上時，您也能夠看到相同的信息

【查看HTTP標頭】

　　點擊 Headers 能夠顯示該資源的標頭。

　　Headers 標籤能夠顯示資源的請求網址、HTTP 方法以及響應狀態代碼。 此外，該標籤還會列出 HTTP 響應和請求標頭、它們的值以及任何查詢字符串參數

　　點擊每一部分旁邊的 view source 或 view parsed 連接，您可以以源格式或者解析格式查看響應標頭、請求標頭或者查詢字符串參數

【預覽資源】

　　點擊 Preview 標籤能夠查看該資源的預覽。Preview 標籤可能顯示一些有用的信息，也可能不顯示，具體取決於所選擇資源的類型

【查看 HTTP 響應內容】

　　點擊 Response 標籤能夠查看資源未格式化的 HTTP 響應內容。 Preview 標籤可能包含一些有用的信息，也可能不包含，具體取決於所選擇資源的類型

 

生命週期

　　全部網絡請求都被視爲資源。經過網絡對它們進行檢索時，資源具備不一樣生命週期，以 Resource Timing 表示。Resource Timing API 提供了與接收各個資源的時間有關的大量詳細信息。請求生命週期的主要階段包括：

一、重定向
　　當即開始 startTime。
　　若是正在發生重定向，redirectStart 也會開始。
　　若是重定向在本階段末發生，將採集 redirectEnd。
二、應用緩存
　　若是是應用緩存在實現請求，將採集 fetchStart 時間。
三、DNS
　　domainLookupStart 時間在 DNS 請求開始時採集。
　　domainLookupEnd 時間在 DNS 請求結束時採集。
四、TCP
　　connectStart 在初始鏈接到服務器時採集。
　　若是正在使用 TLS 或 SSL，secureConnectionStart 將在握手（確保鏈接安全）開始時開始。
　　connectEnd 將在到服務器的鏈接完成時採集。
五、請求
　　requestStart 會在對某個資源的請求被髮送到服務器後當即採集。
六、響應
　　responseStart 是服務器初始響應請求的時間。
　　responseEnd 是請求結束而且數據完成檢索的時間。

　　Network 面板中有給定條目完整的耗時信息

【queueing】

　　若是某個請求正在排隊，則指示：

　　一、請求已被渲染引擎推遲，由於該請求的優先級被視爲低於關鍵資源（例如腳本/樣式）的優先級。 圖像常常發生這種狀況

　　二、請求已被暫停，以等待將要釋放的不可用 TCP 套接字

　　三、請求已被暫停，由於在 HTTP 1 上，瀏覽器僅容許每一個源擁有六個 TCP 鏈接

　　四、生成磁盤緩存條目所用的時間（一般很是迅速）

【stalled】

　　請求等待發送所用的時間。 能夠是等待 Queueing 中介紹的任何一個緣由。 此外，此時間包含代理協商所用的任什麼時候間

【proxy negotiaion】

　　與代理服務器鏈接協商所用的時間

【DNS lookup】

　　執行 DNS 查詢所用的時間。 頁面上的每個新域都須要完整的往返才能執行 DNS 查詢

【Initial Connection】

　　創建鏈接所用的時間，包括 TCP 握手/重試和協商 SSL 的時間

【SSL】

　　完成 SSL 握手所用的時間

【Request sent】

　　發出網絡請求所用的時間。 一般不到一毫秒

【TTFB】

　　等待初始響應所用的時間，也稱爲至第一字節的時間。 此時間將捕捉到服務器往返的延遲時間，以及等待服務器傳送響應所用的時間

【content Download】

　　接收響應數據所用的時間

 

診斷問題

【queueing時間過長】

　　最多見問題是一系列已被加入隊列或已被中止的條目。這代表正在從單個網域檢索太多的資源。在 HTTP 1.0/1.1 鏈接上，Chrome 會將每一個主機強制設置爲最多六個 TCP 鏈接。若是一次請求十二個條目，前六個將開始，然後六個將被加入隊列。最初的一半完成後，隊列中的第一個條目將開始其請求流程

　　要爲傳統的 HTTP 1 流量解決此問題，須要實現域分片。也就是在應用上設置多個子域，以便提供資源。而後，在子域之間平均分配正在提供的資源

　　HTTP 1 鏈接的修復結果不會應用到 HTTP 2 鏈接上。事實上，前者的結果會影響後者。 若是部署了 HTTP 2，不要對資源進行域分片，由於它與 HTTP 2 的操做方式相反。在 HTTP 2 中，到服務器的單個 TCP 鏈接做爲多路複用鏈接。這消除了 HTTP 1 中的六個鏈接限制，而且能夠經過單個鏈接同時傳輸多個資源

【TTFB時間過長】

　　等待時間長表示至第一字節的時間 (TTFB) 漫長。建議將此值控制在 200 毫秒如下

　　主要有如下兩個緣由

　　一、客戶端與服務器之間的網絡條件較差

　　二、服務器應用的響應慢

【content Download時間過長】

　　若是Content Download 階段花費了大量時間，則提升服務器響應或串聯不會有任何幫助。首要的解決辦法是減小發送的字節數