なぜサードパーティのライブラリを分離するのでしょうか?

Webpack は迷惑な小さなゴブリンです。 私は常に過剰なキャンプに属しており、webpack の人気が爆発的に高まっていることに気づき、コミュニティから取り残されるのを恐れて、すぐにそれを手に入れて試してみました。もともとはただ遊びたかっただけなんです。パッケージ化を試みた後、Webpack サーバーを起動し、ホット リプレースメントを追加し、CSS ファイルを分離し、さまざまなローダーを使用してパッケージ化結果を処理および最適化したいのですが、さまざまなソース マップの違いは何ですか?ない。ホットリプレースを追加する際、アプリケーションサーバーとWebpackサーバーが同じものを使用していなかったため、多少の紆余曲折がありました。それでは今日の本題に入ります。
今日のトピックを段階的に拡張していきます:
なぜサードパーティのライブラリを分離する必要があるのですか?
この利点は明らかです。サードパーティのライブラリは比較的安定しており、簡単には変更されません。ブラウザ キャッシュを使用すると、ユーザーはページを再度ロードする際のサーバー リクエストが減少し、速度が向上し、エクスペリエンスが最適化されます。複数のアプリケーションの共通モジュール（エントランス）を抽出する機能も同様で、共通部分がキャッシュされ、すべてのアプリケーションがキャッシュされた内容を利用してパフォーマンスを向上させることができます。
サードパーティのライブラリを分離してブラウザを使用してキャッシュを変更できますか?
これも明らかにマイナスです。たとえば、最も明白な要因は、分離されたライブラリ ファイルを再パッケージ化するたびに、別の名前が付けられることです。別の例としては、バックグラウンドで同僚が js ファイルに設定されているキャッシュの有効期限が 0 で恥ずかしいのですが、0 だとキャッシュが使えないのですか？いいえ、ファイルが完全に変更されていない限り、変更時刻も含めて完全に変更されていない限り、キャッシュは引き続き使用され、パフォーマンスが飛躍的に向上することに注意してください。キャッシュを使用したい場合は、まずキャッシュについて理解する必要があります。簡単に説明します:
ブラウザのキャッシュ メカニズムとは何ですか?
HTTP1.1で与えられた戦略は、Etagでキャッシュコントロールを使用することです。
キャッシュコントロールの設定例:
'Cache-Control': 'public, max-age=600',
max-ageは有効期限です。期限切れの場合、ETag の値もチェックされます。Apache では、ETag の値は、インデックス ノード (INode)、サイズ (Size)、および最終変更時刻 (MTime) をハッシュすることによって取得されます。デフォルトではファイル。
Etag が同じ場合でも、新しいリソースは要求されませんが、以前のファイルが使用されます。

CommonsChunkPlugin は何に使用されますか?
文字通り理解すると、パブリックパッケージを抽出します。パブリックパッケージは、単一ページアプリケーション（単一エントリ）のライブラリが自分自身によってのみ使用されることを意味するため、パブリックパッケージとは見なされません。 、 右？このプラグインによって抽出されたパブリック パッケージは、パッケージ化時間を節約するため (些細なことではありますが、結局のところ役に立たないためです。ライブラリはまったく変更されていません) かどうかに関係なく、毎回再パッケージ化されます (Etag は異なります)。ブラウザのキャッシュを利用する (max-age の有効期限が切れたらキャッシュを放棄しますか?) どちらも良い解決策ではありません。最良の解決策が浮かび上がります: DllPlugin
DllPlugin の利点は何ですか?
ライブラリ ファイルをパッケージ化するのは 1 回のみです。つまり、ライブラリ ファイルが変更されていない限り、一度パッケージ化するだけで済みます。この方法では、後でビジネス コードとライブラリ ファイルをパッケージ化しても、ライブラリ ファイルは常に同じライブラリになります。ライブラリ ファイルが変更されていない限り、キャッシュは常に有効です (Etag は変更されません)。荷物をまとめてライブラリのことは忘れて、すっきりした気分になります。最も簡単な使用方法を紹介します: 最初に別の webpack 構成ファイルを作成します。結局のところ、これは
webpack.config.dll.js

const path = require('path')const webpack = require('webpack');module.exports = {
  entry: {vendor: ['react', 'react-dom', 'react-hot-loader', 'immutable', 'redux', 'react-redux', 'react-router-dom', 'redux-logger',  'redux-persist', 'redux-persist-transform-immutable', 'redux-thunk'],
  },
  output: {filename: 'js/[name].js',path: path.resolve(__dirname, 'public'),library: '[name]', // 当前Dll的所有内容都会存放在这个参数指定变量名的一个全局变量下，注意与DllPlugin的name参数保持一致
  },
  plugins: [new webpack.DllPlugin({  path: path.resolve(__dirname, 'public/manifest.json'), // 本Dll文件中各模块的索引，供DllReferencePlugin读取使用  name: '[name]',}),
  ],}

プラグインを追加するとします。元の設定ファイルに追加します

new webpack.DllReferencePlugin({  manifest: require('./public/manifest.json'), // 指定manifest.json  name: 'vendor',  // 当前Dll的所有内容都会存放在这个参数指定变量名的一个全局变量下，注意与DllPlugin的name参数保持一致}),

まずターミナルを実行します:

まずライブラリ ファイルをパッケージにパックします。ライブラリが変更されていない限り、今後はこのパッケージを使用し、その後ビジネスをパッケージ化します。コードを入力したら完了です。

推奨戦略:

誰もが自分のことをします。 webpack -p --progress --config ./webpack.config.dll.jsシングルページアプリケーションの場合は、DllPluginを使用してライブラリファイルをパッケージ化するだけで、ビジネスコードを1つのパッケージにパッケージ化できます。
マルチページ アプリケーションの場合、DllPlugin がライブラリ ファイルをパッケージ化した後、開発中に多くのパブリック ビジネス コードが使用される可能性があり、いつでも変更される可能性があります。この場合、想定されている動作を実行するには CommonsChunkPlugin を使用する必要があります。実行してからパブリック ビジネスを抽出します。少なくともページ間を切り替えるときは、パブリック部分がキャッシュされます。

以上がなぜサードパーティのライブラリを分離するのでしょうか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。