我们还能在哪些方面进行webpack性能优化
Bigo前端组计算平台前端组基于amis框架，参考之前的文章：https%3A%2F%2Fgithub.com%2Fbigo-frontend%2Fblog%2Fissues%2F17 ；有很好的研发效率提升，但是构建速度却很慢，亟需进行优化。优化之后达到了将webpack构建速度提升80%左右的一个成绩，以下是优化前后的对比
团队做了3件事情来达到这样的一个效果：
基于这次优化做了功课，看了一些资料，看看还有哪些可以优化的地方。
官网的定义：
webpack is a static module bundler for modern JavaScript applications. When webpack processes your application, it internally builds a dependency graph which maps every module your project needs and generates one or more bundles.
也就是说 webpack 是一个用于现代 JavaScript 应用程序的静态模块打包工具，从入口出发，找到入口文件所有的依赖，生成浏览器可以用的bundle文件。webpack的出现使得前端的工程化更加地丰富。从webpack在2013的第一次release(v1.0.0-beta2)开始，至今已经有8、9年的 历史 了，是一个相当成熟的工具，其生态也比较完善，所以前端圈用webpack也是非常地广泛。
尽量用较新的版本，新版本相较之前都会有一定的性能提升和优化，包括Node和Webpack。要注意的是 Node.js v8.9.10 - v9.11.1 ES6的 Set 和 Map 会有性能回退问题，现在LTS的node已经是 v14.16.0 ，所以假设 Node 版本已经较新，并且用的是 WP4 ( webpack4 )。目前还不建议对求稳的或者已经很庞大的项目立即升级到 WP5 ，其一是因为webpack生态里面并不一定所有的插件都能跟的上最新的版本，可能会出现兼容性的问题；其二由于webpack5还并未被广泛地应用，到新版本的稳定和成熟还是需要一定的时间，为避免不必要的bug，建议暂时使用 webpack4 。
对于开发者来说，每次在build的时候不希望花费较长的时间，优化构建速度能够减少开发成本；对于用户而言，优化bundle文件的数量和大小能减少用户的流失率，提升用户体验。所以webpack的性能优化是一个非常关键的技术手段。
webpack构建大概可分为 loader解析 -> 依赖搜索 -> 打包 等三个阶段，就这三个阶段我们分别展开阐述如何去优化。
loader解析：
依赖搜索：
打包: Smaller = Faster
当然需要在 index.html 里面引入cdn依赖，否则在runtime无法找到相应的模块： 。
开发环境* *：** 同样地，生产环境有些配置也不适用于开发环境，比如 TerserPlugin 就不需要，因为在开发环境中压缩代码是没有意义的；devTools的最佳实践是 eval-cheap-module-source-map ，我现在的项目比较轻量，但是也能看出对比：
虽然是不到1000ms的差距，苍蝇肉也是肉不是？而且将来代码量越来越庞大的时候，差距就更明显了。
当然还有其他的可以优化的方法，比如使用ES module，能更好地利用webpack的tree shaking功能；Dll，为更改不频繁的代码生成单独的编译结果，但却是一个配置比较复杂的过程；还有对图片的压缩等等。以上是对于webpack4性能优化基本的配置，期待webpack5成熟稳定的那一天。
