|
(給前端大全加星標(biāo),提升前端技能) 作者:前端森林 公號 / 前端森林
引言webpack的打包優(yōu)化一直是個老生常談的話題,常規(guī)的無非就分塊、拆包、壓縮等。
本文以我自己的經(jīng)驗(yàn)向大家分享如何通過一些分析工具、插件以及webpack新版本中的一些新特性來顯著提升webpack的打包速度和改善包體積,學(xué)會分析打包的瓶頸以及問題所在。 本文演示代碼,倉庫地址:https://github.com/Jack-cool/webpack4 速度分析 ??webpack 有時候打包很慢,而我們在項(xiàng)目中可能用了很多的 plugin 和 loader,想知道到底是哪個環(huán)節(jié)慢,下面這個插件可以計算 plugin 和 loader 的耗時。 yarn add -D speed-measure-webpack-plugin
配置也很簡單,把 webpack 配置對象包裹起來即可: const SpeedMeasurePlugin = require('speed-measure-webpack-plugin');
const smp = new SpeedMeasurePlugin();
const webpackConfig = smp.wrap({ plugins: [ new MyPlugin(), new MyOtherPlugin() ] });
來看下在項(xiàng)目中引入speed-measure-webpack-plugin后的打包情況: 從上圖可以看出這個插件主要做了兩件事情: - 分析每個插件和 loader 的耗時情況 知道了具體
loader和plugin的耗時情況,我們就可以“對癥下藥”了
體積分析 ??打包后的體積優(yōu)化是一個可以著重優(yōu)化的點(diǎn),比如引入的一些第三方組件庫過大,這時就要考慮是否需要尋找替代品了。 這里采用的是webpack-bundle-analyzer,也是我平時工作中用的最多的一款插件了。 它可以用交互式可縮放樹形圖顯示webpack輸出文件的大小。用起來非常的方便。 首先安裝插件: yarn add -D webpack-bundle-analyzer
安裝完在webpack.config.js中簡單的配置一下: const BundleAnalyzerPlugin = require('webpack-bundle-analyzer').BundleAnalyzerPlugin;
module.exports = { plugins: [ new BundleAnalyzerPlugin({ // 可以是`server`,`static`或`disabled`。 // 在`server`模式下,分析器將啟動HTTP服務(wù)器來顯示軟件包報告。 // 在“靜態(tài)”模式下,會生成帶有報告的單個HTML文件。 // 在`disabled`模式下,你可以使用這個插件來將`generateStatsFile`設(shè)置為`true`來生成Webpack Stats JSON文件。 analyzerMode: 'server', // 將在“服務(wù)器”模式下使用的主機(jī)啟動HTTP服務(wù)器。 analyzerHost: '127.0.0.1', // 將在“服務(wù)器”模式下使用的端口啟動HTTP服務(wù)器。 analyzerPort: 8866, // 路徑捆綁,將在`static`模式下生成的報告文件。 // 相對于捆綁輸出目錄。 reportFilename: 'report.html', // 模塊大小默認(rèn)顯示在報告中。 // 應(yīng)該是`stat`,`parsed`或者`gzip`中的一個。 // 有關(guān)更多信息,請參見“定義”一節(jié)。 defaultSizes: 'parsed', // 在默認(rèn)瀏覽器中自動打開報告 openAnalyzer: true, // 如果為true,則Webpack Stats JSON文件將在bundle輸出目錄中生成 generateStatsFile: false, // 如果`generateStatsFile`為`true`,將會生成Webpack Stats JSON文件的名字。 // 相對于捆綁輸出目錄。 statsFilename: 'stats.json', // stats.toJson()方法的選項(xiàng)。 // 例如,您可以使用`source:false`選項(xiàng)排除統(tǒng)計文件中模塊的來源。 // 在這里查看更多選項(xiàng):https: //github.com/webpack/webpack/blob/webpack-1/lib/Stats.js#L21 statsOptions: null, logLevel: 'info' ) ] }
然后在命令行工具中輸入npm run dev,它默認(rèn)會起一個端口號為 8888 的本地服務(wù)器: 圖中的每一塊清晰的展示了組件、第三方庫的代碼體積。 有了它,我們就可以針對體積偏大的模塊進(jìn)行相關(guān)優(yōu)化了。 多進(jìn)程/多實(shí)例構(gòu)建 ??大家都知道 webpack 是運(yùn)行在 node 環(huán)境中,而 node 是單線程的。webpack 的打包過程是 io 密集和計算密集型的操作,如果能同時 fork 多個進(jìn)程并行處理各個任務(wù),將會有效的縮短構(gòu)建時間。 平時用的比較多的兩個是thread-loader和HappyPack。 先來看下thread-loader吧,這個也是webpack4官方所推薦的。 thread-loader
安裝yarn add -D thread-loader
thread-loader 會將你的 loader 放置在一個 worker 池里面運(yùn)行,以達(dá)到多線程構(gòu)建。
?把這個 loader 放置在其他 loader 之前(如下面示例的位置), 放置在這個 loader 之后的 loader 就會在一個單獨(dú)的 worker 池(worker pool)中運(yùn)行。 ? 示例module.exports = { module: { rules: [ { test: /\.js$/, include: path.resolve('src'), use: [ 'thread-loader', // your expensive loader (e.g babel-loader) ] } ] } }
HappyPack安裝yarn add -D happypack
HappyPack 可以讓 Webpack 同一時間處理多個任務(wù),發(fā)揮多核 CPU 的能力,將任務(wù)分解給多個子進(jìn)程去并發(fā)的執(zhí)行,子進(jìn)程處理完后,再把結(jié)果發(fā)送給主進(jìn)程。通過多進(jìn)程模型,來加速代碼構(gòu)建。
示例// webpack.config.js const HappyPack = require('happypack');
exports.module = { rules: [ { test: /.js$/, // 1) replace your original list of loaders with 'happypack/loader': // loaders: [ 'babel-loader?presets[]=es2015' ], use: 'happypack/loader', include: [ /* ... */ ], exclude: [ /* ... */ ] } ] };
exports.plugins = [ // 2) create the plugin: new HappyPack({ // 3) re-add the loaders you replaced above in #1: loaders: [ 'babel-loader?presets[]=es2015' ] }) ];
這里有一點(diǎn)需要說明的是,HappyPack的作者表示已不再維護(hù)此項(xiàng)目,這個可以在github倉庫看到: 作者也是推薦使用webpack官方提供的thread-loader。 ?thread-loader 和 happypack 對于小型項(xiàng)目來說打包速度幾乎沒有影響,甚至可能會增加開銷,所以建議盡量在大項(xiàng)目中采用。 ? 多進(jìn)程并行壓縮代碼 ??通常我們在開發(fā)環(huán)境,代碼構(gòu)建時間比較快,而構(gòu)建用于發(fā)布到線上的代碼時會添加壓縮代碼這一流程,則會導(dǎo)致計算量大耗時多。 webpack默認(rèn)提供了UglifyJS插件來壓縮JS代碼,但是它使用的是單線程壓縮代碼,也就是說多個js文件需要被壓縮,它需要一個個文件進(jìn)行壓縮。所以說在正式環(huán)境打包壓縮代碼速度非常慢(因?yàn)閴嚎sJS代碼需要先把代碼解析成用Object抽象表示的AST語法樹,再應(yīng)用各種規(guī)則分析和處理AST,導(dǎo)致這個過程耗時非常大)。
所以我們要對壓縮代碼這一步驟進(jìn)行優(yōu)化,常用的做法就是多進(jìn)程并行壓縮。 目前有三種主流的壓縮方案: parallel-uglify-plugin
上面介紹的HappyPack的思想是使用多個子進(jìn)程去解析和編譯JS,CSS等,這樣就可以并行處理多個子任務(wù),多個子任務(wù)完成后,再將結(jié)果發(fā)到主進(jìn)程中,有了這個思想后,ParallelUglifyPlugin 插件就產(chǎn)生了。 當(dāng)webpack有多個JS文件需要輸出和壓縮時,原來會使用UglifyJS去一個個壓縮并且輸出,而ParallelUglifyPlugin插件則會開啟多個子進(jìn)程,把對多個文件壓縮的工作分給多個子進(jìn)程去完成,但是每個子進(jìn)程還是通過UglifyJS去壓縮代碼。并行壓縮可以顯著的提升效率。 安裝yarn add -D webpack-parallel-uglify-plugin
示例import ParallelUglifyPlugin from 'webpack-parallel-uglify-plugin';
module.exports = { plugins: [ new ParallelUglifyPlugin({ // Optional regex, or array of regex to match file against. Only matching files get minified. // Defaults to /.js$/, any file ending in .js. test, include, // Optional regex, or array of regex to include in minification. Only matching files get minified. exclude, // Optional regex, or array of regex to exclude from minification. Matching files are not minified. cacheDir, // Optional absolute path to use as a cache. If not provided, caching will not be used. workerCount, // Optional int. Number of workers to run uglify. Defaults to num of cpus - 1 or asset count (whichever is smaller) sourceMap, // Optional Boolean. This slows down the compilation. Defaults to false. uglifyJS: { // These pass straight through to uglify-js@3. // Cannot be used with uglifyES. // Defaults to {} if not neither uglifyJS or uglifyES are provided. // You should use this option if you need to ensure es5 support. uglify-js will produce an error message // if it comes across any es6 code that it can't parse. }, uglifyES: { // These pass straight through to uglify-es. // Cannot be used with uglifyJS. // uglify-es is a version of uglify that understands newer es6 syntax. You should use this option if the // files that you're minifying do not need to run in older browsers/versions of node. } }), ], };
?webpack-parallel-uglify-plugin已不再維護(hù),這里不推薦使用 ? uglifyjs-webpack-plugin
安裝yarn add -D uglifyjs-webpack-plugin
示例const UglifyJsPlugin = require('uglifyjs-webpack-plugin');
module.exports = { plugins: [ new UglifyJsPlugin({ uglifyOptions: { warnings: false, parse: {}, compress: {}, ie8: false }, parallel: true }) ] };
其實(shí)它和上面的parallel-uglify-plugin類似,也可通過設(shè)置parallel: true開啟多進(jìn)程壓縮。 terser-webpack-plugin
不知道你有沒有發(fā)現(xiàn):webpack4 已經(jīng)默認(rèn)支持 ES6語法的壓縮。 而這離不開terser-webpack-plugin。 安裝yarn add -D terser-webpack-plugin
示例const TerserPlugin = require('terser-webpack-plugin');
module.exports = { optimization: { minimize: true, minimizer: [ new TerserPlugin({ parallel: 4, }), ], }, };
預(yù)編譯資源模塊 ??什么是預(yù)編譯資源模塊?在使用webpack進(jìn)行打包時候,對于依賴的第三方庫,比如vue,vuex等這些不會修改的依賴,我們可以讓它和我們自己編寫的代碼分開打包,這樣做的好處是每次更改我本地代碼的文件的時候,webpack只需要打包我項(xiàng)目本身的文件代碼,而不會再去編譯第三方庫。 那么第三方庫在第一次打包的時候只打包一次,以后只要我們不升級第三方包的時候,那么webpack就不會對這些庫去打包,這樣的可以快速的提高打包的速度。其實(shí)也就是預(yù)編譯資源模塊。 webpack中,我們可以結(jié)合DllPlugin 和 DllReferencePlugin插件來實(shí)現(xiàn)。
DllPlugin是什么?
它能把第三方庫代碼分離開,并且每次文件更改的時候,它只會打包該項(xiàng)目自身的代碼。所以打包速度會更快。 DLLPlugin 插件是在一個額外獨(dú)立的webpack設(shè)置中創(chuàng)建一個只有dll的bundle,也就是說我們在項(xiàng)目根目錄下除了有webpack.config.js,還會新建一個webpack.dll.js文件。
webpack.dll.js的作用是把所有的第三方庫依賴打包到一個bundle的dll文件里面,還會生成一個名為 manifest.json文件。該manifest.json的作用是用來讓 DllReferencePlugin 映射到相關(guān)的依賴上去的。
DllReferencePlugin又是什么?
這個插件是在webpack.config.js中使用的,該插件的作用是把剛剛在webpack.dll.js中打包生成的dll文件引用到需要的預(yù)編譯的依賴上來。 什么意思呢?就是說在webpack.dll.js中打包后比如會生成 vendor.dll.js文件和vendor-manifest.json文件,vendor.dll.js文件包含了所有的第三方庫文件,vendor-manifest.json文件會包含所有庫代碼的一個索引,當(dāng)在使用webpack.config.js文件打包DllReferencePlugin插件的時候,會使用該DllReferencePlugin插件讀取vendor-manifest.json文件,看看是否有該第三方庫。 vendor-manifest.json文件就是一個第三方庫的映射而已。
怎么在項(xiàng)目中使用?上面說了這么多,主要是為了方便大家對于預(yù)編譯資源模塊和DllPlugin 和、DllReferencePlugin插件作用的理解(我第一次使用看了好久才明白~~) 先來看下完成的項(xiàng)目目錄結(jié)構(gòu): 主要在兩塊配置,分別是webpack.dll.js和webpack.config.js(對應(yīng)這里我是webpack.base.js) webpack.dll.js
const path = require('path'); const webpack = require('webpack');
module.exports = { mode: 'production', entry: { vendors: ['lodash', 'jquery'], react: ['react', 'react-dom'] }, output: { filename: '[name].dll.js', path: path.resolve(__dirname, './dll'), library: '[name]' }, plugins: [ new webpack.DllPlugin({ name: '[name]', path: path.resolve(__dirname, './dll/[name].manifest.json') }) ] }
這里我拆了兩部分:vendors(存放了lodash、jquery等)和react(存放了 react 相關(guān)的庫,react、react-dom等) webpack.config.js(對應(yīng)我這里就是webpack.base.js)
const path = require('path'); const fs = require('fs'); // ... const AddAssetHtmlWebpackPlugin = require('add-asset-html-webpack-plugin'); const webpack = require('webpack');
const plugins = [ // ... ];
const files = fs.readdirSync(path.resolve(__dirname, './dll')); files.forEach(file => { if(/.*\.dll.js/.test(file)) { plugins.push(new AddAssetHtmlWebpackPlugin({ filepath: path.resolve(__dirname, './dll', file) })) } if(/.*\.manifest.json/.test(file)) { plugins.push(new webpack.DllReferencePlugin({ manifest: path.resolve(__dirname, './dll', file) })) } })
module.exports = { entry: { main: './src/index.js' }, module: { rules: [] }, plugins,
output: { // publicPath: './', path: path.resolve(__dirname, 'dist') } }
這里為了演示省略了很多代碼,項(xiàng)目完整代碼在這里 由于上面我把第三方庫做了一個拆分,所以對應(yīng)生成也就會是多個文件,這里讀取了一下文件,做了一層遍歷。 最后在package.json里面再添加一條腳本就可以了: 'scripts': { 'build:dll': 'webpack --config ./webpack.dll.js', },
運(yùn)行yarn build:dll就會生成本小節(jié)開頭貼的那張項(xiàng)目結(jié)構(gòu)圖了~ 利用緩存提升二次構(gòu)建速度 ??一般來說,對于靜態(tài)資源,我們都希望瀏覽器能夠進(jìn)行緩存,那樣以后進(jìn)入頁面就可以直接使用緩存資源,頁面打開速度會顯著加快,既提高了用戶的體驗(yàn)也節(jié)省了寬帶資源。 當(dāng)然瀏覽器緩存方法有很多種,這里只簡單討論下在webpack中如何利用緩存來提升二次構(gòu)建速度。 在webpack中利用緩存一般有以下幾種思路: - 使用
hard-source-webpack-plugin
babel-loader
babel-loader在執(zhí)行的時候,可能會產(chǎn)生一些運(yùn)行期間重復(fù)的公共文件,造成代碼體積冗余,同時也會減慢編譯效率。
可以加上cacheDirectory參數(shù)開啟緩存: { test: /\.js$/, exclude: /node_modules/, use: [{ loader: 'babel-loader', options: { cacheDirectory: true } }], },
cache-loader
在一些性能開銷較大的 loader 之前添加此 loader,以將結(jié)果緩存到磁盤里。 安裝yarn add -D cache-loader
使用cache-loader 的配置很簡單,放在其他 loader 之前即可。修改Webpack 的配置如下:
// webpack.config.js module.exports = { module: { rules: [ { test: /\.ext$/, use: [ 'cache-loader', ...loaders ], include: path.resolve('src') } ] } }
?請注意,保存和讀取這些緩存文件會有一些時間開銷,所以請只對性能開銷較大的 loader 使用此 loader。 ? hard-source-webpack-plugin
HardSourceWebpackPlugin 為模塊提供了中間緩存,緩存默認(rèn)的存放路徑是: node_modules/.cache/hard-source。
配置 hard-source-webpack-plugin后,首次構(gòu)建時間并不會有太大的變化,但是從第二次開始,構(gòu)建時間大約可以減少 80%左右。 安裝yarn add -D hard-source-webpack-plugin
使用// webpack.config.js var HardSourceWebpackPlugin = require('hard-source-webpack-plugin');
module.exports = { entry: // ... output: // ... plugins: [ new HardSourceWebpackPlugin() ] }
?webpack5中會內(nèi)置hard-source-webpack-plugin。 ? 縮小構(gòu)建目標(biāo)/減少文件搜索范圍 ??有時候我們的項(xiàng)目中會用到很多模塊,但有些模塊其實(shí)是不需要被解析的。這時我們就可以通過縮小構(gòu)建目標(biāo)或者減少文件搜索范圍的方式來對構(gòu)建做適當(dāng)?shù)膬?yōu)化。 縮小構(gòu)建目標(biāo)主要是exclude 與 include的使用: // webpack.config.js const path = require('path'); module.exports = { ... module: { rules: [ { test: /\.js$/, exclude: /node_modules/, // include: path.resolve('src'), use: ['babel-loader'] } ] }
這里babel-loader就會排除對node_modules下對應(yīng) js 的解析,提升構(gòu)建速度。 減少文件搜索范圍這個主要是resolve相關(guān)的配置,用來設(shè)置模塊如何被解析。通過resolve的配置,可以幫助Webpack快速查找依賴,也可以替換對應(yīng)的依賴。 resolve.modules:告訴 webpack 解析模塊時應(yīng)該搜索的目錄resolve.mainFields:當(dāng)從 npm 包中導(dǎo)入模塊時(例如,import * as React from 'react'),此選項(xiàng)將決定在 package.json 中使用哪個字段導(dǎo)入模塊。根據(jù) webpack 配置中指定的 target 不同,默認(rèn)值也會有所不同resolve.mainFiles:解析目錄時要使用的文件名,默認(rèn)是indexresolve.extensions:文件擴(kuò)展名
// webpack.config.js const path = require('path'); module.exports = { ... resolve: { alias: { react: path.resolve(__dirname, './node_modules/react/umd/react.production.min.js') }, //直接指定react搜索模塊,不設(shè)置默認(rèn)會一層層的搜尋 modules: [path.resolve(__dirname, 'node_modules')], //限定模塊路徑 extensions: ['.js'], //限定文件擴(kuò)展名 mainFields: ['main'] //限定模塊入口文件名
動態(tài) Polyfill 服務(wù) ??介紹動態(tài)Polyfill前,我們先來看下什么是babel-polyfill。 什么是 babel-polyfill?babel只負(fù)責(zé)語法轉(zhuǎn)換,比如將ES6的語法轉(zhuǎn)換成ES5。但如果有些對象、方法,瀏覽器本身不支持,比如:
- 全局靜態(tài)函數(shù):
Array.from、Object.assign 等。 - 實(shí)例方法:比如
Array.prototype.includes 等。
此時,需要引入babel-polyfill來模擬實(shí)現(xiàn)這些對象、方法。 這種一般也稱為墊片。 怎么使用babel-polyfill?使用也非常簡單,在webpack.config.js文件作如下配置就可以了: module.exports = { entry: ['@babel/polyfill', './app/js'], };
為什么還要用動態(tài)Polyfill?babel-polyfill由于是一次性全部導(dǎo)入整個polyfill,所以用起來很方便,但與此同時也帶來了一個大問題:文件很大,所以后續(xù)的方案都是針對這個問題做的優(yōu)化。
來看下打包后babel-polyfill的占比: 占比 29.6%,有點(diǎn)太大了! 介于上述原因,動態(tài)Polyfill服務(wù)誕生了。通過一張圖來了解下Polyfill Service的原理: 每次打開頁面,瀏覽器都會向Polyfill Service發(fā)送請求,Polyfill Service識別 User Agent,下發(fā)不同的 Polyfill,做到按需加載Polyfill的效果。 怎么使用動態(tài)Polyfill服務(wù)?采用官方提供的服務(wù)地址即可: //訪問url,根據(jù)User Agent 直接返回瀏覽器所需的 polyfills https://polyfill.io/v3/polyfill.min.js
Scope Hoisting ??
什么是Scope Hoisting?Scope hoisting 直譯過來就是「作用域提升」。熟悉 JavaScript 都應(yīng)該知道「函數(shù)提升」和「變量提升」,JavaScript 會把函數(shù)和變量聲明提升到當(dāng)前作用域的頂部?!缸饔糜蛱嵘挂差愃朴诖?,webpack 會把引入的 js 文件“提升到”它的引入者頂部。
Scope Hoisting 可以讓 Webpack 打包出來的代碼文件更小、運(yùn)行的更快。
啟用Scope Hoisting要在 Webpack 中使用 Scope Hoisting 非常簡單,因?yàn)檫@是 Webpack 內(nèi)置的功能,只需要配置一個插件,相關(guān)代碼如下: // webpack.config.js const webpack = require('webpack')
module.exports = mode => { if (mode === 'production') { return {} }
return { devtool: 'source-map', plugins: [new webpack.optimize.ModuleConcatenationPlugin()], } }
啟用Scope Hoisting后的對比讓我們先來看看在沒有 Scope Hoisting 之前 Webpack 的打包方式。 假如現(xiàn)在有兩個文件分別是 export default 'Hello,Jack-cool';
import str from './constant.js'; console.log(str);
以上源碼用 Webpack 打包后的部分代碼如下: [ (function (module, __webpack_exports__, __webpack_require__) { var __WEBPACK_IMPORTED_MODULE_0__constant_js__ = __webpack_require__(1); console.log(__WEBPACK_IMPORTED_MODULE_0__constant_js__['a']); }), (function (module, __webpack_exports__, __webpack_require__) { __webpack_exports__['a'] = ('Hello,Jack-cool'); }) ]
在開啟 Scope Hoisting 后,同樣的源碼輸出的部分代碼如下: [ (function (module, __webpack_exports__, __webpack_require__) { var constant = ('Hello,Jack-cool'); console.log(constant); }) ]
從中可以看出開啟 Scope Hoisting 后,函數(shù)申明由兩個變成了一個,constant.js 中定義的內(nèi)容被直接注入到了 main.js 對應(yīng)的模塊中。這樣做的好處是: - 代碼體積更小,因?yàn)楹瘮?shù)申明語句會產(chǎn)生大量代碼;
- 代碼在運(yùn)行時因?yàn)閯?chuàng)建的函數(shù)作用域更少了,內(nèi)存開銷也隨之變小。
Scope Hoisting 的實(shí)現(xiàn)原理其實(shí)很簡單:分析出模塊之間的依賴關(guān)系,盡可能的把打散的模塊合并到一個函數(shù)中去,但前提是不能造成代碼冗余。因此只有那些被引用了一次的模塊才能被合并。
?由于 Scope Hoisting 需要分析出模塊之間的依賴關(guān)系,因此源碼必須采用 ES6 模塊化語句,不然它將無法生效。 ? 參考極客時間 【玩轉(zhuǎn) webpack】 - EOF -
|