背景：由于业务发展，代码打包体积逐渐增大，打包后文件增大到24M左右，页面loading时间达到了恐怖的3.5s,极端情况下甚至达到了15s左右
结果：优化后打包体积降低为2.5M左右，首屏加载时间稳定在1s左右
首先，我们要解决的是不可容忍的15s以上的loading时间（根据以往经验，国内用户无法加载国外资源导致）
方法：去掉或者根据环境判断（一般是谷歌统计或者谷歌地图资源加载会导致这样的问题）
第二步，由于项目刚开始比较赶工期，直接拉过来的框架并未对element和echarts按需加载
根据element和echarts官网上的教程，进行了按需加载（element由于调用的组件太多，并未节省太多资源），按需加载后大概节省了2M左右的资源
第三步，针对package.json的下载项挨个排查
mathjs
由于项目中用到了地图围栏功能，有较多对小数点运算功能，但这个包体积实在过大，为了性能自己写utils实现（小数点精度记得保持）
建议是node_modules下载项内容简单的尽量手写
第四步，此时项目打包体积缩减到17M左右，添加gz压缩减小打包后体积
该方法只能减少打包后文件体积，但是实际页面加载时的总资源量不变
此时合理利用chunk分包策略，建议只对500K以上的资源进行分包，具体原因在timeLine中详解
控制台中netWork的TimeLine
如上图所示，打开network，箭头出即是每个请求的timeline缩略图，在这里可以看到请求资源加载的大致情况
如上图所示，点击某个请求，可详细查看该请求的时间分布，我们根据单个请求详细解释资源加载耗时以及如何优化
1.正在排队（英文为Queuing），该项关系到chunk分包策略
导致该请求不能被立即执行的原因:
首先，页面中的资源是有优先级的。比如 CSS、HTML、JavaScrpt 等都是页面中的核心文件，所以优先级最高;而图片、视频、音频这类资就不是核心资源，优先级就比较低，通常当后者遇到前者时，就需要"让路"，进入待排队状态。
其次，浏览器会为每个域名最多维护 6 个TCP 连接，如果发起一个 HTTP 请求时，这6 TCP 连接都处于忙碌状态，那么这个请求就会处于排队状态,0最后，网络进程在为数据分配磁盘空间时，新的 HTTP 请求也需要短暂地等待磁盘分配结束
解决方法：域名分片技术（资源多域名加载）、站点升级
2.停滞（英文为Stalled）
该阶段为TCP连接的检测过程，如果检测成功就会继续使用该TCP发送数据，检测失败则会重建连接，所以该阶段耗时较长，往往是丢包导致，这也意味着网络或者服务端有问题
3.服务器建立连接以及ssl握手时间
该阶段在最新chrome中部分不展示，本次整个连接市场1.44ms，因此不考虑是该部分问题
4.已发送请求（英文为Request Send）
该阶段发送浏览器缓冲区数据，无需判断服务器是否收到，此处一般不用分析
5 正在等待服务器响应（waiting）
该指标可以反映出服务器响应速度，时间越短，服务器响应越快
过慢时可从以下原因分析
markdown
* 服务器生成页面数据时间过久
* 网络原因
* 发送请求头时带上了多余的用户信息解决方案
markdown
* 服务器增加缓存
* 首先排查网络环境，网络环境无问题则使用cdn缓存更多的静态文件
* 减少信息携带6.下载内容（Content DownLoad）
该项是下载资源时长，单个资源下载时间过长，前端自己看看资源大小反省一下，（压缩文件、去注释、拆包）
引用：浏览器原理 20 # Chrome开发者工具：利用网络面板做性能分析 （blog.51cto.com/kaimo313/55...