VUE2打包体积优化以及利用TimeLine进行优化点分析

背景：由于业务发展，代码打包体积逐渐增大，打包后文件增大到24M左右，页面loading时间达到了恐怖的3.5s,极端情况下甚至达到了15s左右

方法：去掉或者根据环境判断（一般是谷歌统计或者谷歌地图资源加载会导致这样的问题）

根据element和echarts官网上的教程，进行了按需加载（element由于调用的组件太多，并未节省太多资源），按需加载后大概节省了2M左右的资源

mathjs

由于项目中用到了地图围栏功能，有较多对小数点运算功能，但这个包体积实在过大，为了性能自己写utils实现（小数点精度记得保持）

建议是node_modules下载项内容简单的尽量手写

该方法只能减少打包后文件体积，但是实际页面加载时的总资源量不变

此时合理利用chunk分包策略，建议只对500K以上的资源进行分包，具体原因在timeLine中详解

如上图所示，打开network，箭头出即是每个请求的timeline缩略图，在这里可以看到请求资源加载的大致情况

如上图所示，点击某个请求，可详细查看该请求的时间分布，我们根据单个请求详细解释资源加载耗时以及如何优化

导致该请求不能被立即执行的原因:

首先，页面中的资源是有优先级的。比如 CSS、HTML、JavaScrpt 等都是页面中的核心文件，所以优先级最高;而图片、视频、音频这类资就不是核心资源，优先级就比较低，通常当后者遇到前者时，就需要"让路"，进入待排队状态。

其次，浏览器会为每个域名最多维护 6 个TCP 连接，如果发起一个 HTTP 请求时，这6 TCP 连接都处于忙碌状态，那么这个请求就会处于排队状态,0最后，网络进程在为数据分配磁盘空间时，新的 HTTP 请求也需要短暂地等待磁盘分配结束

解决方法：域名分片技术（资源多域名加载）、站点升级

该阶段为TCP连接的检测过程，如果检测成功就会继续使用该TCP发送数据，检测失败则会重建连接，所以该阶段耗时较长，往往是丢包导致，这也意味着网络或者服务端有问题

3.服务器建立连接以及ssl握手时间

该阶段在最新chrome中部分不展示，本次整个连接市场1.44ms，因此不考虑是该部分问题

该阶段发送浏览器缓冲区数据，无需判断服务器是否收到，此处一般不用分析

该指标可以反映出服务器响应速度，时间越短，服务器响应越快

过慢时可从以下原因分析

markdown 复制代码

    *   服务器生成页面数据时间过久
    *   网络原因
    *   发送请求头时带上了多余的用户信息

解决方案

markdown 复制代码

    *   服务器增加缓存
    *   首先排查网络环境，网络环境无问题则使用cdn缓存更多的静态文件
    *   减少信息携带

该项是下载资源时长，单个资源下载时间过长，前端自己看看资源大小反省一下，（压缩文件、去注释、拆包）

引用：浏览器原理 20 # Chrome开发者工具：利用网络面板做性能分析 （blog.51cto.com/kaimo313/55...