How to optimize packaging using React and Webpack?

This article mainly introduces a brief discussion of React Webpack construction and packaging optimization. Now I share it with you and give you a reference.

This article introduces the React Webpack construction and packaging optimization and shares it with you. The details are as follows:

Use babel-react-optimize to optimize React code

Check unused libraries and remove import references

Package used libraries on demand, such as lodash and echart Wait

lodash can be optimized using babel-plugin-lodash.

It should be noted that

The babel-plugin-transform-react-remove-prop-types plugin is used in babel-react-optimize. Normally, if you don't reference the component's PropTypes in your code, it's totally fine. Using this plugin may cause problems if your component uses it.

See:

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

Webpack build and package optimization

The problems in Webpack build and package mainly focus on the following two aspects:

1. Webpack build speed is slow

2. The file size after Webpack package is too large

Webpack build speed is slow

You can use Webpack.DDLPlugin, HappyPack to improve build speed. For details, please refer to Xiaoming’s documentation on DMP DDLPlugin. The original text is as follows:

Webpack.DLLPlugin

Adding a webpack.dll.config.js
mainly uses a DllPlugin plug-in to independently package some third-party resources and place them at the same time In a manifest.json configuration file,

In this way, after updating in the component, these third-party resources will not be rebuilt,

1. At the same time, configure dll/vendors independently .js file, provided to webpack.dll.config.js

2. Modify package.json

Add: "dll": "webpack --config webpack.dll.config.js --progress --colors ", .

After executing npm run dll, two files vendor-manifest.json and vendor.dll.js will be produced in the dll directory.

Configure the webpack.dev.config.js file and add one DllReferencePlugin plug-in, and specify the vendor-manifest.json file

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

Modify html

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

Note that you need to configure the NODE_ENV parameter in the htmlWebpackPlugin plug-in

Happypack

Improve rebuild efficiency through multi-threading, caching, etc. https://github.com/amireh/happypack

Create multiple HappyPacks for different resources in webpack.dev.config.js , For example, 1 js, 1 less, and set the 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'],
})

Configure use as happypack/loader in module.rules, set the id

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

to reduce the number of Webpack packages File size

First we need to analyze our entire bundle, what it consists of and the size of each component.

Webpack-bundle-analyzer is recommended here. After installation, just add the plug-in in webpack.dev.config.js, and the analysis results will be automatically opened on the website after each startup, as shown below

plugins.push( new BundleAnalyzerPlugin());

Except In addition, you can also output the packaging process into a json file

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

and then go to the following two websites for analysis

1. webpack/analyse

2. Webpack Chart

Through the above chart analysis, we can clearly see the components and corresponding sizes of the entire bundle.js.

The solution to the excessive size of bundle.js is as follows:

1. Enable compression and other plug-ins in the production environment and remove unnecessary plug-ins

2. Split business code and third-party libraries and public modules

3. webpack Turn on gzip compression

4. Load on demand

Enable compression and other plug-ins in the production environment, and remove unnecessary plug-ins.

Make sure to start webpack.DefinePlugin and webpack.optimize.UglifyJsPlugin in the production environment.

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
  }
  })   
]

Split business code and third-party libraries and public modules

Because the project's business code changes frequently, the code changes of the third-party library are relatively unchanged. So frequency. If the business code and the third library are packaged into the same chunk, at each build, even if the business code only changes one line, even if the code of the third-party library does not change, the hash of the entire chunk will be different from the last time. . This is not the result we want. What we want is that if the code of the third-party library does not change, then we must ensure that the corresponding hash does not change when building, so that we can use the browser cache to better improve page loading performance and shorten page loading time.

Therefore, the code of the third library can be split into vendor chunks separately and separated from the business code. In this way, no matter how the business code changes, as long as the third-party library code does not change, the corresponding hash will remain unchanged.

First, the entry configures two apps and two vendor chunks

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 is your own definition of which third-party libraries need to be included in the vendor, as follows:

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

Then split the third library through CommonsChunkPlugin

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

上面的配置有两个细节需要注意

1. 使用 chunkhash 而不用 hash

2. 单独拆分 webpack 自身代码

使用 chunkhash 而不用 hash

先来看看这二者有何区别：

1. hash 是 build-specific ，任何一个文件的改动都会导致编译的结果不同，适用于开发阶段

2. chunkhash 是 chunk-specific ，是根据每个 chunk 的内容计算出的 hash，适用于生产

因此为了保证第三方库不变的情况下，对应的 vendor.js 的 hash 也要保持不变，我们再 output.filename 中采用了 chunkhash

单独拆分 webpack 自身代码

Webpack 有个已知问题：

webpack 自身的 boilerplate 和 manifest 代码可能在每次编译时都会变化。

这导致我们只是在 入口文件 改了一行代码，但编译出的 vendor 和 entry chunk 都变了，因为它们自身都包含这部分代码。

这是不合理的，因为实际上我们的第三方库的代码没变，vendor 不应该在我们业务代码变化时发生变化。

因此我们需要将 webpack 这部分代码分离抽离

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

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

另外一个参数 minChunks 表示：在传入公共chunk(commons chunk) 之前所需要包含的最少数量的 chunks。数量必须大于等于2，或者少于等于 chunks的数量，传入 Infinity 会马上生成 公共chunk，但里面没有模块。

拆分公共资源

同 上面的拆分第三方库一样，拆分公共资源可以将公用的模块单独打出一个 chunk，你可以设置 minChunk 来选择是共用多少次模块才将它们抽离。配置如下：

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

是否需要进行这一步优化可以自行根据项目的业务复用度来判断。

开启 gzip

使用 CompressionPlugin 插件开启 gzip 即可：

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

上面是我整理给大家的，希望今后会对大家有帮助。

相关文章：

使用Vue如何实现拦截器对token处理方法有哪些？

使用js和jQuery如何实现指定赋值方法

有关Vue中如何换肤？

The above is the detailed content of How to optimize packaging using React and Webpack?. For more information, please follow other related articles on the PHP Chinese website!