今天终于过上一个周末了，终于不用陪女朋友逛街，看电影，吃吃吃的我立刻打开电脑撸了一把代码，爽的一匹。
嘿嘿，今天记录一下我在学习和使用webpack时收集的webpack性能优化方案，不过最近看到webpack4又将性能优化提升到了一个新的高度，不禁泪湿了键盘。不断更新的前端技术栈，我都缺了好多课了。
不多说咯，干就完了！
从头开始说，webpack在代码构建的过程中可以优化的点：
babel-loader的优化：
babel-loader的功能最为强大，同时也是耗时最长的。一般搭配babel-preset-env可以让babel自己去确定最适合浏览器的babel版本和polyfills去使用。
babel的配置（.babel）这一块儿如果各位看官有精力可以把babel对es兼容语法的各个功能查看一遍，绝对有可优化的空间，总之先不要问我了，因为我也不会......
我所使用的优化是使用exclude来除去长久不变的第三方插件，避免编译庞大node_modules。且开启babel-loader的缓存功能。
{
test: /\.js$/,
exclude: /node_modules/,
use: {
loader: 'babel-loader?cacheDirectory=true',
options: {
presets: ['@babel/preset-env']
}
}
}
放弃commonsChunkPlugin，使用DllPlugin:
你，对就是你，跟我讲讲commonsChunkPlugin这个插件是弄啥的？
不错！！！
它就是将webpack打包时的重复代码统一成一个叫vendor的js块儿的（当初刚学webapck的时候觉得就冲这个组件和es6模块化我就得重新用webpack给项目架构一遍）
但是他有一个让人无法忽视的膈应缺陷，每次run的时候都会进行一次打包，但像是那些第三方的依赖库我们很少会去更新，所以每次的打包其实都是多余的喵。
这个时候有一个插件出现了，一厥鸭子给又慢又大的commonsChunk踢一边去了。
这个小插件子就叫DllPlugin，他说呀，我跟那货不一样，我是先把依赖的第三方库原封不动的打出来，再给其配上一个关联id用的vendor-manifest.json，这些代码以后就不动了，今后都只对每次都修改的js打包。
使用Happypack:
webpack是单线程，我们用它处理loader任务的时候也只能一个接一个的排队处理，Happypack会充分释放cpu多核的优势，把任务分解成多个子进程去并发执行。提高打包效率，优化构建时间。
使用webpack-bundle-analyzer可视化压缩后代码结构:
一个非常好用的包组成可视化工具，他会以矩形图的形式将包内各个模块大小和依赖关系呈现出来。如果将比较大的第三方插件一同打包进来会使vendor非常大，就可以通过这个组件对症下药啦，甭管您是用externals，dll还是什么方法，就可以将大插件剥离出来。
使用require.ensure() 进行按需加载:
这种方式应该是各位老铁用的很多的一种吧，我们在写单页面应用的时候，很多页面或组件其实都是不需要在首页或者一个页面渲染时就加载出来的，所以统统一口气下载下来也是资源的浪费，然后我们就用到了这种类似懒加载的技术。
一期就先记录到这里吧，明年就要结婚了心里美滋滋，可是银子也是花的风卷残云一般，写完这边笔记又要赶紧去接个私活挣娶媳妇钱了，下次见了各位看官。
网友评论