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页面加载的更快并且创造更好的用户体验呢? 瀑布图提供是三个直观的玩意儿来协助我们达成这一目标:
-
首先, 减少所有资源的加载时间. 亦即减小瀑布图的宽度. 瀑布图越窄, 网站的访问速度越快.
-
其次, 减少请求数量 也就是降低瀑布图的高度. 瀑布图越矮越好.
-
最后, 通过优化资源请求顺序来加快渲染时间. 从图上看, 就是将绿色的"开始渲染"线向左移. 这条线向左移动的越远越好.
如图所示，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长连接
