Wie optimiert man die Verpackung mit React und Webpack?

Dieser Artikel stellt hauptsächlich die Konstruktion und Verpackungsoptimierung von React + Webpack vor Wie folgt:

Verwenden Sie babel-react-optimize, um den React-Code zu optimieren.

Überprüfen Sie nicht verwendete Bibliotheken und entfernen Sie Importverweise.

Verpacken Sie die verwendeten Klassenbibliotheken als benötigt, wie lodash , echart usw.

lodash kann mit babel-plugin-lodash optimiert werden.

Es ist zu beachten, dass

das Plugin babel-plugin-transform-react-remove-prop-types in babel-react-optimize verwendet. Normalerweise ist es völlig in Ordnung, wenn Sie in Ihrem Code nicht auf die PropTypes der Komponente verweisen. Die Verwendung dieses Plugins kann zu Problemen führen, wenn Ihre Komponente es verwendet.

Einzelheiten finden Sie unter:

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

Webpack-Build und Paketoptimierung

Die Probleme beim Webpack-Build und -Paket konzentrieren sich hauptsächlich auf die folgenden zwei Aspekte:

Webpack-Build-Geschwindigkeit ist langsam
Die Dateigröße nach der Webpack-Verpackung ist zu groß

Die Webpack-Erstellungsgeschwindigkeit ist langsam

Sie können Webpack.DDLPlugin und HappyPack verwenden, um die Build-Geschwindigkeit zu verbessern. Einzelheiten finden Sie in der Dokumentation von Xiaoming zum DMP DDLPlugin. Der Originaltext lautet wie folgt:

Webpack.DLLPlugin

Beim Hinzufügen einer webpack.dll.config.js

wird hauptsächlich ein DllPlugin-Plug-in verwendet, um einige Ressourcen von Drittanbietern unabhängig zu verpacken Fügen Sie sie in eine manifest.json-Konfigurationsdatei ein,

, damit diese Drittanbieterressourcen nach der Aktualisierung in der Komponente nicht neu erstellt werden,

und konfigurieren Sie die DLL /vendors unabhängig gleichzeitig .js-Datei, bereitgestellt für webpack.dll.config.js
Paket.json ändern
Hinzufügen: „dll“ in Skripten: „webpack --config webpack.dll.config.js --progress --colors“, .

Nach dem Ausführen von npm run dll werden zwei Dateien Vendor-manifest.json und Vendor.dll.js im DLL-Verzeichnis erstellt.

Konfigurieren Sie die Datei webpack.dev.config.js Fügen Sie ein DllReferencePlugin-Plug-in hinzu und geben Sie die Datei „vendor-manifest.json“ an

Happypack

Verbessern Sie die Wiederherstellungseffizienz durch Multithreading, Caching usw. https://github.com/amireh/happypack

Erstellen Sie mehrere HappyPacks für verschiedene Ressourcen in webpack.dev.config.js, zum Beispiel 1 js, weniger 1, und legen Sie die ID fest

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

, konfigurieren Sie die Verwendung für Happypack/Loader in module.rules, legen Sie die ID fest

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

um die Anzahl der Webpack-Pakete zu reduzieren Dateigröße

Zuerst müssen wir unser gesamtes Paket analysieren, woraus es besteht und wie groß jede Komponente ist.

Webpack-bundle-analyzer wird hier empfohlen. Nach der Installation fügen Sie einfach das Plug-in in webpack.dev.config.js hinzu und die Analyseergebnisse werden nach jedem Start automatisch auf der Website geöffnet, wie unten gezeigt

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

Außer Darüber hinaus können Sie den Verpackungsprozess auch in eine JSON-Datei ausgeben

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

und dann zur Analyse auf die folgenden beiden Websites gehen

webpack/analyse

Webpack-Diagramm

1. Durch die obige Diagrammanalyse können Sie die Komponenten und entsprechenden Größen des gesamten bundle.js klar erkennen.
2. Die Lösung für das Problem der übermäßigen Größe von bundle.js lautet wie folgt:

Aktivieren Sie die Komprimierung und andere Plug-Ins in der Produktionsumgebung und entfernen Sie unnötige Plug-Ins. ins

Geschäftscode und Bibliotheken und öffentliche Module von Drittanbietern aufteilen

1. Webpack aktiviert die GZIP-Komprimierung

2. Bei Bedarf laden

3. Komprimierung und andere Plug-Ins in der Produktionsumgebung aktivieren und unnötige Plug-Ins entfernen
4. Stellen Sie sicher, dass Sie webpack starten.DefinePlugin und Webpack .optimize.UglifyJsPlugin in der Produktionsumgebung.

   plugins.push( new BundleAnalyzerPlugin());

Geschäftscode mit Bibliotheken von Drittanbietern und öffentlichen Modulen aufteilen

Aufgrund der hohen Häufigkeit von Geschäftscodeänderungen im Projekt gibt es relativ wenige Codeänderungen Bibliotheken von Drittanbietern Also Häufigkeit. Wenn der Geschäftscode und die dritte Bibliothek bei jedem Build in denselben Block gepackt werden, ändert sich der Hash des gesamten Blocks, auch wenn der Geschäftscode nur eine Zeile ändert, selbst wenn sich der Code der Bibliothek eines Drittanbieters nicht ändert anders sein als beim letzten Mal. Das ist nicht das Ergebnis, das wir wollen. Was wir wollen, ist, dass wir, wenn sich der Code der Bibliothek eines Drittanbieters nicht ändert, sicherstellen müssen, dass sich der entsprechende Hash beim Erstellen nicht ändert, damit wir den Browser-Cache verwenden können, um die Seitenladeleistung besser zu verbessern und das Laden der Seite zu verkürzen Zeit.

Daher kann der Code der dritten Bibliothek getrennt vom Geschäftscode in Herstellerblöcke aufgeteilt werden. Unabhängig davon, wie sich der Geschäftscode ändert, bleibt der entsprechende Hash unverändert, solange sich der Bibliothekscode eines Drittanbieters nicht ändert.

Zuerst konfiguriert Entry zwei Apps und zwei Vendor-Chunks

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

Unter anderem ist vendros.js Ihre eigene Definition, welche Bibliotheken von Drittanbietern in den Vendor aufgenommen werden müssen, wie folgt:

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

Dann teilen Sie die dritte Bibliothek über CommonsChunkPlugin auf

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中如何换肤？

Das obige ist der detaillierte Inhalt vonWie optimiert man die Verpackung mit React und Webpack?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!