先看这个图，从上往下看
- Queued at 2.97s 表示当前的这个请求在这个页面加载过程中，加入到请求队列中的时间用了2.97s，按照队列的顺序依次累加，为什么调用接口还需要排队呢？ 因为浏览器对同一时间，同一个Host发起的HTTP1.1并发请求的个数做了限制，不是所有的请求都能发出去，所以需要排队。
上面这个图是各大浏览器对同一个域名能发起的http请求的最大并发数量，所以导致我们Queued at 2.97s等待了2.97s 解决办法：
-
增加浏览器最大并发请求数量，减少排队时间；
-
不同域名调用，静态资源和接口资源放不同服务器域名下；将资源合理分布到多台主机上，可以提高并发数，但是增加并行下载数量也会增大开销，这取决于带宽和CPU速度，过多的并行下载会降低性能；
-
减少延迟/阻塞时间，在服务端减少代理跳转，重定向，在请求中开启 Keep Alive, (临时)关闭SSL，用HTTP代替HTTPS;
-
优化进程管理，代码执行层面的优化，缓存，DB，同异步，接口调用等;
-
started at 2.98s 表示加入到队列之后，实际开始处理的时间，这个和上面Queued at 2.97s不算在总耗时里！
-
Resource Scheduling | DURATION
Queueing | 5.31 ms
资源排期，排队，表示排队等待时间，就是 从添加到待处理队列 到 实际开始处理的 时间间隔。
-
Connection Start | DURATION 是浏览器得到要发出这个请求的指令，到请求可以发出的等待时间，一般是代理协商、以及等待可复用的TCP连接释放的时间，不包括DNS查询、建立TCP连接等时间等 Stalled | 2.35ms 连接开始，停滞2.35ms 解决办法传送门 _ 原因： _ 浏览器对同一个主机域名的并发连接数有限制，因此如果当前的连接数已经超过上限，那么其余请求就会被阻塞，等待新的可用连接，和第一个Queued at差不多；此外脚本也会阻塞其他组件的下载； _解决办法： _ （1）通常常规的优化包括：css、js合并压缩、图片压缩、雪碧图、静态资源所有上CDN； （2）将资源合理分布到多台主机上，能够提升并发数，可是增长并行下载数量也会增大开销，这取决于带宽和CPU速度，过多的并行下载会下降性能； （3）脚本置于页面底部；
-
Request/Response ** 请求发送 / 响应 ** Request Sent 0.15ms 请求第一个字节发出前到最后一个字节发出后的时间，也就是上传时间，通常1ms左右 Waiting(TTFB) 1.53s 指的是浏览器开始收到服务器响应数据的时间（后台处理时间+重定向时间），是反映服务端响应速度的重要指标。就像你问朋友了一个问题，你的朋友思考了一会儿才给你答案，你朋友思考的时间就相当于 TTFB（Time To First Byte）。你朋友思考的时间越短，就说明你朋友越聪明或者对你的问题越熟悉。对服务器来说，TTFB 时间越短，就说明服务器响应越快。通常在50ms以下，如果时间过长，可能是网络原因，或后端查询数据慢导致，也可能是服务性能低，没做好优化等 Content Download ** 0.72ms 内容下载/下载中，收到响应的第一个字节，到接受完最后一个字节的时间，就是下载时间。这个问题我查了一下是多方面的主要解决办法给你们传送门：**
-
1、前端配置解决
-
3、就是个人理解的返回的json数据很大，这时候可能就需要后端的同学优化了
原理和各个问题的时间过长的解决办法已经贴上去啦，这些问题都好深奥，要完全搞懂还要多花时间。
最近遇到了这个问题，才想着记录一下，可能没有研究的很透彻，大神多多指点~
