本文介紹了React + Webpack 構(gòu)建打包優(yōu)化，分享給大家，具體如下：

使用 babel-react-optimize 對(duì) React 代碼進(jìn)行優(yōu)化

檢查沒有使用的庫，去除 import 引用

按需打包所用的類庫，比如 lodash 、 echart 等

lodash 可以采用babel-plugin-lodash 進(jìn)行優(yōu)化。

需要注意的是

在 babel-react-optimize 中使用了 babel-plugin-transform-react-remove-prop-types 這個(gè)插件。正常情況下，如果你在代碼中沒有引用到組件的 PropTypes ，則完全沒問題。如果你的組件用到了，那么使用該插件可能會(huì)導(dǎo)致問題。

具體見：

https://github.com/oliviertassinari/babel-plugin-transform-react-remove-prop-types#is-it-safe

Webpack 構(gòu)建打包優(yōu)化

Webpack 構(gòu)建打包存在的問題主要集中于下面兩個(gè)方面：

1. Webpack 構(gòu)建速度慢
2. Webpack 打包后的文件體積過大

Webpack 構(gòu)建速度慢

可以使用 Webpack.DDLPlugin ， HappyPack 來提高構(gòu)建速度。具體參見小銘在 DMP DDLPlugin 的文檔。原文如下：

Webpack.DLLPlugin

添加一個(gè) webpack.dll.config.js
主要是用到一個(gè) DllPlugin 插件，把一些第三方的資源獨(dú)立打包，同時(shí)放到一個(gè) manifest.json 配置文件中，

這樣在組件中更新后，就不會(huì)重新 build 這些第三方的資源，

1. 同時(shí)獨(dú)立配置 dll/vendors.js 文件，提供給 webpack.dll.config.js
2. 修改 package.json

在 scripts 中添加: "dll": "webpack --config webpack.dll.config.js --progress --colors ", 。

執(zhí)行 npm run dll 以后，會(huì)在 dll 目錄下生產(chǎn) 兩個(gè)文件 vendor-manifest.json ，vendor.dll.js

配置 webpack.dev.config.js 文件，加入一個(gè) DllReferencePlugin 插件，并指定 vendor-manifest.json 文件

new webpack.DllReferencePlugin({
 context: join(__dirname, 'src'),
 manifest: require('./dll/vendor-manifest.json')
})

修改 html

<% if(htmlWebpackPlugin.options.NODE_ENV ==='development'){ %>
 <script src="dll/vendor.dll.js"></script>
<% } %>

注意，需要在 htmlWebpackPlugin 插件中配置 NODE_ENV 參數(shù)

Happypack

通過多線程，緩存等方式提升 rebuild 效率 https://github.com/amireh/happypack

在 webpack.dev.config.js 中針對(duì)不同的資源創(chuàng)建多個(gè) HappyPack, 比如 js 1 個(gè)，less 1 個(gè)，并設(shè)置好 id

new HappyPack({
 id: 'js',
 threadPool: happyThreadPool,
 cache: true,
 verbose: true,
 loaders: ['babel-loader?babelrc&cacheDirectory=true'],
}),
new HappyPack({
 id: 'less',
 threadPool: happyThreadPool,
 cache: true,
 verbose: true,
 loaders: ['css-loader', 'less-loader'],
})

在 module.rules 中配置 use 為 happypack/loader， 設(shè)置 id

{
 test: /\.js$/,
 use: [
 'happypack/loader?id=js'
 ],
 exclude: /node_modules/
}, {
 test: /\.less$/,
 loader: extractLess.extract({
 use: ['happypack/loader?id=less'],
 fallback: 'style-loader'
 })
}

減少 Webpack 打包后的文件體積大小

首先需要對(duì)我們整個(gè) bundle 進(jìn)行分析，由哪些東西組成及各組成部分所占大小。

這里推薦 webpack-bundle-analyzer 。安裝后在 webpack.dev.config.js 中添加插件即可，就能在每次啟動(dòng)后自動(dòng)在網(wǎng)站打開分析結(jié)果，如下圖

plugins.push( new BundleAnalyzerPlugin());

除此之外，還可以將打包過程輸出成json文件

webpack --profile --json -> stats.json

然后到下面這兩個(gè)網(wǎng)站進(jìn)行分析

1. webpack/analyse
2. Webpack Chart

通過上面的圖表分析可以清楚得看到，整個(gè) bundle.js 的組成部分及對(duì)應(yīng)的大小。

解決 bundle.js 體積過大的解決思路如下：

1. 生產(chǎn)環(huán)境啟用壓縮等插件，去除不必要插件
2. 拆分業(yè)務(wù)代碼與第三方庫及公共模塊
3. webpack 開啟 gzip 壓縮
4. 按需加載

生產(chǎn)環(huán)境啟用壓縮等插件，去除不必要插件

確保在生產(chǎn)環(huán)境啟動(dòng) webpack.DefinePlugin 和 webpack.optimize.UglifyJsPlugin 。

const plugins = [
 new webpack.DefinePlugin({
  'process.env.NODE_ENV': JSON.stringify(process.env.NODE_ENV || 'production')
 }),
  new webpack.optimize.UglifyJsPlugin({
  compress: {
   warnings: false,
   drop_console: false //eslint-disable-line
  }
  })   
]

