Comment optimiser le packaging avec React et Webpack ?

Cet article présente principalement la construction et l'optimisation du packaging de React + Webpack. Maintenant, je vais le partager avec vous et vous donner une référence.

Cet article présente la construction et l'optimisation du packaging de React + Webpack. avec vous en détail. Comme suit :

Utilisez babel-react-optimize pour optimiser le code React

Vérifiez les bibliothèques inutilisées et supprimez les références d'importation

Emballez les bibliothèques de classes utilisées comme nécessaires, comme lodash , echart, etc.

lodash peut être optimisé à l'aide de babel-plugin-lodash.

Il est à noter que

utilise le plugin babel-plugin-transform-react-remove-prop-types dans babel-react-optimize. Normalement, si vous ne faites pas référence aux PropTypes du composant dans votre code, tout va bien. L'utilisation de ce plugin peut poser des problèmes si votre composant l'utilise.

Pour plus de détails, voir :

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

Build et optimisation du package Webpack

Les problèmes liés à la build et au package Webpack se concentrent principalement sur les deux aspects suivants :

1. La vitesse de build du Webpack est lent

2. La taille du fichier après l'emballage du Webpack est trop grande

La vitesse de construction du Webpack est lente

Vous pouvez utiliser Webpack.DDLPlugin, HappyPack pour améliorer la vitesse de construction. Pour plus de détails, veuillez vous référer à la documentation de Xiaoming sur DMP DDLPlugin. Le texte original est le suivant :

Webpack.DLLPlugin

L'ajout d'un webpack.dll.config.js
utilise principalement un plug-in DllPlugin pour empaqueter certaines ressources tierces de manière indépendante et mettez-les dans le fichier de configuration In a manifest.json,

afin que ces ressources tierces ne soient pas reconstruites après mise à jour dans le composant,

1. et configurez les dll /vendors indépendamment en même temps, fichier .js, fourni à webpack.dll.config.js

2. Modifier package.json

Ajouter : "dll" dans les scripts : "webpack --config webpack.dll.config.js --progress --colors ", .

Après avoir exécuté npm run dll, deux fichiers supplier-manifest.json et supplier.dll.js seront produits dans le répertoire dll

Configurez le fichier webpack.dev.config.js et. ajoutez un plug-in DllReferencePlugin et spécifiez le fichier supplier-manifest.json

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

Modifier html

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

Notez que vous devez configurer le paramètre NODE_ENV

dans le plug-in htmlWebpackPlugin Happypack

Amélioration de l'efficacité de la reconstruction grâce au multi-threading, à la mise en cache, etc. https://github.com/amireh/happypack

Dans webpack.dev.config.js pour différentes ressources Créez plusieurs HappyPacks, tels que 1 js, 1 de moins, et définissez l'identifiant

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

Configurez l'utilisation dans module.rules en tant que happypack/loader, et définissez le. id

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

Réduire la taille du fichier après l'emballage du Webpack

Nous devons d'abord analyser l'ensemble de notre bundle, en quoi il consiste et la taille de chaque composant.

Webpack-bundle-analyzer est recommandé ici. Après l'installation, ajoutez simplement le plug-in dans webpack.dev.config.js, et les résultats de l'analyse seront automatiquement ouverts sur le site Web après chaque démarrage, comme indiqué ci-dessous

plugins.push( new BundleAnalyzerPlugin());

De plus, vous pouvez également générer le processus d'emballage dans un fichier json

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

, puis accéder aux deux sites Web suivants pour analyse

1. webpack /analyse

2. Graphique Webpack

Grâce à l'analyse graphique ci-dessus, nous pouvons voir clairement les composants et les tailles correspondantes de l'ensemble du bundle.js.

La solution au problème de la taille excessive de bundle.js est la suivante :

1. Activez la compression et les autres plug-ins dans l'environnement de production, et supprimez les plug-ins inutiles. ins

2. Diviser le code métier, les bibliothèques tierces et les modules publics

3. Webpack active la compression gzip

4. Charger à la demande

Activer la compression et d'autres plug-ins dans l'environnement de production et supprimer les plug-ins inutiles

Assurez-vous de démarrer webpack.DefinePlugin et webpack .optimize.UglifyJsPlugin dans l’environnement de production.

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

Diviser le code métier et les bibliothèques tierces et modules publics

En raison de la fréquence élevée des changements dans le code métier du projet, le code les modifications dans la bibliothèque tierce sont relativement moins fréquentes. Si le code métier et la troisième bibliothèque sont regroupés dans le même morceau, à chaque build, même si le code métier ne change qu'une seule ligne, même si le code de la bibliothèque tierce ne change pas, le hachage du morceau entier sera être différent de la dernière fois. Ce n’est pas le résultat que nous souhaitons. Ce que nous voulons, c'est que si le code de la bibliothèque tierce ne change pas, nous devons alors nous assurer que le hachage correspondant ne change pas lors de la construction, afin que nous puissions utiliser le cache du navigateur pour mieux améliorer les performances de chargement des pages et raccourcir le chargement des pages. temps.

Par conséquent, le code de la troisième bibliothèque peut être divisé en morceaux de fournisseur séparément du code métier. De cette façon, quelle que soit la façon dont le code métier change, tant que le code de la bibliothèque tierce ne change pas, le hachage correspondant restera inchangé.

Tout d'abord, l'entrée configure deux applications et deux blocs de fournisseur

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'
},

Parmi eux, vendros.js est votre propre définition des bibliothèques tierces qui doivent être incluses dans le fournisseur, comme suit :

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

Puis divisez la troisième bibliothèque via 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中如何换肤？

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!