概览
网页使用体验和网路有着非常大的关系，而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收到多个AcceptHeader时，由于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
以此图来说，[email protected]这个Request是来自bundle.js（Fetch），而bundle.js则是来自pdf-editor.now.sh（起始的HTML）。
[email protected]本身则因为转址导向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-CookieHeader就会出现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 面板将网路问题限缩后才能用相对的方法解决。