Navigation Timing是一套主要用于衡量文档加载性能的JavaScript API，。
Navigation Timing 2目前还是工作草案，它是做为第一版的一个补充，但是新增了如下内容：
在第1版中，我们可以通过window.performance.timing获取PerformanceTiming对象。
在第2版中，我们也可以通过Performance Timeline提供的API访问。
浏览器完成卸载前一个文档的时间(也就是准备加载新页面的那个起始时间)。如果没有前一个文档，那么就返回fetchStart的值。
如果前一个文档，和当前文档同源，返回前一个文档发生unload事件前的时间。如果没有前一个文档，或不同源，则返回0。
如果前一个文档和当前文档同源，返回前一个文档发生unload事件的时间；如果没有前一个文档，或不同源，则返回0。
如果发生了HTTP重定向，或者类似的事情，并且从导航开始中间的每次重定向，并不都和当前文档同域的话，则返回0。
如果发生了HTTP重定向，或者类似的事情，并且，从导航开始，中间的每次重定向都和当前文档同域的话，就返回开始重定向的fetchStart的值。其他情况则返回0。
如果发生了HTTP重定向，或者类似的事情。并且，从导航开始，中间的每次重定向都和当前文档同域的话，就返回最后一次重定向，接收到最后一个字节数据后的那个时间。其他情况则返回0。
如果一个新的资源(这里是指当前文档)获取被发起，或类似的事情发生，则fetchStart必须返回用户代理开始检查其相关缓存的那个时间，其他情况则返回开始获取该资源的时间。
返回用户代理对当前文档所属域进行DNS查询开始的时间。如果此请求没有DNS查询过程，如长连接，资源cache，甚至是本地资源等。那么就返回 fetchStart的值。
返回用户代理对结束对当前文档所属域进行DNS查询的时间。如果此请求没有DNS查询过程，如长连接，资源cache，甚至是本地资源等。那么就返回 fetchStart的值。
返回用户代理向服务器请求文档，开始建立连接的那个时间，如果此连接是一个长连接，又或者直接从缓存中获取资源（即没有与服务器建立连接）。则返回domainLookupEnd的值。
返回用户代理向服务器服务器请求文档，建立连接成功后(注意，不是断开连接的时间)的那个时间。如果此连接是一个长连接，又或直接从缓存中获取资源 （即没有与服务器建立连接），则返回domainLookupEnd的值。
可选特性。用户代理如果没有对应的属性，就要把这个设置为undefined。如果有这个属性，并且是HTTPS协议，那么就要返回开始SSL握手的那个时间。如果不是HTTPS， 那么就返回0。
返回从服务器、缓存、本地资源等，开始请求文档的时间。
如果请求中途，连接断开了，并且用户代理进行了重连，并重新请求了资源，那么requestStart就必须为这个新请求所对应的时间。
注意: 此接口并不包含一个表示请求结束的属性，如requestEnd，原因有两点:
返回用户代理从服务器、缓存、本地资源中，接收到第一个字节数据的时间。
返回用户代理接收到最后一个字符的时间，和当前连接被关闭的时间中，最早的那个。同样，文档可能来自服务器、缓存、或本地资源。
此值的读取应该是在我们可以确保真的是Response结束以后，比如
window.onload。因为可能会有chunked输出的情况,那么脚本执行并获取该值时，响应还没有结束，这就会导致获取时间不准确。
返回用户代理把其文档的current document readiness设置为loading的时候。
这是整个过程开始的时间戳，浏览器开始解析 HTML 文档第一批收到的字节 document。另外，current document readiness 其实就是
document。readyStateAPI对应的状态。
返回用户代理把其文档的current document readiness设置为“interactive”的时候。
标记 DOM 准备就绪，即浏览器完成解析并且所有 HTML 和 DOM 构建完毕的时间点
从标准来说，domReady的状态为”interactive”时，意味着文档解析结束了。因为标准中描述DOM树创建结束后第一件事，就是把current document readiness设置为”interactive”。
HTML 5.1 8.2.6中第一步。
返回文档发生DOMContentLoaded事件的时间。
标记 DOM 准备就绪并且没有样式表阻碍 JavaScript 执行的时间点 - 意味着我们可以开始构建呈现树了。
HTML 5.1 8.2.6中第4步。
DOMContentLoad和 DOMInteractive 之间插入了以下两个步骤。
DOMContentLoad事件。需要注意的是这个待运行脚本列表。在不同浏览器中可能会有所不同。大致会包括
document.write写入文档流的脚本，以及defer的脚本。所以从这里我们应该知道defer的脚本的执行是推迟DOMContentLoad事件触发的。很多JavaScript 框架等待此事件发生后，才会开始执行它们自己的逻辑，比如JQuery。因此，浏览器会通过捕获 EventStart 和 EventEnd 时间戳，跟踪执行逻辑所需的时间。
文档的DOMContentLoaded事件的结束时间。
所谓事件结束的时间，是指如果DOMContentLoaded事件被开发者注册了回调事件，那么这个事件的 Event End 时间减去 Event Start 的时间，那么就可以跟踪回调执行逻辑所需的时间。
当然部分浏览器实现可能会有2-3ms的误差。但是这个时间，基本可以忽略不计。类似的情况还有后面的
loadEventStart和loadEventEnd。即window.onload所有回调所消耗的时间。
返回用户代理把其文档的current document readiness设置为“complete”的时候。
标记网页及其所有附属资源都已经准备就绪的时间，顾名思义，所有的处理完成，网页上所有资源（包括图片，Web Fonts等）都已下载完成 - 即加载旋转图标停止旋转。
HTML 5.1 8.2.6中第7步。
文档触发load事件的时间。如果load事件没有触发，那么该接口就返回0。
作为每个网页加载的最后一步，浏览器会触发onLoad事件，以便触发附加的应用逻辑。
文档触发load事件结束后的时间。如果load事件没有触发，那么该接口就返回0。
我们现在已经知道Navigation Timing所提供的API，下面是一些常用的Use Cases:
| 指标 | 指标值 |
|---|---|
| DNS | domainLookupEnd - domainLookupStart |
| TCP | connectEnd - connectStart |
| TTFB | responseStart - navigationStart |
| 页面等待响应的耗费时间 | responseEnd – fetchStart |
| 页面DOM渲染的耗费时间(domReady) | domContentLoadedEventEnd – fetchStart |
| 页面Load完成的耗费时间(onLoad) | loadEventEnd – fetchStart |
