timing
1.1各个字段都代表含义
1.2 字段含义
1、navigationStart
为紧接着在相同的浏览环境下卸载前一个文档结束之时的 Unix毫秒时间戳。
如果没有上一个文档，则它的值相当于 fetchStart。
可以直接理解为页面加载开始的地方。
2、unloadEventStart
为 unload (en-US) 事件被触发之时的 Unix毫秒时间戳。
如果没有上一个文档，或者上一个文档或需要重定向的页面之一不同源，则该值返回 0。
可以理解为不同域，则为0，即加载新页面，就是0，可以被忽略
3、unloadEventEnd
为unload (en-US) 事件处理程序结束之时的 Unix毫秒时间戳。如果没有上一个的文档，
或者上一个文档或需要被跳转的页面的其中之一不同源，则该值返回 0。
不同域，则为0，即加载新页面，就是0，可以被忽略
4、redirectStart
为第一个HTTP的重定向开始的时刻的 Unix毫秒时间戳。
如果重定向没有发生，或者其中一个重定向非同源，则该值返回 0。
不同域，则为0，即加载新页面，就是0，可以被忽略
5、redirectEnd
为最后一次的HTTP重定向被完成且HTTP响应的最后一个字节被接收之时的 Unix毫秒时间戳。
如果没有发生重定向，或者其中一个重定向不同源，则该值返回 0。
不同域，则为0，即加载新页面，就是0，可以被忽略
6、fetchStart
为浏览器已经准备好去使用HTTP请求抓取文档之时的 Unix毫秒时间戳。这一时刻在检查应用的缓存之前。
在没有重定向和页面卸载的情况下，和navigationStart的时间戳一样
7、domainLookupStart
为域名开始解析之时的 Unix毫秒时间戳。如果一个持久连接被使用，
或者该信息已经被本地资源或者缓存存储，则该值等同于 fetchStart。
DNS已缓存，则为0，可忽略
8、domainLookupEnd
为解析域名结束时的 Unix毫秒时间戳。如果一个持久连接被使用，
或者该信息已经被本地资源或者缓存存储，则该值等同于 fetchStart。
DNS已缓存，则为0，可忽略
9、connectStart
代表TCP开始建立连接时间节点。如果浏览器没有进行TCP连接（比如使用持久化连接webscoket），
则两者都等于domainLookupEnd；
10、connectEnd
代表TCP连接完成的时间节点。如果浏览器没有进行TCP连接（比如使用持久化连接webscoket），
则两者都等于domainLookupEnd；
11、secureConnectionStart
如果页面使用HTTPS，它的值是安全连接握手之前的时刻。如果该属性不可用，则返回undefined。
如果该属性可用，但没有使用HTTPS，则返回0
12、requestStart
为浏览器发送从服务器或者缓存获取实际文档的请求之时的 Unix毫秒时间戳。
如果传输层在请求开始之后发生错误并且连接被重新打开，
则该属性将会被设定为新的请求的相应的值 。
13、responseStart
为浏览器从服务器、缓存或者本地资源接收到响应的第一个字节之时的 Unix毫秒时间戳。
14、responseEnd
为浏览器从服务器、缓存或者本地资源接收响应的最后一个字节或者连接被关闭之时的 Unix毫秒时间戳。
15、domLoading
为解析器开始工作，即 Document.readyState 改变为 'loading'
并且 readystatechange 事件被触发之时的 Unix毫秒时间戳。
16、domInteractive
为在主文档的解析器结束工作，即 Document.readyState 改变为 'interactive'
并且相当于 readystatechange 事件被触发之时的 Unix毫秒时间戳。
17、domContentLoadedEventStart
代表DOMContentLoaded事件触发的时间节点
18、domContentLoadedEventEnd
代表DOMContentLoaded事件结束的时间节点
19、domComplete
为主文档的解析器结束工作，Document.readyState 变为 'complete'
相当于 readystatechange 事件被触发时的 Unix毫秒时间戳。
20、loadEventStart
为 load 事件被现在的文档触发之时的 Unix时间戳。如果这个事件没有被触发，则他返回 0。
21、loadEventEnd
为 load 事件处理程序被终止，加载事件已经完成之时的 Unix毫秒时间戳。
如果这个事件没有被触发，或者没能完成，则该值将会返回 0。
network
这里表示的是这个html资源从开始加载 =>
加入队列(Queued at 0) => 排队等待(Queueing) => 暂停(Stalled) => SSL建立 =>
发送请求(Request Sent) => Waiting(TTFB - Time to First Byte) => Content Download
1、Queued at 0 和 Queueing 是资源加载队列排队的时间，
这个跟浏览器当前处理事务的数量有关，不过一般比较小。
2、Stalled 表示搁置时间，即这个时候即使开始处理他这个资源了，
如果突然有其他事务要处理，那么就得耽搁他一下。
3、SSL（安全套接层协议层），这个是在https的情况下才有，
是在Web服务器和Web客户机之间建立经过身份验证和加密会话的Web协议。
4、Request Sent 即开始发送请求的时候
5、Waiting(TTFB) 首字节等待时间，即可以理解为Request Sent 到 收到第一个字节 所需时间。
6、Content Download 即内容下载时间，内容的大小和当时的网速会影响这个时间。
理解
DOMContentLoaded
当初始的 HTML 文档被完全加载和解析完成之后，
**DOMContentLoaded **事件被触发，而无需等待样式表、图像和子框架的完全加载。
DOMContentLoaded 事件的时间（463 毫秒），这也对应于蓝色垂直线。
HTML 下载结束与蓝色垂直线 (DOMContentLoaded) 之间的差距是浏览器构建 DOM 树所需的时间
，我们可以构建渲染树甚至绘制页面，而无需等待页面上的每个资源
当我们谈论关键渲染路径时，我们通常是在谈论 HTML 标记、CSS 和 JavaScript。
图像不会阻塞页面的初始渲染
script
如果包含一个解析器阻塞 JavaScript 文件
所以在domContentLoaded下载和解析 CSS 文件之前，该事件会被阻塞
因为 JavaScript 可能会查询 CSSOM，
所以我们必须阻塞 CSS 文件，直到它下载后才能执行 JavaScript。
我们可以添加“async”关键字来解除解析器阻塞
onload
onload事件标记了页面所需的所有资源都已下载和处理的点；
此时，加载微调器可以在浏览器中停止旋转（瀑布中的红色垂直线）
分析关键渲染路径性能
分析解读
通过上面的栗子可以容易想到TTFB 是 反映服务端响应速度的重要指标，
对服务器来说，TTFB 时间越短，就说明服务器响应越快。
影响TTFB时间长短的主要时间可能有：
1、浏览器端跟服务端之间的网络不好，如你在中国，
服务器在非洲，那么你 "发出的问题" 要经过N多个网络节点才能到达非洲，
这个时间肯定就长。（网络不好）
服务端收到浏览器端请求后，如果先读数据库，然后又同步处理大量数据，
2、然后再把数据传给客户端，那么这个时间肯定也会长。（耗时逻辑）
一般服务端渲染的页面，其资源的TTFB会很长
performance.getEntries()
这个是返回浏览器加载一个网页所发出的静态资源（也包含webworker）的性能记录列表
{
name: '资源的名字',
entryType: '资源的类型，如resource 表示是静态资源，paint 表示是渲染事件',
startTime: '资源请求的开始时间(注意不是时间戳，而是相对于页面加载起始的偏移时间)',
duration: '资源请求的耗时'(资源加载开始 => 资源加载结束)
}
performanceResourceTiming 静态资源类型
performancePaintTiming 渲染类型
重定向资源类型（A）对应的注释：
这一种是重定向资源（设为A），类似于页面加载，所以有load事件
{
// TCP链接开始
connectEnd: 29.009999999288993,
// TCP链接完成
connectStart: 10.269999999763968,
// 解编码后大小
decodedBodySize: 320036,
// dom完成（包括解析）
domComplete: 1022.3799999994299,
// 对应页面的DomContentLoaded事件，DomContentLoaded结束时间
domContentLoadedEventEnd: 705.3900000000795,
// DomContentLoaded开始时间
domContentLoadedEventStart: 692.4199999994016,
// dom可交互时间
domInteractive: 519.4899999996778,
// DNS解析完成
domainLookupEnd: 10.269999999763968,
// DNS解析开始
domainLookupStart: 5.699999999706051,
// 排期
duration: 1030.9849999994185,
// 编码后大小
encodedBodySize: 78155,
// 资源类型 导航重定向
entryType: "navigation",
// 开始请求的事件
fetchStart: 0.534999999217689,
// 具体的触发者的类型，如 navigation link script 等
initiatorType: "navigation",
// 对应页面的load事件完成时间
loadEventEnd: 1030.9849999994185,
// 对应页面的load事件开始时间
loadEventStart: 1022.4199999993289,
// 请求资源名字
name: "https://www.baidu.com/",
nextHopProtocol: "http/1.1",
// 重定向次数
redirectCount: 0,
// 重定向完成
redirectEnd: 0,
// 重定向开始
redirectStart: 0,
// 请求开始
requestStart: 29.144999999516585,
// 数据响应完成，即数据下载完成
responseEnd: 253.8349999995262,
// 数据响应开始，即数据刚开始下载
responseStart: 221.83999999924708,
// SSL时间
secureConnectionStart: 16.709999999875436,
serverTiming: [],
// 资源开始触发时间
startTime: 0,
// 传输大小
transferSize: 78846,
// 加载类型，目前看是navigation下才有
type: "reload",
// 上一个页面卸载完成时间
unloadEventEnd: 251.25499999921885,
// 上一个页面卸载开始时间
unloadEventStart: 250.11999999969703,
workerStart: 0,
}
时序故障阶段解释
排队。浏览器在以下情况下将请求排队：
有更高优先级的请求。
已经为此源打开了六个 TCP 连接，这是限制。仅适用于 HTTP/1.0 和 HTTP/1.1。
浏览器在磁盘缓存中短暂分配空间
停滞不前。请求可能因排队中描述的任何原因而停止。
DNS 查找。浏览器正在解析请求的 IP 地址。
初始连接。浏览器正在建立连接，包括 TCP 握手/重试和协商 SSL。
代理协商。浏览器正在与代理服务器协商请求。
请求发送。正在发送请求。
服务工作者准备。浏览器正在启动 service worker。
对 ServiceWorker 的请求。请求正在发送给服务人员。
等待（TTFB）。浏览器正在等待响应的第一个字节。TTFB 代表第一个字节的时间。
此时间包括 1 次往返延迟和服务器准备响应所用的时间。
内容下载。浏览器直接从网络或服务工作者接收响应。该值是读取响应正文所花费的总时间。
大于预期值可能表示网络速度较慢，或者浏览器正忙于执行其他工作，这会延迟读取响应。
接收推送。浏览器正在通过 HTTP/2 服务器推送接收此响应的数据。
阅读推送。浏览器正在读取之前收到的本地数据。
再看看performance对应的network
我仔细计算了一下
0对应的是TTFB以前的时间（0 - 29ms），耗时29 （18.75 + 4.57 + 2.88 + 2.26 = 28.46）
1对应的是TTFB（29 - 221.93），耗时192.93
2对应的是Content Download（221.93 - 253.83），耗时31.9
经过上面的例子，我们可以得出（以下代指他们的耗时）：
DNS Lookup = domainLookupEnd - domainLookupStart
Initial connection = connectEnd - connectStart
SSL = connectEnd - secureConnectionStart
TTFB = responseEnd - responseStart
发生的顺序 DNS Lookup => Initial connection(SSL包含在connection内) => TTFB
875
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
