本文由雲+社區發表做者:志航css
影響前端發佈速度的有兩個方面,一個是構建,一個就是壓縮,把這兩個東西優化起來,能夠減小不少發佈的時間。前端
thread-loader 會將您的 loader
放置在一個 worker 池裏面運行,以達到多線程構建。 node
把這個 loader 放置在其餘 loader 以前(以下圖 example 的位置), 放置在這個 loader 以後的 loader 就會在一個單獨的 worker 池(worker pool)中運行。webpack
$ npm install --save-dev thread-loader
// 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中使用,不然效果不佳git
更多配置請查看: https://github.com/webpack-co...github
happypack,經過多進程模型,來加速代碼構建。從 github 的 starts 數量來看,happypack 使用的人數比較多,比較受歡迎。web
相關的技術原理這裏再也不累贅,能夠查看淘寶FED的相關文章 happypack 原理解析npm
var HappyPack = require('happypack'); var happyThreadPool = HappyPack.ThreadPool({ size: os.cpus().length }); // ... 省略其他配置 module: { loaders: [ { test: /\.less$/, loader: ExtractTextPlugin.extract( 'style', path.resolve(__dirname, './node_modules', 'happypack/loader') + '?id=less' ) } ] }, plugins: [ new HappyPack({ id: 'less', loaders: ['css!less'], threadPool: happyThreadPool, cache: true, verbose: true }) ]
從實際使用的狀況來看,thread-loader 和 happypack 對於小型項目來講打包速度幾乎沒有影響,是由於它自己的額外開銷,例如I/O,建議只在大型項目中使用,能夠先測試再投入生產環境。babel
項目基本處於沒人維護的階段,issue 沒人處理,pr沒人合併。多線程
terser-webpack-plugin 是一個使用 terser 壓縮js的webpack 插件。
壓縮是發佈前處理最耗時間的一個步驟,若是是你是在webpack 4 中,只要幾行代碼,便可加速你的構建發佈速度。
const TerserPlugin = require('terser-webpack-plugin'); module.exports = { optimization: { minimizer: [new TerserPlugin( parallel: true // 多線程 )], }, };
更多用法請查看上面連接。
隨着 webpack 4 的優化,構建速度其實獲得了極大的提高,也收到了parcel 等零配置Web應用打包工具的啓發,其實 webpack 的配置日趨簡潔,何不嘗試配置一下呢?
此文已由騰訊雲+社區在各渠道發佈
獲取更多新鮮技術乾貨,能夠關注咱們騰訊雲技術社區-雲加社區官方號及知乎機構號