前置知识
瀑布图：是请求不同阶段的图形表示。将鼠标悬停在瀑布上可以查看细目
鼠标放上去会看到下面的面板
下面我们来介绍下这些英文和数字代表什么意思
-
总计：
- Queued 队列总耗时
- Started 在什么时候发起请求，一般于Queued相差几十毫秒
Queueing (队列)
- 该请求被渲染引擎推迟了，因为它被认为比关键资源（例如脚本/样式）的优先级低。这通常发 生在图像上。
- 该请求被暂停以等待将要释放的不可用的TCP套接字。
- 由于浏览器在HTTP 1上每个源仅允许六个TCP连接，因此该请求被暂停。
- 花在制作磁盘缓存条目上的时间（通常非常快) Stalled/Blocking(阻塞)
- 请求等待发送之前花费的时间。它可能正在等待队列中描述的任何原因。此外，此时间包括代理协商中花费的任何时间。 Proxy Negotiation（代理协商）
- 与代理服务器连接进行协商所花费的时间。
DNS Lookup(DNS查询)
- 与代理服务器连接进行协商所花费的时间。 Initial Connection （初始化连接）
- 建立连接所花费的时间，包括TCP握手/重试和协商SSL。 SSL
- 完成SSL握手所花费的时间 Request Sent (请求发送)
- 发出网络请求所花费的时间。通常为一毫秒的时间。 Waiting (TTFB)(Time To First Byte)
- 等待初始响应所花费的时间，也称为到达第一个字节的时间。除了等待服务器传递响应所花费的时间之外，该时间还捕获了到服务器的往返延迟。 Content Download （内容下载）
- 接收响应数据所花费的时间。
我们开发中最应该关注：
Started： 什么时候发起这个请求
Waiting (TTFB)(Time To First Byte) 这个接口耗时了多少
Content Download （内容下载 ）从服务器下载到本地耗时了多久
案例
图标库的优化
背景
图标库页面的加载过慢，需要优化下。（图标的加载是后端存成了id，前端调用接口进行下载展示）
分析
打开F12,查看network， 发现下载的瀑布图是阶梯状的，一个接着一个发起，因为图标的加载默认是没有依赖关系，这里可以同步发起。
查看页面代码后。发现代码确实是在发起请求后，当上一个请求有response后再发起下一次请求
下方的图片为当时的瀑布图
修改后
请求同时发起，瀑布图也是期望的样子。
用户体验的优化
- 之前使用的是promise.all,当所有请求结束，页面的loading才结束，展示给用户
- 修改为取消loading,使用elementUi组件 el-image,给图标加一个loading状态，当response有响应，再将真实的图片地址替换掉，更快的展示给用户
总结
如何根据瀑布图进行优化
Started 过长，
- 检查静态资源是否过大，导致请求延后，将资源进行分包
- 检查请求是否链式调用，可以考虑将请求同步发起，如果真的是后一个请求依赖前一个请求，考虑是否有更好的方案
Waiting 过长
- 先与后端沟通接口是否可以调优
- 前端与后端沟通用到了哪个字段，检查是否多查询了无用的字段
Content Download 过长
- 接口响应长（是否多返回了无用的字段）
- 静态资源过大（webpack进行分包按需加载）
