-
Notifications
You must be signed in to change notification settings - Fork 890
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Day108:Webpack 为什么慢,如何进行优化 #921
Comments
一、webpack 为什么慢webpack是所谓的模块捆绑器,内部有循环引用来分析模块间之间的依赖,把文件解析成AST,通过一系类不同loader的加工,最后全部打包到一个js文件里。 webpack4以前在打包速度上没有做过多的优化手段,编译慢的大部分时间是花费在不同loader编译过程,webpack4以后,吸收借鉴了很多优秀工具的思路, 如支持0配置,多线程等功能,速度也大幅提升,但依然有一些优化手段。如合理的代码拆分,公共代码的提取,css资源的抽离 二、优化 Webpack 的构建速度
三、使用Webpack4带来的优化
来看下具体使用 1.noParse
module.exports = {
module: {
noParse: /jquery/,
rules:[]
}
} 2.IgnorePlugin
module.exports = {
plugins: [
new Webpack.IgnorePlugin(/\.\/local/, /moment/),
]
} 3.dillPlugin
4.happypack -> thread-loader
5.thread-loaderthread-loader 会将您的 loader 放置在一个 worker 池里面运行,以达到多线程构建。 把这个 loader 放置在其他 loader 之前,放置在这个 loader 之后的 loader 就会在一个单独的 worker 池(worker pool)中运行。 // webpack.config.js
module.exports = {
module: {
rules: [
{
test: /\.js$/,
include: path.resolve("src"),
use: [
"thread-loader",
// 你的高开销的loader放置在此 (e.g babel-loader)
]
}
]
}
} 每个 worker 都是一个单独的有 600ms 限制的 node.js 进程。同时跨进程的数据交换也会被限制。请在高开销的loader中使用,否则效果不佳 6.压缩加速——开启多线程压缩不推荐使用 webpack-paralle-uglify-plugin,项目基本处于没人维护的阶段,issue 没人处理,pr没人合并。 Webpack 4.0以前:uglifyjs-webpack-plugin,parallel参数 module.exports = {
optimization: {
minimizer: [
new UglifyJsPlugin({
parallel: true,
}),
],
},}; 推荐使用 terser-webpack-plugin module.exports = {
optimization: {
minimizer: [new TerserPlugin(
parallel: true // 多线程
)],
},
}; |
扫描下方二维码,收藏关注,及时获取答案以及详细解析,同时可解锁800+道前端面试题。
The text was updated successfully, but these errors were encountered: