フロントエンドの世界に足を踏み入れてしばらく経つと、誰もが一度は「なぜReactやVueは、わざわざVirtual DOMなんていう面倒なものを挟むのか？」という疑問にぶち当たります。
ブラウザのレンダリングエンジン（BlinkやWebKit）は、実は非常に優秀です。しかし、JavaScriptから直接DOMを操作する際、開発者が不用意に「重い処理」を連発すると、ブラウザは悲鳴を上げます。今日は、その「悲鳴」をいかに未然に防ぎ、裏側で何が起きているのかを、アーキテクトの視点から紐解いていきましょう。
—
1. DOM操作が「高コスト」だと言われる本当の理由
ブラウザにとって、DOMツリーとCSSOMツリーを合成してレンダリングパイプラインを回すことは、CPUとGPUをフル回転させる一大プロジェクトです。
- リフロー（Reflow/Layout）: DOMのサイズや位置が変わると、ページ全体の計算をやり直す。
- リペイント（Repaint）: 色や背景など、見た目が変わると描画をやり直す。
- コンポジット（Composite）: レイヤーを重ね合わせる。
これらは、現代のWebサイトにおいて「パフォーマンスのボトルネック」の代名詞です。Virtual DOMの本質は、「これらの重い処理を、最小限の回数に抑えるためのバッファ」に過ぎません。JavaScriptのメモリ上で構造を比較し、ブラウザに対して「ここだけ変えてくれ」という指示書を最短経路で叩きつける、いわば「調整役」なのです。
—
2. 差分検出（Diffing）のアルゴリズム：魔法ではない「妥協の産物」
Reactなどが採用している差分検出アルゴリズムは、実は「二つのツリーを完全に比較する」という数学的に厳密な処理をすると、計算量が $O(n^3)$ になってしまい、現実的な速度が出ません。
そこで彼らがとった戦略は、「実用性を最優先したヒューリスティック（経験則）な近似」です。
1. 同階層のみを比較: 異なる階層への移動は無視する（割り切り）。
2. 型が違えば即座に破棄: `
3. Keyによるリストの最適化: 順序の入れ替えを検知するために、ユニークな `key` を使う。
この「割り切り」があるからこそ、私たちは毎フレーム60fpsの滑らかなアニメーションを享受できているのです。
—
3. 実践：差分検出の考え方をコードで実装してみる
「ブラックボックスに頼るな、中身を知れ」が我がチームの合言葉です。簡単なDOMの更新関数を書いてみましょう。ブラウザ標準の `diff` 処理を簡易的に再現するアプローチです。
/
- 簡易的なDOM更新関数
- 仮想DOMの考え方：現在のDOMと新しいDOMを比較し、
- 変更があった場所だけをピンポイントで更新する
/
function updateElement($parent, newNode, oldNode, index = 0) {
// 1. ノードが削除された場合
if (!newNode) {
$parent.removeChild($parent.childNodes[index]);
}
// 2. ノードが追加された場合
else if (!oldNode) {
$parent.appendChild(render(newNode));
}
// 3. 差分がある場合（タグの変更や属性の変更）
else if (changed(newNode, oldNode)) {
$parent.replaceChild(render(newNode), $parent.childNodes[index]);
}
// 4. 子要素の再帰的な比較
else if (newNode.type) {
const newLength = newNode.children.length;
const oldLength = oldNode.children.length;
for (let i = 0; i < Math.max(newLength, oldLength); i++) {
updateElement(
$parent.childNodes[index],
newNode.children[i],
oldNode.children[i],
i
);
}
}
}
// 変更の有無を判定（ここを最適化するのがライブラリの腕の見せ所）
function changed(node1, node2) {
return typeof node1 !== typeof node2 ||
(typeof node1 === 'string' && node1 !== node2) ||
node1.type !== node2.type;
}
このコードのポイントは、`changed` 関数で「比較のコスト」を極限まで削っている点です。実務ではここに、さらに `props` の深い比較（Deep Equal）や、キャッシュ戦略が加わります。
---
4. シニアとしてのアドバイス：最適化の罠
最後に、現場でよくある失敗を一つ。
「Virtual DOMがあるから、DOM操作を意識しなくていい」というのは半分正解で、半分間違いです。
Reactの `memo` や `useMemo` を無闇に使うエンジニアがいますが、比較そのもののコストが、再レンダリングのコストを上回ることが多々あります。「何でもメモ化する」のではなく、ブラウザのレンダリングパイプラインを俯瞰し、「どこが重いのか」をChrome DevToolsの「Performance」タブで計測することから始めてください。
結局のところ、最高のパフォーマンスは「無駄な計算をしないこと」ではなく、「ブラウザに余計な仕事をさせないこと」に帰結します。
Virtual DOMはあくまで「便利な道具」です。その下にあるブラウザのレンダリングの泥臭い現実を理解していれば、あなたも一段上のフロントエンドエンジニアになれるはずです。さあ、次はコードを書いて、実際にプロファイリングを回してみましょう。
コメント