前言之前用vuecli写过一篇博客，是一个单页项目，npmrunbuild直接打包的路由大概有十条，还有一个巨大的js1M先把文件挂载到服务器上试试看。加载时间仿佛过了半个世纪。第一屏页面加载耗时9秒，大文件加载耗时8秒。这个必须优化。没有用户可以容忍9秒。在清空页面不关闭页面的过程中，我也将项目从vuecli2.x迁移到了vuecli3，所以我会介绍一些优化上的异同点。vuecli2.x自带分析工具，直接运行npmrunbuild--report如果是vuecli3，先安装插件cnpmintallwebpack-bundle-analyzer–save-dev然后在vue.config.js中配置webpackchainWebpack:(config)=>{/*添加分析工具*/if(process.env.NODE_ENV==='production'){if(process.env.npm_config_report){config.plugin('webpack-bundle-analyzer').use(require('webpack-bundle-analyzer').BundleAnalyzerPlugin).end();config.plugins.delete('prefetch')}}}然后运行npmrunbuild--report会在浏览器中打开一个项目打包图，方便直观对比每个bundle文件，可以看到所有的依赖和所有项目中的路由都打包到同一个文件中。另外，在浏览器中，还可以通过converge查看代码的使用状态。红色的已下载但未使用。部分路由的延迟加载在打包构建应用时，JavaScript包会变得很大，影响页面加载。如果我们能把不同路由对应的组件分成不同的代码块，然后在路由访问时加载相应的组件，效率会更高。一开始就把路由对应的组件文件都下载下来，显然是不合适的。这就好比下载一个app，所以我们需要在router.js文件中使用路由进行懒加载。原静态引用方法importShowBlogsfrom'@/components/ShowBlogs'routes:[path:'Blogs',name:'ShowBlogs',component:ShowBlogs]改为routes:[path:'Blogs',name:'ShowBlogs',component:()=>import('./components/ShowBlogs.vue')以函数的形式动态引入，这样可以将各自的路由文件单独打包，需要加载的文件放在routing组件的firstscreen只有在解析给定的routing时才会下载，已经变成橙色的部分已经被小弟们分流掉了。如果是在vuecli3中，我们还需要多做一步，因为vuecli3默认开启了prefetch（预加载模块），从而提前获取用户以后可能访问的内容。首屏会一次性下载这几十个路由文件，所以我们要关闭这个功能，在vue.config.js中设置参考官网：设置后，首屏只会加载当前页面的路由组件element-ui按需加载首屏需要加载的依赖包，element-ui占用足足568k。原来的导入方式引入了整个包：importElementUIfrom'element-ui'Vue.use(ElementUI)但实际上我使用的组件只有按钮、分页、表格、输入和警告，所以我们需要根据需要引用它们:从'element-ui'导入{Button,Input,Pagination,Table,TableColumn,MessageBox};Vue.use(Button)Vue.use(Input)Vue.use(Pagination)Vue.prototype.$alert=MessageBox.alert注意MessageBox注册方式的区别，虽然我们使用了alert，但是不需要在.babelrc文件中引入Alert组件添加（vue-cli3需要先安装babel-plugin-component）：plugins:[["component",{"libraryName":"element-ui","styleLibraryName":"theme-chalk"}]]element-ui小了很多，但是看到显眼的table.js后，突然想到table组件只有后台管理页面使用，不需要全局注册，所以我们删除main.js中Table和TablColumn的引用，在后台组件本地注册import{Table,TableColumn}from"element-ui";components:{"el-table":Table,"el-table-column":TableColumn}，表格拆分到路由文件中，组件重复打包。上图可以看到，两个路由文件都引用了codemirror。在webpack的config文件中，修改CommonsChunkPlugin的配置minChunks:3，将3改为2，则将被使用过两次以上的包提取出来，放到公共依赖文件中。不过由于首页也有多个组件，所以首页我也会下载这个公共依赖文件。下载了首页黄色和灰色的部分，拆了半天，又回到了原点。当然，我们可以继续折腾CommonsChunkPlugin的配置来解决这个问题，但是在新版本的webpack中，CommonsChunkPlugin的自由度更高，也更先进。SplitChunksPlugin取代了这就是为什么我要将项目迁移到vuecli3（使用webpack4）并默认优化它。首页只会下载灰色部分（235K）。gzip解压后我们使用gzip压缩安装compressionwebpack-plugincnmpicompression-webpack-plugin-D在vue.congig.js中引入并修改webpack配置constCompressionPlugin=require('compression-webpack-plugin')configureWebpack:(config)=>{if(process.env.NODE_ENV==='production'){//修改生产配置...config.mode='production'return{plugins:[newCompressionPlugin({test:/\.js$|\.html$|\.css/,//匹配filenamethreshold:10240,//压缩超过10k的数据deleteOriginalAssets:false//是否删除原文件})]}}可以看到超过200k的文件已经压缩到100k以内了。在服务端，如果发送请求的浏览器支持gzip，我们也需要做相应的配置，发送一个gzip格式的文件。我的服务器是用express框架构建的。安装压缩就可以使用constcompression=require('compression')app.use(compression())注意后一句要放在所有其他中间件注册之前。最终效果是首屏加载资源198k，加载时间1s，比原帖快90%：是否拆分vuecli3和vuecli2。一个不同的是vuecli3会默认开启一个css分离插件ExtractTextPlugin。每个模块的css文件都会分开，一共13个css文件，我们的首页请求了4个，占用了资源请求时间。我们可以在vue.config.js中关闭它css:{//是否使用css分离插件ExtractTextPluginextract:false,//启用CSSsourcemaps？sourceMap:false,//csspresetter配置项loaderOptions:{},//为所有css/预处理器文件启用CSS模块。modules:false},packaged在输出文件中，直接没有css文件夹。相反，它是一个集成的js文件，负责从头开始注入所有样式。首屏加载文件数量减少，但体积变大，最终测试速度也不算太大。因此，是否拆分css，见仁见智。下面具体分析项目。综上所述，性能优化是一个很愉快的过程，但也是一个深坑，东西太多。这篇文章仅仅是个开始。有帮助的参考文章Vue打包优化代码拆分https://juejin.im/post/5ac815...Vue性能优化：如何实现懒加载和代码拆分？https://www.infoq.cn/article/...*zNWebpack打包优化卷https://www.jeffjade.com/2017...记一个vue+element+echarts项目优化https://juejin.im/post/5b0033…
