1.背景供应链管理背景以下简称SCM。逐渐忽略了用户对系统体验层面的诉求。最近通过网上反馈渠道收集到的问题中，有不少是与页面打开速度慢有关。为了提升系统的用户体验和效率，我们对SCM的打开速度做了一些有针对性的迭代优化。2、现状目前SCM使用的是Vue2全家桶，基于vue-cli-service开发构建。菜单数量较多，将业务域拆分成若干个子应用（React技术栈）的迁移工作也在进行中。通过效率数据仪表盘，可以查看SCM二次开盘率的统计数据（二次开盘指数FMP的计算方法请参考首屏统计的前世今生）。从下图可以看出，优化前的二次打开率基本在20%以下，数据会随着发布频率的变化而波动。3.思路说到前端性能优化，大家的脑海里或多或少都会冒出一些想法。如果你搜索它，你还可以看到各种最佳实践和其他10,000字符的长文本。为了避免出现已经做了很多工作，但对性能提升没有明显效果的情况，在开始优化工作之前，首先需要对系统进行诊断，确定要达到的关键结果和衡量指标通过优化。这里我们只需要使用两个工具来辅助搜索优化工作，通过不断的优化和不断的验证就可以达到预期的效果。使用ChromeDevTools的性能选项卡来识别页面性能瓶颈。如下图，通过Network区显示的静态资源/接口请求的瀑布流，以及Main区主线程运行过程中各个Task的执行详情，很容易找出影响因素影响页面性能。如果使用Performance，可以参考官方教程Analyzeruntimeperformance。使用webpack-bundle-analyzer查看编译打包后的文件，验证打包策略是否合理，是否存在冗余模块等。使用vue-cli-service的项目可以在打包命令后加上--report开启;umi项目可以通过在打包命令前加上ANALYZE=1来启用；其他webpack项目可以安装webpack-bundle-analyzer依赖包，根据需要使用。4、优化之路首先要解决如何在最短的时间内获取页面所需的最少资源。4.1静态资源控制html文件大小由于TCP慢启动算法的限制，html文件大小尽量控制在14kB以内，以便html内容以TCP包的形式发送给浏览器（参考why-your-website-should-be-under-14kb-in-size)优化前的打包策略是将运行时块提取到html文件中。之前估计是为了减少请求数，但是因为在接收到Assets之后，整个站点的静态资源都被CDN化了，这方面的影响基本可以忽略。因此，去掉html文件中的runtimechunk内容后，文件大小从18kB缩小到不到1kB。公共包大小优化包分析工具显示，@du/earth占用了近40%的公共包。熟悉Vue的同学都知道，常见的Vue组件注册方式有两种：Vue.component(id,[definition])，全局注册{components:{'component-a':ComponentA}}，本地注册优先，常用于项目依赖的基础组件库，比如element-ui，由于组件库本身提供了install方法，可以使用Vue.use(ElementUI)方便的全局注册所有组件。如果组件不是按需打包的，这个导入方法会导入element-ui的整个包。importVuefrom'vue'importElementUIfrom'element-ui'Vue.use(ElementUI)但是在代码分析的过程中，发现@du/earth（可以理解为基于element-的高层组件）ui)也采用了这种全局注册的方式，经过一番查找比较（费了一番功夫），项目代码中只用到了其中的4个组件。importVuefrom'vue'//优化前importEarthfrom'@du/earth'Vue.use(Earth)//优化后importDuFormfrom'@du/earth/lib/du-form'//...Vue.component('du-form',DuForm)//...优化效果如下图，chunk-libs的提交直接从1.4MB减少到730kB，下降了50%。其实这种基本的工作量并不多，但是收益却是巨大的。另外，通过页面代码分析，其实有些组件并不是第一次入口就需要的，我们可以使用动态导入的方式。例如：importVuefrom'vue'//优化前importVueBarcodefrom'@xkeshi/vue-barcode'Vue.component('barcode',VueBarCode)//优化后Vue.component('barcode',()=>import('@xkeshi/vue-barcode'))部分依赖包也存在打包策略不合理，依赖包的优化需要推进。比如@du/umi-request2.x版本包会打包一些node.js模块。由于历史原因，我们暂时无法升级到3.x版本，所以我们找到了包的维护者。在2.x版本基本改变了依赖包的导入方式，更新了2.x版本。借助发布平台资产发布资产打包优化。前端应用可以很好的利用CDN特性，带来更快的资源请求速度，支持秒级回滚。但是目前的访问方式需要前端应用自己加上版本号的概念。如果更新了版本号，构建产品每次编译打包后都会放在新版本号的目录下，导致基于contentHash的打包策略无法得到充分利用。浏览器缓存。为了解决这个问题，目前有两种方案（如果大家有更好的方案欢迎留言分享）：setexternals。通过unpkg或者自己上传一些不容易改的基础框架包到CDN，以脚本src的形式写入到index.html文件中。并将这些依赖包设置到打包配置文件中的externals配置项中：..}}使用DllPlugin预打包。对于一些不易更改但可能需要在本地打包的依赖包，可以使用webpackDllPlugin提前打包。在vue-cli-service项目中，可以添加vue-cli-plugin-dll依赖，在vue.config.js中配置：{pluginOptions:{dll:{entry:{vendor:['vue','vue-router','vuex','@du/element-ui'],},output:{path:path.resolve(__dirname,'./dll'),filename:'[name].js',},注入:false,}}}我们拿到dll产品后，目前将其上传到CDN，并导入到index.html文件中。后面我们可以通过CopyWebpackPlugin和HtmlWebpackPlugin将其添加到打包过程中。总结大概通过以上的优化方式，可以将公共依赖包chunk-libs的提交压缩到200kB以内。4.2页面渲染SCM采用典型的top-sidelayout-banner界面布局的后台应用。提前渲染主体布局。SCM目前的路由是获取用户的天网权限菜单，与本地声明的路由进行merge操作，在Vue实例化之前添加到vue-router的路由表中。当前方法需要等待菜单界面请求完成后才开始渲染主体布局。根据上报的接口请求时间数据，菜单的接口请求大约需要200ms（全菜单权限的情况下），如果菜单的数据可以缓存起来，对于秒开来说，这里节省的能量还是很明显的.因此，在原有的菜单界面请求逻辑中加入了缓存优先级的逻辑。伪代码如下：}//更新菜单栏数据getMenuListFromApi((res)=>{setMenuListCache(res.data)store.dispatch('app/menuList',res.data)})})}另外优化前的嵌套路由声明方法就是把Layout(菜单栏+顶栏)作为嵌套view的一部分，也就是当前路由解析后才能渲染主布局。之所以使用这种方式，是考虑到有路由页面不需要Layout的场景，但经过分析，这种场景其实还是比较少见的，可以兼容处理。伪代码如下：
