这篇文章由Cloud+Community发布大量的发帖时间。thread-loaderthread-loader会把你的loader放在一个workerpool中运行，实现多线程构建。将此加载器放在其他加载器之前（如下例所示），此加载器之后的加载器将在单独的工作池中运行。安装$npminstall--save-devthread-loaderusageandexmaple//webpack.config.jsmodule.exports={module:{rules:[{test:/\.js$/,include:path.resolve("src"),use:["thread-loader",//在这里放置你的高开销加载器（例如babel-loader）]}]}每个worker都是一个独立的node.js进程，有600毫秒的限制。同时，跨进程的数据交换也会受到限制。请在高开销的loader中使用，否则效果不佳。更多配置请查看：https://github.com/webpack-co...happypackhappypack通过多进程模型加速代码构建。从github上的启动数来看，happypack使用人数较多，比较受欢迎。原理相关的技术原理这里不再赘述。可以查看淘宝FEDhappypack原理分析用法和例子的相关文章varHappyPack=require('happypack');varhappyThreadPool=HappyPack.ThreadPool({size:os.cpus().length});//...省略配置模块的其余部分：{loaders:[{test:/\.less$/,loader:ExtractTextPlugin.extract('style',path.resolve(__dirname,'./node_modules','happypack/loader')+'?id=less')}]},插件:[newHappyPack({id:'less',loaders:['css!less'],threadPool:happyThreadPool,cache:true,verbose:true})]构造方法总结从实际使用来看，thread-loader和happypack对小项目的打包速度几乎没有影响，因为它们本身有额外的开销，比如I/O，所以建议只在大型项目中使用它，你可以在投入生产环境之前对其进行测试。压缩不推荐使用webpack-parallel-uglify-plugin项目基本处于无人维护，无人处理issue，无人合并pr的阶段。推荐使用terser-webpack-pluginterser-webpack-plugin是一个使用terser压缩js的webpack插件。压缩是发布前最耗时的步骤。如果您使用的是webpack4，只需几行代码即可加快构建和发布速度。用法和示例constTerserPlugin=require('terser-webpack-plugin');module.exports={优化：{最小化器：[newTerserPlugin(parallel:true//多线程)],},};有关更多用法，请参见上面的链接。总结随着webpack4的优化，构建速度其实有了很大的提升，同时也受到parcel等零配置web应用打包工具的启发。其实webpack的配置越来越简洁了。为什么不尝试配置它呢？本文已由腾讯云+社区在各渠道发布获取更多新鲜技术干货，可以关注我们的腾讯云技术社区-云家社区公众号和知乎代理号
