Chrome的Waterfall

参考：

1、https://developers.google.com/web/tools/chrome-devtools/network-performance/reference#timing

2、http://www.mamicode.com/info-detail-1015625.html

浏览器根据html中外连资源出现的顺序，依次放入队列（Queue）,然后根据优先级确定向服务器获取资源的顺序。同优先级的资源根据html中出现的先后顺序来向服务器获取资源

• Queueing. 出现下面的情况时，浏览器会把当前请求放入队列中进行排队
  • 有更高优先级的请求时.
  • 和目标服务器已经建立了6个TCP连接（最多6个，适用于HTTP/1.0和HTTP/1.1）
  • 浏览器正在硬盘缓存上简单的分配空间
• Stalled. 请求会因为上面的任一个原因而阻塞
• DNS Lookup. 浏览器起正在解析IP地址.
• Proxy negotiation. The browser is negotiating the request with a proxy server.
• Request sent. The request is being sent.
• ServiceWorker Preparation. The browser is starting up the service worker.
• Request to ServiceWorker. The request is being sent to the service worker.
• Waiting (TTFB). 浏览器等待响应第一个字节到达的时间. 包含来回的延迟时间和服务器准备响应的时间.
• Content Download. The browser is receiving the response.
• Receiving Push. The browser is receiving data for this response via HTTP/2 Server Push.
• Reading Push. The browser is reading the local data previously received.

• DNS Lookup - 在浏览器和服务器进行通信之前, 必须经过DNS查询, 将域名转换成IP地址. 在这个阶段, 你可以处理的东西很少. 但幸运的是, 并非所有的请求都需要经过这一阶段.

• Initial Connection - 在浏览器发送请求之前, 必须建立TCP连接. 这个过程仅仅发生在瀑布图中的开头几行, 否则这就是个性能问题(后边细说).

• SSL/TLS Negotiation - 如果你的页面是通过SSL/TLS这类安全协议加载资源, 这段时间就是浏览器建立安全连接的过程. 目前Google将HTTPS作为其 搜索排名因素 之一, SSL/TLS 协商的使用变得越来越普遍了.

• Time To First Byte (TTFB) - TTFB 是浏览器请求发送到服务器的时间+服务器处理请求时间+响应报文的第一字节到达浏览器的时间. 我们用这个指标来判断你的web服务器是否性能不够, 或者说你是否需要使用CDN.

• Downloading - 这是浏览器用来下载资源所用的时间. 这段时间越长, 说明资源越大. 理想情况下, 你可以通过控制资源的大小来控制这段时间的长度.

根据瀑布图进行性能优化

那么我们如何是一个web页面加载的更快并且创造更好的用户体验呢? 瀑布图提供是三个直观的玩意儿来协助我们达成这一目标:

1. 首先, 减少所有资源的加载时间. 亦即减小瀑布图的宽度. 瀑布图越窄, 网站的访问速度越快.

2. 其次, 减少请求数量 也就是降低瀑布图的高度. 瀑布图越矮越好.

3. 最后, 通过优化资源请求顺序来加快渲染时间. 从图上看, 就是将绿色的"开始渲染"线向左移. 这条线向左移动的越远越好.

如图所示，select2_metro.css在位置上要比avatar1_small.png和index.js靠后，但是优先级确实最高(Higthest-->High-->Medium-->Low),所以这个下载顺序是：select2_metro.css-->index.js-->avatar1_small.png

Connection ID:可以看到总共有6个值--166718、166774、166775、166776、166777、166778，因为浏览器并发数limit是6；如果两个url相同，就表示两个资源的下载共用的同一个tcp长连接