前面的話
Chrome 開發者工具是一套內置於Google Chrome中的Web開發和調試工具，可用來對網站進行迭代、調試和分析。使用 Network 面板測量網站網絡性能。本文將詳細介紹chrome開發者工具中網絡面板network的使用
概述
【打開方式】
打開方式有以下三種
1、在Chrome菜單中選擇 更多工具 > 開發者工具
2、在頁面元素上右鍵點擊，選擇 “檢查”
3、使用 快捷鍵 Ctrl+Shift+I (Windows) 或 Cmd+Opt+I (Mac)
【作用】
Network 面板記錄頁面上每個網絡操作的相關信息，包括詳細的耗時數據、HTTP 請求與響應標頭和 Cookie，等等
它有如下作用
1、使用 Network 面板記錄和分析網絡活動
2、整體或單獨查看資源的加載信息
3、過濾和排序資源的顯示方式
4、保存、復制和清除網絡記錄
5、根據需求自定義 Network 面板
【組成】
Network 面板由五個窗格組成：
1、Controls。使用這些選項可以控制 Network 面板的外觀和功能
2、Filters。 使用這些選項可以控制在 Requests Table 中顯示哪些資源。提示：按住 Cmd (Mac) 或 Ctrl(Windows/Linux) 並點擊過濾器可以同時選擇多個過濾器
3、Overview。 此圖表顯示了資源檢索時間的時間線。如果看到多條豎線堆疊在一起，則說明這些資源被同時檢索
4、Requests Table。 此表格列出了檢索的每一個資源。 默認情況下，此表格按時間順序排序，最早的資源在頂部。點擊資源的名稱可以顯示更多信息。 提示：右鍵點擊 Timeline 以外的任何一個表格標題可以添加或移除信息列
5、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 面板上的兩個地方顯示：
1、Overview 窗格中的藍色豎線表示事件；
2、在 Summary 窗格中，可以看到事件的確切時間
頁面完全加載時將觸發 load。此事件顯示在三個地方：
1、Overview 窗格中的紅色豎線表示事件
2、Requests Table 中的紅色豎線也表示事件
3、在 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 提供了與接收各個資源的時間有關的大量詳細信息。請求生命周期的主要階段包括：
1、重定向
立即開始 startTime。
如果正在發生重定向，redirectStart 也會開始。
如果重定向在本階段末發生，將采集 redirectEnd。
2、應用緩存
如果是應用緩存在實現請求，將采集 fetchStart 時間。
3、DNS
domainLookupStart 時間在 DNS 請求開始時采集。
domainLookupEnd 時間在 DNS 請求結束時采集。
4、TCP
connectStart 在初始連接到服務器時采集。
如果正在使用 TLS 或 SSL，secureConnectionStart 將在握手（確保連接安全）開始時開始。
connectEnd 將在到服務器的連接完成時采集。
5、請求
requestStart 會在對某個資源的請求被發送到服務器后立即采集。
6、響應
responseStart 是服務器初始響應請求的時間。
responseEnd 是請求結束並且數據完成檢索的時間。
Network 面板中有給定條目完整的耗時信息
【queueing】
如果某個請求正在排隊，則指示：
1、請求已被渲染引擎推遲，因為該請求的優先級被視為低於關鍵資源（例如腳本/樣式）的優先級。 圖像經常發生這種情況
2、請求已被暫停，以等待將要釋放的不可用 TCP 套接字
3、請求已被暫停，因為在 HTTP 1 上，瀏覽器僅允許每個源擁有六個 TCP 連接
4、生成磁盤緩存條目所用的時間（通常非常迅速）
【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 毫秒以下
主要有以下兩個原因
1、客戶端與服務器之間的網絡條件較差
2、服務器應用的響應慢
【content Download時間過長】
如果Content Download 階段花費了大量時間，則提高服務器響應或串聯不會有任何幫助。首要的解決辦法是減少發送的字節數