コードスプリッティングとは? JavaScript をオンデマンドで読み込む

コードスプリッティングは 1 つの大きなバンドルを複数のチャンクに分割し、ブラウザが現在のビューに必要なコードだけをダウンロードできるようにします。

アプリ全体を単一の JavaScript ファイルとして出荷すると、ユーザーは決して実行しないかもしれないコードを待つことになります。コードスプリッティングは、ルートを訪れたときなど、必要なときに読み込まれるチャンクにバンドルを分割します。これは初回読み込み時間を改善する最も効果的な方法の 1 つであり、バンドラーが build 時に重い処理を担います。

splitting はどう起こるか

動的な import() は、最初からではなく runtime で読み込まれる別個のチャンクを作るようバンドラーに指示します。ルートベースの splitting が最も一般的なパターンです。各ページが独自のチャンクとなり、ユーザーがそこへ遷移したときに取得されます。

共有チャンク

バンドラーは複数のエントリーポイント間で共有されるコードを検出し、重複しないよう共通チャンクにまとめます。サードパーティライブラリ向けの vendor チャンクが典型的な結果で、cache が deploy をまたいで生き残るよう安定に保たれます。

利点

より小さな初回ダウンロードによる、より速い初回ページ読み込み。
めったに訪れないページのコードは、必要にならない限り取得されません。
安定した共有チャンクは release をまたいで cache に残ります。

トレードオフ

小さすぎるチャンクが多すぎるとリクエストのオーバーヘッドが増え、パフォーマンスを損なうことがあります。splitting はまた、チャンクがユーザーのクリック後に届き得るため、プリフェッチや読み込み状態を自分で設計しなければならないものにします。

CI/CD でのコードスプリッティング

splitting は、build が生成する出力ファイルの数と、それらがどうハッシュされるかを変えます。各チャンクは content hash を受け取るため、CDN はそれを永続的に cache でき、deploy 後に変更されたチャンクだけが再ダウンロードされます。pipeline はチャンク化された出力全体を 1 つの artifact としてアップロードします。

重要なポイント

コードスプリッティングは動的インポートを介して、多くの場合ルートごとにコードをオンデマンドで読み込みます。
共有チャンクと vendor チャンクは重複を避け、deploy をまたいで cache に残ります。
各チャンクは content-hash されるため、deploy は変更された分だけを無効化します。