記述の単位300個で、1つずつ全部変えてみました。作り直しになるのは中央値3個です。
ところが99%点は282個でした。全部作り直す300個とほとんど変わりません。
半分の変更は3個で終わります。ただし残りの一部は、全部作り直すのとほぼ変わりません。
Viteが差し替えるのはその単位だけです。出典はこう説明しています。
ファイルを編集すると、Viteはその単位だけをブラウザ上で更新するために、標準の仕組みの上で差し替えを使い、ページ全体の再読み込みも作り直しの待ちも起こさなかったという記述です。
ただしその単位を使っている側は作り直しになります。範囲がどれだけ広がるかを数えました。
記述の単位300個の依存の図を作り、300通りすべてを試しました。
記述の単位 300個。1単位を作り直すのに 8ms かかる 1つ変えたとき、それを使っている側をすべて作り直す やり方 作り直す単位 かかる時間 全部作り直す 300個 2.40秒 使っている側だけ（中央値） 3個 0.02秒 使っている側だけ（平均） 21.9個 0.18秒 使っている側だけ（99%点） 282個 2.26秒
中央値は3個・0.02秒です。半分の変更は、待ち時間として感じません。
平均は21.9個まで上がります。中央値と平均が7倍違うのは、分布が偏っているためです。
99%点は282個・2.26秒でした。全部作り直す2.40秒との差は0.14秒しかありません。
つまり一部の変更については、差し替えの仕組みが効いていません。
該当するのは、多くの単位から使われている下のほうの記述です。共通の設定や型の定義が典型になります。
体感を決めるのはここです。普段は速いのに、ときどき待たされるという形になります。
半分は3個で終わるが、遅いほうの端は全部作り直しとほぼ同じ。
When you edited a file, Vite used Hot Module Replacement (HMR) over native ESM to update just that module in the browser, without a full page reload or waiting for a rebuild.原文Vite 公式ドキュメント「Why Vite」 この内容の有効期限2027-02-18
細かく分けるほど取り直す量は減りますが、取りに行く回数がそのまま増えます。
Viteは開発中と本番で作りを変えます。出典は理由をこう述べています。
まとめない形式は開発中はうまく働くものの、それを本番に出すことは、入れ子になった取り込みによる追加の往復のせいで、依然として効率が悪いという記述です。
では、まとめる数をいくつにすればよいのか。取り直す量と取りに行く回数を並べて数えました。
記述の単位 300個、合わせて 6350KB まとめる数を変えて、1回の更新で取り直しになる量を見る まとめる数 1つあたりの大きさ 更新1回で取り直す量 取りに行く回数 1個 6349.7KB 6349.7KB 1回 4個 1587.4KB 1600.5KB 4回 16個 396.9KB 386.1KB 16回 60個 105.8KB 120.3KB 60回 300個 21.2KB 23.6KB 300回
1つにまとめると、1文字直すたびに6349.7KBを配り直します。
300個に分ければ23.6KBです。269分の1になります。
右端の列がそのまま増えます。300個に分けると取りに行く回数も300回です。
初めて開く利用者は、この300回を全部払います。更新のたびに得をするのは、2回目以降に来た利用者だけです。
16個あたりが折り返しになります。取り直す量は6349.7KBの16分の1まで落ち、回数は16回にとどまります。
細かく分けるほど、取り直す量と取りに行く回数が入れ替わる。
Even though unbundled ESM works well during development, shipping it in production is still inefficient due to additional network round trips from nested imports.原文Vite 公式ドキュメント「Why Vite」 この内容の有効期限2027-02-18
小さいうちはどの道具でも同じです。差が出るのは、単位の数が増えてからでした。
Viteが出てきた前提は規模です。出典はウェブアプリケーションの規模と込み入り方が増すにつれ、それらを組み立てる道具は追いつくのに苦労してきたと述べています。
この計測でも同じことが出ます。300個だから2.40秒で、30個なら0.24秒です。
全部作り直しても0.24秒なら、差し替えの仕組みは要りません。待ち時間として感じない範囲だからです。
効いてくるのは、全部作り直すと待たされる規模からです。その境目は、単位あたりの時間と数の掛け算で決まります。
この計測では1単位8msと置きました。実際の値は自分の環境で全部作り直して割れば出ます。
3番目は依存の図から出せます。数え方はモノレポの記事で扱った到達範囲の計算と同じです。
依存の図は式で作ったものです。実際の構成では、共通の記述がもっと少数に集中していることが多く、その場合は中央値がさらに下がり、遅いほうの端がより極端になります。1単位8msという値も置いたものです。ここで見せているのは、中央値と99%点が2桁違うという関係で、それは全通り試せば自分の構成でも出せます。
As web applications have grown in size and complexity, the tools used to build them have struggled to keep up.原文Vite 公式ドキュメント「Why Vite」 この内容の有効期限2027-02-18
同じ課題を持つ会社にとって、動いている設定は「作る時間」を買えるということです。ServiceDockは自作のワークフローやテンプレートを出品できるマーケットプレイスです。手数料や出品の流れは出品者向けページにまとまっています。
出品の仕組みを見る