SMP ⏱
General output time took 38.3 secs
SMP ⏱ Plugins
HtmlWebpackPlugin took 1.31 secs
CopyPlugin took 0.016 secs
OptimizeCssAssetsWebpackPlugin took 0.002 secs
ContextReplacementPlugin took 0.001 secs
MiniCssExtractPlugin took 0 secs
DefinePlugin took 0 secs
SMP ⏱ Loaders
_babel-loader@8.1.0@babel-loader took 29.98 secs
module count = 1503
_babel-loader@8.1.0@babel-loader, and
_eslint-loader@3.0.4@eslint-loader took 18.74 secs
module count = 86
_css-loader@3.6.0@css-loader, and
_less-loader@5.0.0@less-loader took 16.45 secs
module count = 64
modules with no loaders took 2.24 secs
module count = 7
_file-loader@5.1.0@file-loader took 1.03 secs
module count = 17
_style-loader@1.3.0@style-loader, and
_css-loader@3.6.0@css-loader, and
_less-loader@5.0.0@less-loader took 0.102 secs
module count = 64
_html-webpack-plugin@3.2.0@html-webpack-plugin took 0.021 secs
module count = 1
SMP ⏱
General output time took 10.67 secs
SMP ⏱ Plugins
HtmlWebpackPlugin took 1.69 secs
BundleAnalyzerPlugin took 0.091 secs
CopyPlugin took 0.011 secs
MiniCssExtractPlugin took 0.003 secs
OptimizeCssAssetsWebpackPlugin took 0.002 secs
DefinePlugin took 0.001 secs
ContextReplacementPlugin took 0 secs
SMP ⏱ Loaders
_babel-loader@8.1.0@babel-loader took 8.26 secs
module count = 277
_babel-loader@8.1.0@babel-loader, and
_eslint-loader@3.0.4@eslint-loader took 7.18 secs
module count = 86
_css-loader@3.6.0@css-loader, and
_less-loader@5.0.0@less-loader took 1.94 secs
module count = 28
modules with no loaders took 0.728 secs
module count = 12
_file-loader@5.1.0@file-loader took 0.392 secs
module count = 17
_style-loader@1.3.0@style-loader, and
_css-loader@3.6.0@css-loader, and
_less-loader@5.0.0@less-loader took 0.052 secs
module count = 28
_html-webpack-plugin@3.2.0@html-webpack-plugin took 0.026 secs
module count = 1
为什么需要性能优化
在使用
Webpack
时,如果不注意性能优化,可能会产生性能问题,会导致在开发体验上不是非常丝滑,性能问题主要是编译速度慢,打包体积过大,因此性能优化也主要从这些方面来分析。本文主要是自己平时的工作积累和参考别人的文章,而进行总结,基于Webpack4
版本。构建分析
编译速度分析
对
Webpack
构建速度进行优化的首要任务就是去知道哪些地方值得我们注意。speed-measure-webpack-plugin
插件能够测量 Webpack 构建速度居然达到了惊人的 38.3 秒,虽然有点不是很准确,但是非常慢。发现
babel-loader、eslint-loader、css-loader、less-loader
占据了大头。打包体积分析
通过
webpack-bundle-analyzer
插件能够在Webpack
构建结束后生成构建产物体积报告,配合可视化的页面,能够直观知道产物中的具体占用体积。效果图如下:
可以看出一个很明显的问题就是
Ant Design、TRTC、Mobx
这些库,没有排除。打包体积如下:
如何优化
缩小构建目标
resolve.modules
配置(减少模块搜索层级和不必要的编译工作)resolve.extensions
配置使用 thread-loader,开启多进程
thread-loader
会将你的loader
放置在一个worker
池里面运行,每个worker
都是一个单独的有 600ms 限制的node.js
进程。同时跨进程的数据交换也会被限制。请在高开销的loader
中使用,否则效果不佳。使用 hard-source-webpack-plugin
在
Webpack4
中,hard-source-webpack-plugin
是DLL
的更好替代者。hard-source-webpack-plugin
是Webpack
的插件,为模块提供中间缓存步骤。为了查看结果,您需要使用此插件运行Webpack
两次:第一次构建将花费正常的时间。第二次构建将显着加快(大概提升 90% 的构建速度)。不过该插件很久没更新了,不太建议使用。去掉 eslint-loader
由于我项目中使用了
eslint-loader
如果配置了precommit
,其实可以去掉的。通过 externals 把相关的包,排除
Webpack
index.html
JS 压缩
从
Webpack4
开始,默认情况下使用terser
压缩生产环境下的输出结果。Terser
是一款兼容ES2015 +
的JavaScript
压缩器。与UglifyJS
(许多项目的早期标准)相比,它是面向未来的选择。有一个UglifyJS
的分支——uglify-es
,但由于它不再维护,于是就从这个分支诞生出了一个独立分支,它就是terser
。CSS 压缩
Webpack
4.0 以后,官方推荐使用mini-css-extract-plugin
插件来打包CSS
文件。FAQ
Ant Design 无法加载
请确保加载顺序,
Moment、Polyfill
放在Ant Design
前面加载MobX 无法加载
MobX
引入mobx.umd.min.js
库,mobx-react
需要引入package.json
最终效果
打包体积:
打包体积由原先 2.1M 变成了 882KB,可以说效果非常巨大。
包依赖:
Ant Design、TRTC、Mobx
这些库也没了编译速度:
编译速度由原先 38.3 secs(实际编译速度大概 15 秒左右),减少到 10.67 secs(实际编译速度 10 秒左右)。
国内外公共 CDN 地址
参考资料
博客
博客