在http1的时代，比较常见的一种性能优化就是合并http的请求数量，通常我们会把许多js代码合并在一起，但是如果一个js包体积特别大的话对于性能提升来说就有点矫枉过正了。而如果我们对所有的代码进行合理的拆分，将首屏和非首屏的代码进行剥离，将业务代码和基础库代码进行拆分，在需要某段代码的时候再加载它，下次若再需要用则从缓存中读取，一来可以更好地使用浏览器缓存，再者就是可以提高首屏加载速度，很好提升用户的体验。
核心思想
业务代码和基础库的分离
这个其实很好理解，业务代码通常更新迭代很频繁，而基础库通常更新缓慢，这里做拆分的话可以充分利用浏览器缓存来加载基础库代码。
按需异步加载
这个主要解决首屏请求大小的问题，我们在访问首屏的时候只需要加载首屏所需的逻辑，而不是加载所有路由的代码。
实战
最近，采用vuetify改造了一个内部系统，一开始用了最常用的webpack配置，功能很快开发了，可是一打包，发现效果不是很明显，打出很多大包
这里我们看下打包分布，这里使用的是 webpack-bundle-analyzer,可以很清晰的看到 vue 和 vuetify等模块都有出现 被重复打包的情况。
这里我们先贴一下配置，一边一会儿分析时用:
const path = require('path') const webpack = require('webpack') const CleanWebpackPlugin = require('clean-webpack-plugin') const HtmlWebpackPlugin = require('html-webpack-plugin') const BundleAnalyzerPlugin = require('webpack-bundle-analyzer').BundleAnalyzerPlugin; const generateHtml = new HtmlWebpackPlugin({ title: '逍遥系统', template: './src/index.html', minify: { removeComments: true } }) module.exports = { entry: { vendor: ['vue', 'vue-router', 'vuetify'], app: './src/main.js' }, output: { path: path.resolve(__dirname, './dist'), filename: '[name].[hash].js', chunkFilename:'[id].[name].[chunkhash].js' }, resolve: { extensions: ['.js', '.vue'], alias: { 'vue$': 'vue/dist/vue.esm.js', 'public': path.resolve(__dirname, './public') } }, module: { rules: [ { test: /\.vue$/, loader: 'vue-loader', options: { loaders: { } // other vue-loader options go here } }, { test: /\.js$/, loader: 'babel-loader', exclude: /node_modules/ }, { test: /\.(png|jpg|gif|svg)$/, loader: 'file-loader', options: { objectAssign: 'Object.assign' } }, { test: /\.css$/, loader: ['style-loader', 'css-loader'] }, { test: /\.styl$/, loader: ['style-loader', 'css-loader', 'stylus-loader'] } ] }, devServer: { historyApiFallback: true, noInfo: true }, performance: { hints: false }, devtool: '#eval-source-map', plugins: [ new BundleAnalyzerPlugin(), new CleanWebpackPlugin(['dist']), generateHtml, new webpack.optimize.CommonsChunkPlugin({ name: 'ventor' }), ] } if (process.env.NODE_ENV === 'production') { module.exports.devtool = '#source-map' // module.exports.plugins = (module.exports.plugins || []).concat([ new webpack.DefinePlugin({ 'process.env': { NODE_ENV: '"production"' } }), new webpack.optimize.UglifyJsPlugin({ sourceMap: true, compress: { warnings: false } }), new webpack.LoaderOptionsPlugin({ minimize: true }) ]) }
CommonChunkPlugin
ventor入口这里我们发现并没有筛选出所有引用的node_module下的模块 ，比如axios ,所以导致打包到了app.js里了，这里我们做下分离
entry: { vendor: ['vue', 'vue-router', 'vuetify', 'axios'], app: './src/main.js' },
那这里又出现个问题了，我不可能手动去手动录入模块，这时我们可能需要 自动化分离 ventor，这里我们需要引入 minChunks，在配置中我们就可以对所有mode_module下所引用的模块进行打包 修改配置如下
entry: { //vendor: ['vue', 'vue-router', 'vuetify', 'axios'], //删除 app: './src/main.js' } new webpack.optimize.CommonsChunkPlugin({ name: 'vendor', minChunks: ({ resource }) => ( resource && resource.indexOf('node_modules') >= 0 && resource.match(/\.js$/) ) }),
经过上面几步的优化，我们再看看文件分布，会发现node_module下的模块都收归到了vendor下了。
这里我们可以得到一个经验，就是在一个项目中可以专门针对node_module下的模块进行打包优化。但是这里细心的你可能发现codemirror组件不也是node_module中的么，但为啥没被打包进去反而重复打包到其他单页面了呢，其实这里是因为在commonChunk中使用name属性其实也就意味着只会沿着entry入口去找寻所依赖的包，由于我们的组件采用的是异步加载，故这里就不会去打包了，我们做个实验验证下，现在我们去掉dbmanage和system页面的路由懒加载改为直接引入