概覽

網頁使用體驗和網路有著非常大的關係，而 Network 面板就是協助開發者分析網路問題的工具。本篇文章將會說明如何以 Network 面板來觀察各種資訊，以及關於請求的的重要觀念解析。

Network Log Detail

在 Network log 列表中點擊任意一列 Request 會從右側展開該 Request 的詳細資訊面板，且根據 Request 的內容會有不同的分頁。

Headers

General 包含了 Request 的基本資訊如 URL、Request method、Status code、Remote address 等等。

下方則有 Response Headers、Request Headers，預設 Headers 會以字母順序列出，點擊 Headers 旁的 view source 可以看到原始的 Headers。

Headers Order

注意如果有多個相同的 Header 欄位就須注意順序，例如 Server 收到多個 Accept Header 時，由於 Accept 的格式就是逗點分隔的多值，解析時會把 Accept 的值以逗點串接起來，此時順序就會影響結果，甚至不同環境也可能解析出不同的結果。

Accept: text/html
Accept: application/xhtml+xml, application/xml

Request Payload

依據 Request 夾帶的資料還可能會有更多資訊，預設會以 key: value 格式列出，按下 view source 可以看到原始資料：

• Query String – Query String Parameters
• Request Payload – application/x-www-form-urlencoded、application/json
• Form Data – multipart/form-data

Provisional Headers

Request 失敗或 Response 是來自 Cache 時可能會看到以下警告，該列表就會顯示很少資訊：

Response

此分頁可以看到原始的 Response 內容，也因為是原始內容，除了文字以外就沒辦法顯示，如果是文字可以按下左下角的 {} 來根據檔案類型自動排版文字內容。

Preview

和 Response 一樣是用來顯示 Response 的內容，不過 Preview 會自動依據檔案類型決定顯示的方式：

• JSON – JavaScript 物件
• 圖片 - 顯示圖片
• HTML - Render 為頁面
• 字體 - 顯示所有文字

Initiator

顯示 Request 的依賴關係以及發出 Request 的原因。

Request initiator chain

會顯示完整的依賴關係，可以從樹狀結構中看出：

• 該 Request 依賴於哪些 Request
• 哪些 Request 依賴於該 Request

以此圖來說，downloadjs@1.4.7 這個 Request 是來自 bundle.js（Fetch），而 bundle.js 則是來自 pdf-editor.now.sh（起始的 HTML）。

downloadjs@1.4.7 本身則因為轉址導向 download.js。

按下 Shift 再 Hover Reuqest 可以看到該 Request 依賴的 Request 變為綠底，而依賴於該 Reuqest 的 Request 則變為紅底。

因為預設 Request 是以發起的時間排序，因此綠色一定會在上方，紅色出現在下方，很容易觀察。

Request call stack

如果是由 JavaScript 發起的 XHR/Fetch Request，就會顯示 Call stack，代表 Function 由下而上的執行並在頂層 Function 發出 Request。

Timing

發起 Request 時，首先要經過 DNS lookup、TCP handshake、SSL negotiation 等等階段才能建立連線開始下載內容，Timing 分頁會顯示各個階段所花費的時間：

排隊（Queuing）

瀏覽器在以下情況，Request 不能直接開始，需要先排隊：

• 有更高優先（Priority）的 Request
• 以 HTTP/1.0、HTTP/1.1 連線但該 Domain 已經有六個 Request 正在進行
• 其他瀏覽器的準備如分配快取空間

開始建立連線

第一個 Stalled 的原因 Queuing 幾乎相同，可以想像為買東西的時候，就算輪到自己了，店員可能會說：「稍等我一下哦。」不能馬上開始結帳。

• Stalled
• DNS Lookup – 利用 DNS Server 取得 IP 地址
• Initial connection – 包含 TCP handshake 和 SSL negotiating

送出 Request

• Request sent – 處理「送出 Request」所用的時間
• Waiting (TTFB) – 送出 Request 到開始下載的時間
• Content Download – 下載時間

分析

依據卡住較久的階段不同，有不同的解決方式，例如 Queuing、Stalled 過長可能需要 HTTP2 或是 Domain sharding，開始建立連線階段過久需要 Preconnect，Waiting 和 Server 效能有關，Content download 則須考慮內容大小等等。

Messages

展開 WebSocket 的 Request 可以看到即時的訊息、長度和時間，上傳的訊息會有綠色背景。

Cookies

如果 Request 有帶 Cookie 或是 Response 有 Set-Cookie Header 就會出現 Cookies 分頁，可以查看每個 Cookie 的屬性，預設不會顯示被阻擋的 Cookie，開啟 show filtered out request cookies 才能看到，可以 Hover 到訊息圖示上看看為什麼無法傳送 Cookie。

Cookie 的 Path 屬性和 Request 的 URL 衝突了。

右鍵選單

Request 的右鍵選單中有 Copy 選單，裡面有幾個好用的選項：

• Copy as fetch – 複製 Request，另外還有 cURL 等等，用來修改 Request 重發或是爬蟲都很方便。
• Copy response – 複製 Response 內容。

Network log 欄位

預設 Network log 有七個欄位：Name、Status、Type、Initiator、Size、Time、Waterfall 這幾個欄位，在表頭上按右鍵可以新增更多：

除了這些以外，下方的 Response Headers 選單還可以加入自訂的 Header 欄位：

以下特別提幾個比較特別或重要的欄位：

Priority

每一種 Request 的優先程度都不同，瀏覽器也會有不同的 Request 行為，例如會造成 Render blocking 的 CSS 有最高優先度，沒在視野內的圖片優先度較低，Prefetch 的優先程度最低，只有 Network idle 的時候才會開始 Request 等等。

關於 Chrome 如何處理優先程度可以參考 Chrome Resource Priorities and Scheduling

Connection ID

建立 TCP 連線後瀏覽器會自動保留連線來提升 Request 效能，打開 Connection ID 欄之後同樣數字的 Request 只要完成建立連線階段，後續都不須重須建立連線。

只有第一個 80709 和 80736 有橘紫色的建立連線階段

Waterfall

預設 Network log 會以 Request 起始時間排序，在剛才提到的右鍵選單中可以展開 Waterfall 看到額外的排序選項：

• Start Time – 開始時間（預設）
• Response Time – 開始下載的時間
• End Time – 結束時間
• Total Duration – 開始到結束的時間
• Latency – 開始到開始下載的時間 (TTFB)

TTFB 是 Web Vitals 的一員，之後會有一篇為主題以 Web Vitals 為主題的文章。

小結

本篇文章介紹了如何透過 Network log 來分析 Network 相關的效能問題，善用 Network 面板將網路問題限縮後才能用相對的方法解決。