我们还能在哪些方面进行webpack性能优化

　　我们做了啥
　　Bigo前端组计算平台前端组基于amis框架，参考之前的文章：https3A2F2Fgithub。com2Fbigofrontend2Fblog2Fissues2F17；有很好的研发效率提升，但是构建速度却很慢，亟需进行优化。优化之后达到了将webpack构建速度提升80左右的一个成绩，以下是优化前后的对比
　　团队做了3件事情来达到这样的一个效果：splitchunks进行公共模块优化optimization：｛splitChunks：｛chunks：all，cacheGroups：｛vendorsa：｛chunks：all，test：（mobxstatetreereactcolorreactdomroutersortablejsmobxreact），priority：100，name：vendorsreactmobx，｝，venodrb：｛test：lodash，priority：100，name：vendorlodash，chunks：all｝，｝｝｝external避免将比较大的第三方依赖打包到bundle中webpack。config。js：externals：〔｛react：React，reactdom：ReactDOM，moment：moment，mobx：mobx，monacoeditor：monaco，echarts：echarts，jquery：jQuery，hls。js：hls，flv。js：flv，｝，function（context，request，callback）｛if（moment。。test（request））｛returncallback（null，rootmoment）；｝if（tinymce。。test（request））｛returncallback（null，roottinymce）；｝if（froalaeditor。。test（request））｛returncallback（null，rootfroala）；｝if（echarts。。test（request））｛returncallback（null，rootecharts）；｝继续下一步且不外部化引用callback（）；｝，〕index。html：对tsloader的优化：｛test：。tsx？，use：〔｛loader：tsloader，options：｛transpileOnly：true｝｝〕，exclude：nodemodules｝，。。。plugins：〔newForkTsCheckerWebpackPlugin（），〕
　　基于这次优化做了功课，看了一些资料，看看还有哪些可以优化的地方。webpack是什么
　　官网的定义：
　　webpackisastaticmodulebundlerformodernJavaScriptapplications。Whenwebpackprocessesyourapplication，itinternallybuildsadependencygraphwhichmapseverymoduleyourprojectneedsandgeneratesoneormorebundles。
　　也就是说webpack是一个用于现代JavaScript应用程序的静态模块打包工具，从入口出发，找到入口文件所有的依赖，生成浏览器可以用的bundle文件。webpack的出现使得前端的工程化更加地丰富。从webpack在2013的第一次release（v1。0。0beta2）开始，至今已经有8、9年的历史了，是一个相当成熟的工具，其生态也比较完善，所以前端圈用webpack也是非常地广泛。版本
　　尽量用较新的版本，新版本相较之前都会有一定的性能提升和优化，包括Node和Webpack。要注意的是Node。jsv8。9。10v9。11。1ES6的Set和Map会有性能回退问题，现在LTS的node已经是v14。16。0，所以假设Node版本已经较新，并且用的是WP4（webpack4）。目前还不建议对求稳的或者已经很庞大的项目立即升级到WP5，其一是因为webpack生态里面并不一定所有的插件都能跟的上最新的版本，可能会出现兼容性的问题；其二由于webpack5还并未被广泛地应用，到新版本的稳定和成熟还是需要一定的时间，为避免不必要的bug，建议暂时使用webpack4。为什么要优化
　　对于开发者来说，每次在build的时候不希望花费较长的时间，优化构建速度能够减少开发成本；对于用户而言，优化bundle文件的数量和大小能减少用户的流失率，提升用户体验。所以webpack的性能优化是一个非常关键的技术手段。优化手段两个测量工具speedmeasurewebpackplugin（SMP），要对webpack的构建速度进行优化，得知道要优化的重点在哪里，而该插件则是帮助检查哪些地方需要进一步优化的工具。webpackbundleanalyzer，虽然webpack也有官方的分析工具，社区也有许多其他的工具可以参考，但是通过资料、技术分享以及项目经验，webpackbundleanalyzer用的还是不错的，它可以将bundle展示为交互式、可缩放的树状图形式，使用起来非常便捷。三个可优化阶段
　　webpack构建大概可分为loader解析依赖搜索打包等三个阶段，就这三个阶段我们分别展开阐述如何去优化。
　　loader解析：includeexclude，对于loader而言，不需要对项目中所有的文件进行文件转换，应将loader应用于最少数量的必要模块，常见的配置：｛。。。，exclude：nodemodules｝如果项目中用到了tsloader，那就要小心了，因为如果不做额外的配置，会发现构建速度是非常耗时的。原因是因为tsloader在每次构建的时候都会对所有文件进行类型检查，当项目越来越庞大，会发现构建速度越来越慢。这个时候需要设置transpileOnly：true来提高构建速度，该配置只处理编译而不做类型检查；然而类型检查是使用TypeScript的初衷，可以使用forktscheckerwebpackplugin插件来在单独的进程中做类型检查。那性能和类型检查都能cover到。如果使用的是babelloader，可以设置其cache相关的选项，比如cacheDirectory、cacheCompression等；cacheloader：利用文件的modifiertime来检查文件是否更新，如果没有更新则利用缓存的内容，是一个轻量级的比较。特点是在第一次构建的时候比较慢，后面的构建会快很多。但是用它也要特别注意，最好用在性能消耗比较昂贵的地方，否则基本没有什么效果。该loader已经被作者Archive了，因为webpack5内置了cache的相关配置，将来如果升级就不需要它了。使用cacheloader时要放在其他loader的前面。threadloader：也是应用于比较昂贵的地方，可以将打包任务划分多个node进程，把模块一次分配给这些进程，实现多进程构建。跟cacheloader一样也需要放到其他loader的前面。｛。。。，use：〔threadloader，昂贵的loader（e。gbabelloader）〕，｝最后一点是，尽量少用工具，因为每个loaderplugin都有其启动时间，不用就不会有性能问题啦。
　　依赖搜索：减少resolve。modules，resolve。extensions等中条目数量，因为IO操作比较消耗性能；基本上webpack对这些配置有默认值，比如resolve。modules为nodemodules，告诉webpack解析模块时应该搜索nodemodules目录；resolve。extensions默认值为〔。wasm，。mjs，。js，。json〕，如果用了TypeScript还是要配置一下的，extensions是说在引入模块时可以不需要带扩展：importFilefrom。。pathtofile；
　　打包：SmallerFastersplitChunks，本着小即是快的原则，尽量使chunk包越小越好。在webpack4之前，可以使用CommonsChunkPlugin来避免模块与模块之间的重复依赖，webpack4内置了optimization。splitChunks，可开箱即用。splitChunks有它默认的行为，不同的项目根据需求做不同的调整。可以设置不同的cacheGroup，拆分前必须共享模块的最小chunk数量等等，能最大程度地优化重复依赖的问题。一个简单的：splitChunks：｛chunks：all，cacheGroups：｛lodash：｛test：lodash，priority：1，｝，｝｝externals，防止将某些import的包打包到bundle中，而是在运行时再去从外部获取这些扩展依赖。例如：externals：〔｛moment：moment，｝。。。〕
　　当然需要在index。html里面引入cdn依赖，否则在runtime无法找到相应的模块：。多环境
　　生产环境：生产环境关注与压缩bundle、更轻量的sourcemap等，建议不同环境写不同的配置，当然可以有共用的配置，利用webpackmerge可以实现配置共用；对于devTools，推荐使用sourceMap，相对于inlinesourcemap和evalcheapmodulesourcemap性能好一点；代码压缩，在WP5中内置了terserwebpackplugin，现在使用WP4的话，需要安装插件，这个插件功能非常强大，除了基本的压缩功能以外，还可以使用多进程并发构建，以及去除注释等功能；不带路径的配置，pathinfo会在bundle中包含模块信息的注释，但在庞大的项目中，会导致GC性能很差，应该关闭；
　　开发环境：同样地，生产环境有些配置也不适用于开发环境，比如TerserPlugin就不需要，因为在开发环境中压缩代码是没有意义的；devTools的最佳实践是evalcheapmodulesourcemap，我现在的项目比较轻量，但是也能看出对比：inlinesourcemap：5205msVSevalcheapmodulesourcemap：4744ms
　　虽然是不到1000ms的差距，苍蝇肉也是肉不是？而且将来代码量越来越庞大的时候，差距就更明显了。
　　当然还有其他的可以优化的方法，比如使用ESmodule，能更好地利用webpack的treeshaking功能；Dll，为更改不频繁的代码生成单独的编译结果，但却是一个配置比较复杂的过程；还有对图片的压缩等等。以上是对于webpack4性能优化基本的配置，期待webpack5成熟稳定的那一天。