webpack がアセット キャッシュにどのように役立つか
次に（アプリの読み込み時間を短縮するアプリサイズの最適化の後）行うべきことは、キャッシュです。これにより、アプリの一部をクライアントに保持し、毎回再ダウンロードしなくて済みます。
バンドルのバージョニングとキャッシュ ヘッダーを使用する
キャッシュに保存する一般的な方法は次のとおりです。
ファイルをかなり長い期間（1 年間など）キャッシュに保存するようブラウザに指示します。
# Server header Cache-Control: max-age=31536000Cache-Controlの機能について詳しくは、Jake Archibald のキャッシュのベスト プラクティスに関する優れた投稿をご覧ください。変更されたらファイル名を変更して、強制的に再ダウンロードします。
<!-- Before the change --> <script src="./index-v15.js"></script> <!-- After the change --> <script src="./index-v16.js"></script>
この方法では、JS ファイルをダウンロードしてキャッシュに保存し、そのキャッシュに保存されたコピーを使用するようブラウザに指示します。ブラウザは、ファイル名が変更された場合（または 1 年が経過した場合）にのみネットワークにアクセスします。
webpack でも同じことを行いますが、バージョン番号の代わりにファイル ハッシュを指定します。ハッシュをファイル名に含めるには、[chunkhash] を使用します。
// webpack.config.js
module.exports = {
entry: './index.js',
output: {
filename: 'bundle.[chunkhash].js' // → bundle.8e0d62a03.js
}
};
ファイル名をクライアントに送信する必要がある場合は、HtmlWebpackPlugin または WebpackManifestPlugin を使用します。
HtmlWebpackPlugin はシンプルですが、柔軟性は低いアプローチです。このプラグインは、コンパイル時に、コンパイル済みリソースがすべて含まれる HTML ファイルを生成します。サーバー ロジックが複雑でない場合は、次の方法で十分です。
<!-- index.html -->
<!DOCTYPE html>
<!-- ... -->
<script src="bundle.8e0d62a03.js"></script>
WebpackManifestPlugin はより柔軟なアプローチで、複雑なサーバー パートがある場合に便利です。ビルド中に、ハッシュのないファイル名とハッシュ付きのファイル名のマッピングを含む JSON ファイルが生成されます。サーバーでこの JSON を使用して、処理するファイルを確認します。
// manifest.json
{
"bundle.js": "bundle.8e0d62a03.js"
}
関連情報
- Jake Archibald のキャッシュ保存のベスト プラクティス
依存関係とランタイムを別のファイルに抽出する
依存関係
アプリの依存関係は、実際のアプリコードよりも変更頻度が低い傾向があります。それらを別のファイルに移動すると、ブラウザで個別にキャッシュできます。アプリコードが変更されるたびに再ダウンロードすることはありません。
依存関係を別のチャンクに抽出するには、次の 3 つの手順を行います。
出力ファイル名を
[name].[chunkname].jsに置き換えます。// webpack.config.js module.exports = { output: { // Before filename: 'bundle.[chunkhash].js', // After filename: '[name].[chunkhash].js' } };webpack はアプリをビルドするときに、
[name]をチャンク名に置き換えます。[name]部分を追加しないと、ハッシュでチャンクを区別する必要があります。これは非常に困難です。entryフィールドをオブジェクトに変換します。// webpack.config.js module.exports = { // Before entry: './index.js', // After entry: { main: './index.js' } };このスニペットでは、「main」はチャンクの名前です。この名前は、手順 1 の
[name]の代わりに使用されます。ここまでの手順を実施していない場合と同様に、アプリをビルドすると、このチャンクにアプリコード全体が含まれます。ただし、これはすぐに変更されます。
webpack 4 の場合、webpack 構成に
optimization.splitChunks.chunks: 'all'オプションを追加します。// webpack.config.js (for webpack 4) module.exports = { optimization: { splitChunks: { chunks: 'all' } } };このオプションを使用すると、スマートコード分割が有効になります。これを使用すると、webpack はベンダーコードが 30 KB を超えると（圧縮と gzip の前に）ベンダーコードを抽出します。また、共通コードも抽出されます。これは、ビルドで複数のバンドルが生成される場合に便利です（アプリをルートに分割している場合など）。
webpack 3 の場合は、
CommonsChunkPluginを追加します。// webpack.config.js (for webpack 3) module.exports = { plugins: [ new webpack.optimize.CommonsChunkPlugin({ // A name of the chunk that will include the dependencies. // This name is substituted in place of [name] from step 1 name: 'vendor', // A function that determines which modules to include into this chunk minChunks: module => module.context && module.context.includes('node_modules'), }) ] };このプラグインは、パスに
node_modulesを含むすべてのモジュールをvendor.[chunkhash].jsという別のファイルに移動します。
これらの変更により、各ビルドで 1 つではなく 2 つのファイル（main.[chunkhash].js と vendor.[chunkhash].js（webpack 4 の場合は vendors~main.[chunkhash].js））が生成されます。webpack 4 の場合、依存関係が少ない場合はベンダー バンドルが生成されないことがあります。これは問題ありません。
$ webpack
Hash: ac01483e8fec1fa70676
Version: webpack 3.8.1
Time: 3816ms
Asset Size Chunks Chunk Names
./main.00bab6fd3100008a42b0.js 82 kB 0 [emitted] main
./vendor.d9e134771799ecdf9483.js 47 kB 1 [emitted] vendor
ブラウザはこれらのファイルを個別にキャッシュに保存し、変更されたコードのみを再ダウンロードします。
Webpack ランタイム コード
残念ながら、ベンダーコードのみを抽出しても不十分です。アプリコードの一部を変更しようとすると、次のようになります。
// index.js
…
…
// E.g. add this:
console.log('Wat');
vendor ハッシュも変わることがわかります。
Asset Size Chunks Chunk Names
./vendor.d9e134771799ecdf9483.js 47 kB 1 [emitted] vendor
↓
Asset Size Chunks Chunk Names
./vendor.e6ea4504d61a1cc1c60b.js 47 kB 1 [emitted] vendor
これは、webpack バンドルに、モジュールのコードとは別に、ランタイム（モジュールの実行を管理する小さなコード）が含まれているためです。コードを複数のファイルに分割すると、このコードにチャンク ID と対応するファイルのマッピングが含まれるようになります。
// vendor.e6ea4504d61a1cc1c60b.js
script.src = __webpack_require__.p + chunkId + "." + {
"0": "2f2269c7f0a55a5c1871"
}[chunkId] + ".js";
Webpack はこのランタイムを、最後に生成されたチャンク（この場合は vendor）に含めます。チャンクが変更されるたびに、このコードも変更され、vendor チャンク全体が変更されます。
この問題を解決するには、ランタイムを別のファイルに移動しましょう。webpack 4 では、optimization.runtimeChunk オプションを有効にすることでこれを実現できます。
// webpack.config.js (for webpack 4)
module.exports = {
optimization: {
runtimeChunk: true
}
};
webpack 3 の場合は、CommonsChunkPlugin を使用して空のチャンクを追加で作成します。
// webpack.config.js (for webpack 3)
module.exports = {
plugins: [
new webpack.optimize.CommonsChunkPlugin({
name: 'vendor',
minChunks: module => module.context && module.context.includes('node_modules')
}),
// This plugin must come after the vendor one (because webpack
// includes runtime into the last chunk)
new webpack.optimize.CommonsChunkPlugin({
name: 'runtime',
// minChunks: Infinity means that no app modules
// will be included into this chunk
minChunks: Infinity
})
]
};
この変更後、各ビルドで次の 3 つのファイルが生成されます。
$ webpack
Hash: ac01483e8fec1fa70676
Version: webpack 3.8.1
Time: 3816ms
Asset Size Chunks Chunk Names
./main.00bab6fd3100008a42b0.js 82 kB 0 [emitted] main
./vendor.26886caf15818fa82dfa.js 46 kB 1 [emitted] vendor
./runtime.79f17c27b335abc7aaf4.js 1.45 kB 3 [emitted] runtime
逆順で index.html に含めると、設定は完了です。
<!-- index.html -->
<script src="./runtime.79f17c27b335abc7aaf4.js"></script>
<script src="./vendor.26886caf15818fa82dfa.js"></script>
<script src="./main.00bab6fd3100008a42b0.js"></script>
関連情報
- 長期キャッシュ保存に関する Webpack ガイド
- webpack ランタイムとマニフェストに関する Webpack のドキュメント
- 「CommonsChunkPlugin を最大限に活用する」
optimization.splitChunksとoptimization.runtimeChunkの仕組み
webpack ランタイムをインライン化して余分な HTTP リクエストを削減
さらにパフォーマンスを向上させるには、webpack ランタイムを HTML レスポンスにインライン化してみてください。たとえば、
<!-- index.html -->
<script src="./runtime.79f17c27b335abc7aaf4.js"></script>
次の手順を行います。
<!-- index.html -->
<script>
!function(e){function n(r){if(t[r])return t[r].exports;…}} ([]);
</script>
ランタイムは小さく、インライン化すると HTTP リクエストを節約できます（HTTP/1 では非常に重要で、HTTP/2 では重要度は低くなりますが、それでも効果があります）。
次にその方法をご紹介します。
HTMLWebpackPlugin を使用して HTML を生成する場合
HtmlWebpackPlugin を使用して HTML ファイルを生成する場合は、InlineSourcePlugin のみが必要です。
const HtmlWebpackPlugin = require('html-webpack-plugin');
const InlineSourcePlugin = require('html-webpack-inline-source-plugin');
module.exports = {
plugins: [
new HtmlWebpackPlugin({
inlineSource: 'runtime~.+\\.js',
}),
new InlineSourcePlugin()
]
};
カスタム サーバー ロジックを使用して HTML を生成する
webpack 4 の場合:
WebpackManifestPluginを追加して、ランタイム チャンクの生成された名前を確認します。// webpack.config.js (for webpack 4) const ManifestPlugin = require('webpack-manifest-plugin'); module.exports = { plugins: [ new ManifestPlugin() ] };このプラグインを使用したビルドでは、次のようなファイルが作成されます。
// manifest.json { "runtime~main.js": "runtime~main.8e0d62a03.js" }ランタイム チャンクのコンテンツを簡単な方法でインライン化します。たとえば、Node.js と Express を使用する場合:
// server.js const fs = require('fs'); const manifest = require('./manifest.json'); const runtimeContent = fs.readFileSync(manifest['runtime~main.js'], 'utf-8'); app.get('/', (req, res) => { res.send(` … <script>${runtimeContent}</script> … `); });
または webpack 3 の場合:
filenameを指定してランタイム名を静的にします。module.exports = { plugins: [ new webpack.optimize.CommonsChunkPlugin({ name: 'runtime', minChunks: Infinity, filename: 'runtime.js' }) ] };runtime.jsコンテンツを便利な方法でインライン化します。Node.js と Express の場合:// server.js const fs = require('fs'); const runtimeContent = fs.readFileSync('./runtime.js', 'utf-8'); app.get('/', (req, res) => { res.send(` … <script>${runtimeContent}</script> … `); });
すぐには必要のないコードを遅延読み込みする
ページには、重要度の高い部分と低い部分があります。
- YouTube で動画ページを読み込む場合、コメントよりも動画に重点を置いています。ここでは、コメントよりも動画の方が重要です。
- ニュース サイトで記事を開いた場合、ユーザーは広告よりも記事のテキストに注目します。テキストが広告よりも重要です。
このような場合は、最初に最も重要な部分のみをダウンロードし、残りの部分は後で遅延読み込みすることで、初期読み込みのパフォーマンスを改善します。これには、import() 関数とコード分割を使用します。
// videoPlayer.js
export function renderVideoPlayer() { … }
// comments.js
export function renderComments() { … }
// index.js
import {renderVideoPlayer} from './videoPlayer';
renderVideoPlayer();
// …Custom event listener
onShowCommentsClick(() => {
import('./comments').then((comments) => {
comments.renderComments();
});
});
import() は、特定のモジュールを動的に読み込むことを指定します。webpack は import('./module.js') を検出すると、このモジュールを個別のチャンクに移動します。
$ webpack
Hash: 39b2a53cb4e73f0dc5b2
Version: webpack 3.8.1
Time: 4273ms
Asset Size Chunks Chunk Names
./0.8ecaf182f5c85b7a8199.js 22.5 kB 0 [emitted]
./main.f7e53d8e13e9a2745d6d.js 60 kB 1 [emitted] main
./vendor.4f14b6326a80f4752a98.js 46 kB 2 [emitted] vendor
./runtime.79f17c27b335abc7aaf4.js 1.45 kB 3 [emitted] runtime
実行が import() 関数に達した場合にのみダウンロードします。
これにより、main バンドルが小さくなり、初期読み込み時間が短縮されます。さらに、キャッシュの効率も向上します。メイン チャンクのコードを変更しても、コメント チャンクは影響を受けません。
関連情報
コードをルートとページに分割する
アプリに複数のルートまたはページがあるにもかかわらず、コードを含む JS ファイルが 1 つしかない（main チャンクが 1 つしかない）場合は、リクエストごとに余分なバイトが配信されている可能性があります。たとえば、ユーザーがサイトのホームページにアクセスしたとします。
別のページにある記事をレンダリングするためのコードを読み込む必要はありませんが、読み込まれます。さらに、ユーザーが常にホームページのみにアクセスし、記事コードを変更した場合、webpack はバンドル全体を無効にするため、ユーザーはアプリ全体を再ダウンロードする必要があります。
アプリをページ（またはシングルページ アプリの場合はルート）に分割すると、ユーザーは関連するコードのみをダウンロードします。さらに、ブラウザによるアプリコードのキャッシュも向上します。ホームページのコードを変更すると、対応するチャンクのみが無効になります。
シングルページ アプリの場合
シングルページ アプリをルートごとに分割するには、import() を使用します（「現在必要のないコードを遅延読み込みする」をご覧ください）。フレームワークを使用する場合は、既存のソリューションを利用できることがあります。
react-routerのドキュメントの「コード分割」（React の場合）vue-routerのドキュメントの「遅延読み込みルート」（Vue.js の場合）
従来の複数ページ アプリの場合
従来のアプリをページごとに分割するには、webpack のエントリ ポイントを使用します。アプリにホームページ、記事ページ、ユーザー アカウント ページの 3 種類のページがある場合、次のように 3 つのエントリが必要です。
// webpack.config.js
module.exports = {
entry: {
home: './src/Home/index.js',
article: './src/Article/index.js',
profile: './src/Profile/index.js'
}
};
エントリファイルごとに、webpack は個別の依存関係ツリーを構築し、そのエントリで使用されるモジュールのみを含むバンドルを生成します。
$ webpack
Hash: 318d7b8490a7382bf23b
Version: webpack 3.8.1
Time: 4273ms
Asset Size Chunks Chunk Names
./0.8ecaf182f5c85b7a8199.js 22.5 kB 0 [emitted]
./home.91b9ed27366fe7e33d6a.js 18 kB 1 [emitted] home
./article.87a128755b16ac3294fd.js 32 kB 2 [emitted] article
./profile.de945dc02685f6166781.js 24 kB 3 [emitted] profile
./vendor.4f14b6326a80f4752a98.js 46 kB 4 [emitted] vendor
./runtime.318d7b8490a7382bf23b.js 1.45 kB 5 [emitted] runtime
そのため、記事ページで Lodash のみを使用している場合、home バンドルと profile バンドルには Lodash が含まれず、ユーザーがホームページにアクセスしたときにこのライブラリをダウンロードする必要はありません。
ただし、個別の依存関係ツリーにはデメリットもあります。2 つのエントリ ポイントが Lodash を使用し、依存関係をベンダー バンドルに移動していない場合、両方のエントリ ポイントに Lodash のコピーが含まれます。この問題を解決するには、webpack 4 で webpack 構成に optimization.splitChunks.chunks: 'all' オプションを追加します。
// webpack.config.js (for webpack 4)
module.exports = {
optimization: {
splitChunks: {
chunks: 'all'
}
}
};
このオプションを使用すると、スマート コード分割が有効になります。このオプションを使用すると、webpack は共通のコードを自動的に検索し、個別のファイルに抽出します。
または、webpack 3 では CommonsChunkPlugin を使用します。これにより、共通の依存関係が新しい指定されたファイルに移動します。
module.exports = {
plugins: [
new webpack.optimize.CommonsChunkPlugin({
name: 'common',
minChunks: 2 // 2 is the default value
})
]
};
minChunks の値を調整して、最適な値を見つけてください。通常は小さく保ちますが、チャンクの数が多くなる場合は増やします。たとえば、3 つのチャンクの場合は minChunks が 2 で、30 個のチャンクの場合は 8 になります。2 のままにすると、共通ファイルにモジュールが多すぎて、ファイルが大きくなりすぎます。
関連情報
- エントリ ポイントのコンセプトに関する Webpack のドキュメント
- CommonsChunkPlugin に関する Webpack のドキュメント
- 「CommonsChunkPlugin を最大限に活用する」
optimization.splitChunksとoptimization.runtimeChunkの仕組み
モジュール ID の安定性を高める
コードをビルドするときに、webpack は各モジュールに ID を割り当てます。後で、これらの ID はバンドル内の require() で使用されます。通常、ビルド出力では、モジュールパスの直前に ID が表示されます。
$ webpack
Hash: df3474e4f76528e3bbc9
Version: webpack 3.8.1
Time: 2150ms
Asset Size Chunks Chunk Names
./0.8ecaf182f5c85b7a8199.js 22.5 kB 0 [emitted]
./main.4e50a16675574df6a9e9.js 60 kB 1 [emitted] main
./vendor.26886caf15818fa82dfa.js 46 kB 2 [emitted] vendor
./runtime.79f17c27b335abc7aaf4.js 1.45 kB 3 [emitted] runtime
↓ こちら
[0] ./index.js 29 kB {1} [built]
[2] (webpack)/buildin/global.js 488 bytes {2} [built]
[3] (webpack)/buildin/module.js 495 bytes {2} [built]
[4] ./comments.js 58 kB {0} [built]
[5] ./ads.js 74 kB {1} [built]
+ 1 hidden module
デフォルトでは、ID はカウンタを使用して計算されます（最初のモジュールは ID 0、2 番目のモジュールは ID 1 などとなります）。この方法の問題は、新しいモジュールを追加すると、モジュール リストの途中に表示され、次のモジュールの ID がすべて変更される可能性があることです。
$ webpack
Hash: df3474e4f76528e3bbc9
Version: webpack 3.8.1
Time: 2150ms
Asset Size Chunks Chunk Names
./0.5c82c0f337fcb22672b5.js 22 kB 0 [emitted]
./main.0c8b617dfc40c2827ae3.js 82 kB 1 [emitted] main
./vendor.26886caf15818fa82dfa.js 46 kB 2 [emitted] vendor
./runtime.79f17c27b335abc7aaf4.js 1.45 kB 3 [emitted] runtime
[0] ./index.js 29 kB {1} [built]
[2] (webpack)/buildin/global.js 488 bytes {2} [built]
[3] (webpack)/buildin/module.js 495 bytes {2} [built]
↓ 新しいモジュールを追加しました
[4] ./webPlayer.js 24 kB {1} [built]
↓ 結果は次のとおりです。comments.js の ID が 4 から 5 に変更されました
[5] ./comments.js 58 kB {0} [built]
↓ ads.js の ID が 5 から 6 に変更されました
[6] ./ads.js 74 kB {1} [built]
+ 1 hidden module
これにより、実際のコードが変更されていなくても、ID が変更されたモジュールを含む、またはモジュールに依存するすべてのチャンクが無効になります。この例では、0 チャンク（comments.js を含むチャンク）と main チャンク（他のアプリコードを含むチャンク）が無効になりますが、main チャンクのみが無効になるはずです。
この問題を解決するには、HashedModuleIdsPlugin を使用してモジュール ID の計算方法を変更します。カウンタベースの ID は、モジュールパスのハッシュに置き換えられます。
$ webpack
Hash: df3474e4f76528e3bbc9
Version: webpack 3.8.1
Time: 2150ms
Asset Size Chunks Chunk Names
./0.6168aaac8461862eab7a.js 22.5 kB 0 [emitted]
./main.a2e49a279552980e3b91.js 60 kB 1 [emitted] main
./vendor.ff9f7ea865884e6a84c8.js 46 kB 2 [emitted] vendor
./runtime.25f5d0204e4f77fa57a1.js 1.45 kB 3 [emitted] runtime
↓ こちら
[3IRH] ./index.js 29 kB {1} [built]
[DuR2] (webpack)/buildin/global.js 488 bytes {2} [built]
[JkW7] (webpack)/buildin/module.js 495 bytes {2} [built]
[LbCc] ./webPlayer.js 24 kB {1} [built]
[lebJ] ./comments.js 58 kB {0} [built]
[02Tr] ./ads.js 74 kB {1} [built]
+ 1 hidden module
この方法では、モジュールの名前を変更するか移動した場合にのみ、モジュールの ID が変更されます。新しいモジュールは、他のモジュールの ID には影響しません。
プラグインを有効にするには、構成ファイルの plugins セクションに追加します。
// webpack.config.js
module.exports = {
plugins: [
new webpack.HashedModuleIdsPlugin()
]
};
関連情報
まとめ
- バンドルをキャッシュに保存し、バンドル名を変更してバージョンを区別する
- バンドルをアプリコード、ベンダーコード、ランタイムに分割する
- ランタイムをインライン化して HTTP リクエストを保存する
importを使用して重要でないコードを遅延読み込みする- ルート/ページごとにコードを分割して、不要なデータを読み込まないようにする