拆分業(yè)務(wù)代碼與第三方庫及公共模塊

由于項(xiàng)目的業(yè)務(wù)代碼變更頻率很高，而第三方庫的代碼變化則相對(duì)沒有那么頻率。如果將業(yè)務(wù)代碼和第三庫打包到同一個(gè) chunk 的話，在每次構(gòu)建的時(shí)候，哪怕業(yè)務(wù)代碼只改了一行，即使第三方庫的代碼沒有發(fā)生變化，會(huì)導(dǎo)致整個(gè) chunk 的 hash 跟上一次不同。這不是我們想要的結(jié)果。我們想要的是，如果第三方庫的代碼沒有變化，那在構(gòu)建的時(shí)候也要保證對(duì)應(yīng)的 hash 沒有發(fā)生變化，從而能利用瀏覽器緩存，更好的提高頁面加載性能和縮短頁面加載時(shí)間。

因此可以將第三庫的代碼單獨(dú)拆分成 vendor chunk，與業(yè)務(wù)代碼分離。這樣就算業(yè)務(wù)代碼再怎么發(fā)生變化，只要第三方庫代碼沒有發(fā)生變化，對(duì)應(yīng)的 hash 就不變。

首先 entry 配置兩個(gè) app 和 vendor 兩個(gè)chunk

entry: {
 vendor: [path.join(__dirname, 'dll', 'vendors.js')],
 app: [path.join(__dirname, 'src/index')]
},
output: {
 path: path.resolve(__dirname, 'build'),
 filename: '[name].[chunkhash:8].js'
},

其中 vendros.js 是自己定義的哪些第三方庫需要納入 vendor 中，如下：

require('babel-polyfill');
require('classnames');
require('intl');
require('isomorphic-fetch');
require('react');
require('react-dom');
require('immutable');
require('redux');

然后通過 CommonsChunkPlugin 拆分第三庫

plugins.push(
 // 拆分第三方庫
 new webpack.optimize.CommonsChunkPlugin({ name: 'vendor' }),
 // 拆分 webpack 自身代碼
 new webpack.optimize.CommonsChunkPlugin({
  name: 'runtime',
  minChunks: Infinity
 })
);

上面的配置有兩個(gè)細(xì)節(jié)需要注意

1. 使用 chunkhash 而不用 hash
2. 單獨(dú)拆分 webpack 自身代碼

使用 chunkhash 而不用 hash

先來看看這二者有何區(qū)別：

1. hash 是 build-specific ，任何一個(gè)文件的改動(dòng)都會(huì)導(dǎo)致編譯的結(jié)果不同，適用于開發(fā)階段
2. chunkhash 是 chunk-specific ，是根據(jù)每個(gè) chunk 的內(nèi)容計(jì)算出的 hash，適用于生產(chǎn)

因此為了保證第三方庫不變的情況下，對(duì)應(yīng)的 vendor.js 的 hash 也要保持不變，我們?cè)?output.filename 中采用了 chunkhash

單獨(dú)拆分 webpack 自身代碼

Webpack 有個(gè)已知問題：

webpack 自身的 boilerplate 和 manifest 代碼可能在每次編譯時(shí)都會(huì)變化。

這導(dǎo)致我們只是在 入口文件 改了一行代碼，但編譯出的 vendor 和 entry chunk 都變了，因?yàn)樗鼈冏陨矶及@部分代碼。

這是不合理的，因?yàn)閷?shí)際上我們的第三方庫的代碼沒變，vendor 不應(yīng)該在我們業(yè)務(wù)代碼變化時(shí)發(fā)生變化。

因此我們需要將 webpack 這部分代碼分離抽離

new webpack.optimize.CommonsChunkPlugin({
   name: "runtime",
   minChunks: Infinity
}),

其中的 name 只要不在 entry 即可，通常使用 "runtime" 或 "manifest" 。

另外一個(gè)參數(shù) minChunks 表示：在傳入公共chunk(commons chunk) 之前所需要包含的最少數(shù)量的 chunks。數(shù)量必須大于等于2，或者少于等于 chunks的數(shù)量，傳入 Infinity 會(huì)馬上生成 公共chunk，但里面沒有模塊。

更多關(guān)于 CommonChunkPlugin 可以查看 官方文檔

拆分公共資源

同 上面的拆分第三方庫一樣，拆分公共資源可以將公用的模塊單獨(dú)打出一個(gè) chunk，你可以設(shè)置 minChunk 來選擇是共用多少次模塊才將它們抽離。配置如下：

new webpack.optimize.CommonsChunkPlugin({
 name: 'common',
 minChunks: 2,
}),

是否需要進(jìn)行這一步優(yōu)化可以自行根據(jù)項(xiàng)目的業(yè)務(wù)復(fù)用度來判斷。

開啟 gzip

使用 CompressionPlugin 插件開啟 gzip 即可：

// 添加 gzip
new CompressionPlugin({
 asset: '[path].gz[query]',
 algorithm: 'gzip',
 test: /\.(js|html)$/,
 threshold: 10240,
 minRatio: 0.8
})

以上就是本文的全部內(nèi)容，希望對(duì)大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。

最新評(píng)論