【実務・中級編】V8エンジンの最適化を阻害する「var」：コンパイル時の静的解析とスコープ汚染のコスト – JavaScriptコア文法・モダン言語仕様と変数・関数解析バイブル

V8エンジンの最適化を阻害する `var`：コンパイル時の静的解析とスコープ汚染のコスト

コードレビューの場で、未だに `var` を見かけることはないだろうか。「動くからいい」「昔からの慣習だから」という理由で放置されたその数文字が、ブラウザのJavaScriptエンジン、特にV8のパフォーマンスをどれほどスポイルしているかを知るエンジニアは意外と少ない。

我々はフロントエンドのパフォーマンスを語る時、バンドルサイズやLCP（Largest Contentful Paint）、不要な再レンダリングばかりに目を奪われがちだ。しかし、ランタイムの根底にあるJavaScriptの書き方そのものが、V8のコンパイルパイプラインを破壊しているという事実を見落としてはならない。

今回は、V8エンジンの内部挙動、特にIgnition（インタプリタ）からTurboFan（最適化コンパイラ）に至るライフサイクルにおいて、なぜ `var` が毒となり得るのか。そのメカニズムをコードの深部から紐解き、実務で使える堅牢な設計論へと昇華させよう。

—

1. V8エンジンの視点：なぜ `var` はコンパイル時の静的解析を殺すのか

スコープの曖昧さと「巻き上げ（Hoisting）」の代償

モダンなJavaScriptエンジン（V8）は、コードを実行する前にAST（抽象構文木）を生成し、バイトコードへとコンパイルする。この段階で、エンジンは変数がどのスコープに属し、どこでメモリを割り当てるべきかを決定（静的解析）しようとする。

ここで `let` や `const` が登場した場合、それらはブロックスコープ（Lexical Environment）にバインドされ、TDZ（Temporal Dead Zone：一時的死領域）によって厳密に管理される。エンジンは「この変数はこのブロックの内側だけで生存し、スコープを抜ければ即座にガベージコレクションの対象になり得る」と確信できる。

一方、`var` はどうか。
`var` は関数スコープを持ち、巻き上げ（Hoisting）によって、宣言前であっても関数内のどこからでも `undefined` としてアクセスできてしまう。

function processTransaction(isValid) {
if (isValid) {
var fee = 100; // ブロック内で宣言しているつもりが…
}
return fee; // ブロック外の関数スコープから参照可能（undefined または 100）
}

この仕様は、V8のスコープ解析器に余計な負荷をかける。変数 `fee` がどこまで生存し、どのレジスタやスタックフレームに割り当てるべきか、コンパイラが「静的に確定」しにくくなるのだ。結果として、変数の実体がヒープ上のコンテキスト（Contextオブジェクト）に逃げる（Heap Allocation / Context Allocation）確率が跳ね上がる。

インライン展開（Inlining）の失敗と最適化の壁

V8の最適化コンパイラ「TurboFan」の最大の武器の一つは、インライン展開（Function Inlining）である。頻繁に呼び出される小さな関数の中身を、呼び出し元のコードに直接埋め込むことで、関数呼び出しのオーバーヘッドをゼロにする最適化手法だ。

しかし、関数内に `var` が乱用され、変数のスコープが曖昧になっていると、TurboFanは最適化の安全性を証明できなくなる。

1. 変数がどこからでも書き換えられる可能性（スコープ汚染）が残る。
2. 最適化の前提条件（プロパティの形状や変数の型）が崩れやすくなる。
3. 結果：Deoptimization（最適化解除）が発生し、コードは低速なインタプリタ実行へとフォールバックする。

数ミリ秒を削り出す高頻度のDOM操作や、膨大な配列処理のループ内において、この `Deopt` の発生は致命的なパフォーマンス低下を招く。

—

2. 実務の現場で直面するアンチパターンと修正アプローチ

実際のプロダクションコードで、`var` の存在がどのように保守性とパフォーマンスを破壊しているかを見てみよう。以下は、よくある非効率な非同期API連携のコードだ。

❌ アンチパターン：`var` によるスコープ汚染とクロージャの罠

// 【アンチパターン】保守性が低く、V8の最適化を阻害するコード
function setupEventHandlers(items) {
var results = [];

for (var i = 0; i < items.length; i++) { var item = items.i; // そもそもタイポがあるが、varのせいでiは関数スコープ全体に漏れる // 非同期処理を伴うイベントリスナーの登録 document.getElementById(`btn-${i}`).addEventListener('click', function() { // ループ変数がvarで宣言されているため、クロージャが参照する 'i' は // ループ終了後の最終的な値に固定されてしまう典型的なバグ fetchData(items[i]).then(function(res) { results.push(res); }); }); } } このコードの問題点は二つある。 1. `var i` が関数スコープ全体に漏れ出し、非同期コールバックが意図しないインデックスを参照するバグ（IIFEなどで無理やり凌がれていた古い時代の遺物）。 2. V8がこの変数を最適化できず、クロージャ内の変数をヒープに退避させるための余分なメモリ割り当てコストが発生する点。 ---

✅ プロダクション・リファクタリング：ブロックスコープとイミュータビリティの徹底

上記のコードを、V8の最適化パースに優れ、かつバグの起きない堅牢な設計に書き換える。

/