アプリ/フロント基盤

webpackとは|入口を1個から30個に増やしたら、落とせる割合が96.2%から59.7%に下がった

何を集めて何を落とすのか入口の数はどう効くのか落とせない記述は何か

記述の単位300個・6350KBで、入口1個からたどると残るのは15個・242KBでした。

入口を30個にすると136個・2557KBが残ります。落とせる割合は96.2%から59.7%に下がりました。

この記事の要点

  • 入口1個なら96.2%落とせる
  • 3個で79.6%
  • 30個では59.7%
  • 入口が結果を決める

入口を1個から30個に増やしたら、落とせる割合が96.2%から59.7%に下がった

落とせる量は書き方ではなく、入口の数で決まります。入口が増えるほど到達範囲が広がります。

webpackは入口を起点にします。出典の説明はこうです。

これらの入口から始めて、webpackは、アプリケーションが必要とするあらゆる単位を含む依存の図を再帰的に組み立て、それらすべてを少数のまとまりへ束ねるという記述です。

起点が違えば、含まれる範囲も変わります。入口の数を動かして計算しました。

入口の数を変える

記述の単位300個・合わせて6350KBの図を用意しました。たどれないものは落とせるものとします。

text
記述の単位 300個、合わせて 6350KB
入口からたどれないものを落とす。入口の数を変えて減り方を見る

入口の数  残る単位  残る大きさ  落とせる割合
1個               15個       242KB         96.2%
3個               62個      1292KB         79.6%
10個              87個      1586KB         75.0%
30個             136個      2557KB         59.7%

入口1個なら残るのは15個・242KBだけです。96.2%を落とせます。

3個にすると残りは62個・1292KBへ跳ねます。入口が2つ増えただけで5倍以上です。

増え方は途中でゆるむ

3個から10個で残るのは62個から87個までしか増えません。入口が3倍でも1.4倍です。

重なりが出るためです。複数の入口が同じ下位の記述を使っているので、二重には数えません。

つまり効くのは最初の数個です。入口を1個から3個にする判断が、いちばん大きく結果を変えます。

落とせる割合は、入口の数で決まる。

単位: %入口1個96.2%入口3個79.6%入口10個75%入口30個59.7%単位300個・6350KBの図での実測。3個から10個の落ち込みが小さいのは、入口どうしが同じ下位を使うため。
図1 ── 入口の数と、落とせる割合
出典webpack 公式ドキュメント「The Dependency Graph」2026-08-18 確認
Starting from these entry points, webpack recursively builds a dependency graph that includes every module your application needs, then bundles all of those modules into a small number of bundles - often, only one - to be loaded by the browser.
原文webpack 公式ドキュメント「The Dependency Graph」 この内容の有効期限2027-02-18

入口は自動では決まらず、書いた通りになる

自動では決まりません。どこから始めるかを書いた通りに、含まれる範囲が決まります。

webpackの入口は、指定するものです。出典は入口とは、webpackが内部の依存の図を組み立て始めるにあたって、どの単位を使うべきかを示すものであると定めています。

前の計測の96.2%と59.7%の差は、この指定だけから生まれました。記述の中身は同じです。

入口を決める順序

  1. 利用者が最初に開く単位を挙げる。ここは必ず入口になる
  2. 別々に配りたい画面を挙げる。分けるなら入口を分ける
  3. 共通で使われる部分を抜き出す。入口にはしない
  4. 残ったものは入口にしない。たどれれば自然に含まれる

4番目を守るのが要点です。迷って入口に足すと、落とせる割合がその分だけ下がります

分けるかどうかの判断

入口を分けると配るまとまりも分かれます。更新のたびに配り直す量は減ります

その代わり取りに行く回数が増えます。この釣り合いはViteの記事で測っていて、16個あたりが折り返しでした。

入口に足すかどうかで、落とせる範囲が決まる。

利用者がその単位を直接開くかいいえ入口にしない。たどれれば自然に含まれるはい他の画面と別々に配りたいかいいえ入口にしない。同じまとまりに入れるはい入口に加える。そのぶん到達範囲が広がる入口を1個から3個に増やすと、落とせる割合が96.2%から79.6%へ下がる。迷ったら加えない側に倒す。
図2 ── 入口に加えるかどうかの判断
出典webpack 公式ドキュメント「Concepts」2026-08-18 確認
An entry point indicates which module webpack should use to begin building out its internal dependency graph.
原文webpack 公式ドキュメント「Concepts」 この内容の有効期限2027-02-18

依存は1行で生まれ、たどれた時点で落とせない

使うかどうかではなく、たどれるかどうかで決まります。書き方1つで範囲が広がります。

webpackの依存は、書いた瞬間にできます。出典はあるファイルが別のファイルに依存するときは常に、webpackはこれを依存として扱うと述べています。

条件がありません。実際に呼ぶかどうかは問われません

範囲が広がる書き方

  1. まとめ役のファイルから取り込む。1つ欲しくて全部たどる
  2. 取り込みだけ残す。使っていなくても依存になる
  3. 条件で分岐する取り込み。どちらも含まれる
  4. 名前で組み立てる取り込み。範囲を決められない

1番目がいちばん起きます。1つの関数のために、そのまとまり全体をたどってしまう形です。

前の計測でいえば、入口を増やしたのと同じ効き方になります。到達できる範囲が広がれば、落とせる量は減ります

見つけ方

配ったまとまりの中身を出せば分かります。入れた覚えのない名前があれば、そこがたどられています。

数え方は前の節と同じです。入口から到達できる単位を数え、全体と比べるだけで出ます。

余談 この計測での注意

依存の図は式で作ったものです。入口は上位から無作為に選んでおり、実際の構成では入口どうしの重なり方に偏りがあります。重なりが大きい構成では、入口を増やしても落とせる割合はここまで下がりません。また、たどれない単位はすべて落とせるものとしました。実際には落とせない書き方もあります。ここで見せているのは、落とせる量が記述の中身ではなく入口の数で決まるという関係です。

出典webpack 公式ドキュメント「The Dependency Graph」2026-08-18 確認
Any time one file depends on another, webpack treats this as a dependency.
原文webpack 公式ドキュメント「The Dependency Graph」 この内容の有効期限2027-02-18

よくある質問

webpackは何を集めますか
入口からたどれる記述です。依存をたどって図を作り、そこに含まれるものだけをまとめます。
入口の数はどう効きますか
強く効きます。この計測では1個で96.2%落とせたものが、30個では59.7%まで下がりました。
入口はどう決めますか
利用者が最初に開く単位です。ここから始めて図が作られるので、増やすほど到達範囲が広がります。
落とせない記述はありますか
たどれてしまうものです。1つのファイルが別のファイルに依存した時点で、依存として扱われます。

まとめ

  • 入口から依存をたどる
  • たどれない分は落とせる
  • 入口が増えると落とせなくなる
  • 依存は1行で生まれる

今日から始められること

  1. いまの入口の数を数える
  2. 入口ごとに到達する単位を数える
  3. 複数の入口から使われている単位を探す
  4. 使っていない取り込みが残っていないか見る

実務で組んだwebpackのワークフローには、値段が付きます

同じ課題を持つ会社にとって、動いている設定は「作る時間」を買えるということです。ServiceDockは自作のワークフローやテンプレートを出品できるマーケットプレイスです。手数料や出品の流れは出品者向けページにまとまっています。

出品の仕組みを見る