【ITニュース解説】I Benchmarked Signals vs Virtual DOM — Here’s What I Found

ウェブアプリケーションの画面（ユーザーインターフェース、UI）を効率的に、そして素早く動かすことは、利用者にとって快適な体験を提供する上で非常に重要である。この分野ではこれまで、Reactなどの人気フレームワークが採用してきた「Virtual DOM（仮想DOM）」という技術が主流だった。しかし、最近では「Signals（シグナル）」と呼ばれる新しいアプローチが登場し、その性能の高さが注目されている。ここでは、これら二つの技術の仕組みと、実際の性能比較から見えてきたシグナルの優位性について解説する。

まず、Virtual DOMの仕組みから説明する。Virtual DOMは、2013年にReactによって広められ、Vueなどの他のフレームワークにも採用され、フロントエンド開発の標準となった。従来のWeb開発では、画面の一部を変更するたびにブラウザが管理する実際のDOM（Document Object Model）を直接操作する必要があり、これは複雑で非効率な処理だった。そこでVirtual DOMは、ブラウザのDOMを直接操作する代わりに、UIの状態を表現する「仮想のDOMツリー」をメモリ上に保持する。UIの状態に変化があったとき、フレームワークは新しい仮想DOMツリーを生成し、それを以前の仮想DOMツリーと比較する。この比較によって変更があった部分（差分）だけを検出し、その差分のみを実際のDOMに適用するという方法である。この抽象化のおかげで、開発者はUIの状態変化について深く考えることなく、宣言的にコードを書けるようになり、大規模なUI開発が非常に容易になった。

しかし、Virtual DOMにはいくつかの課題がある。最も大きな問題は、その更新の粒度が「粗い」ことである。状態が変化すると、フレームワークは「コンポーネントとその子孫すべてが変更されたかもしれない」と仮定し、関連するコンポーネント全体を再描画しようとする。何が具体的に変更されたかを正確に把握できないため、変更された可能性のあるサブツリー全体を再生成し、差分を比較するという大掛かりな処理が発生する。この差分比較自体も、ツリーのサイズに比例して処理時間が増大するため、効率が悪くなる。開発者は、不要な再レンダリングを防ぐためにuseMemoやuseCallbackといった最適化の仕組みを利用する必要があり、これらは開発者の負担となる。小さなアプリケーションでは問題なくても、大規模なアプリケーションになると、数千もの冗長なDOM操作やメモリの無駄遣い、さらにはブラウザのメインスレッドを長時間ブロックする原因となり、アプリケーションの応答性が低下する可能性がある。

これに対し、SignalsはVirtual DOMの考え方を根本から変えるアプローチである。Signalsは「全てが変わったかもしれない」と仮定するのではなく、「何が変更されたか正確にわかる」というシンプルな原則に基づいている。シグナルは、値を格納し、その値を読み取るすべてのコードやDOMのバインディング（接続）を追跡する小さなリアクティブな要素である。シグナルの値が更新されると、そのシグナルに「依存している」特定のコードやDOMバインディングだけが再実行される。つまり、グローバルな再レンダリングも、ツリーの差分比較も発生せず、無駄な処理が一切ない。更新処理は常に一定の時間で完了し、変更が非常に局所的に適用されるため、極めて効率的である。Solid.jsというフレームワークは、このシグナルモデルを最初から採用しており、Angularもバージョン16からシグナルを導入し、今後のリアクティブシステムの基盤として位置づけている。

実際の性能を比較するため、筆者はReact（Virtual DOM）とSolid.js（Signals）で全く同じ機能を実装した二つのアプリケーション（ダッシュボード）を作成し、6つの一般的なシナリオでベンチマークテストを実施した。テストシナリオには、フィルタリング、継続的な更新、大量の要素の挿入、削除、ソート、そしてアプリケーションが何も操作されないアイドル状態が含まれる。各シナリオで、DOM操作の回数、更新にかかる時間（遅延）、使用メモリ量（ヒープサイズ）、そしてブラウザのメインスレッドを50ミリ秒以上ブロックする「ロングタスク」の数を測定した。Reactは意図的にuseMemoなどの最適化を適用しないデフォルトの状態でテストし、Virtual DOM自体の効率を評価した。

ベンチマークの結果は非常に印象的だった。 まず、DOM操作の回数について、SignalsはVirtual DOMに比べて圧倒的に少なかった。ソート操作のシナリオでは、Reactが101,997回ものDOM操作を発生させたのに対し、Solid.jsはわずか7回に抑えられた。これは1万4500倍以上の改善であり、全体としてSignalsはDOM操作を最大99.9%削減したことになる。アイドル状態のシナリオでも、Reactはバックグラウンドで約1万回のDOM操作が発生したが、Solid.jsは2回とほぼ安定していた。 次に、メモリ使用量では、SignalsがVirtual DOMに比べて大幅に少ないことが示された。Reactのヒープ使用量が最大で2.4GBに達したのに対し、Solid.jsは約675MBに留まった。これは、Signalsが常に70%から75%のメモリ削減を実現していることを意味する。 更新遅延（操作開始からUIの更新完了までの時間）についても、SignalsはVirtual DOMを大きく上回った。連続的な更新のシナリオでは、Reactの処理時間が8,298ミリ秒だったのに対し、Solid.jsは541ミリ秒で完了し、93.5%の高速化を達成した。Solid.jsはほとんどのシナリオで、Reactよりも30%から94%速くUIを更新できた。 ロングタスクの発生頻度と時間も、Signalsがはるかに優れていた。Reactが数十回のロングタスクを発生させ、メインスレッドを8秒以上ブロックすることがあったのに対し、Solid.jsはほとんどのシナリオで1〜2回のロングタスクに抑えられ、合計時間も1秒未満だった。連続更新のシナリオでは、Reactが51回のロングタスクを発生させたのに対し、Solid.jsは1回だった。

これらの結果が示すのは、SignalsがVirtual DOMと比較して、DOM操作の効率、メモリ使用量、更新速度において桁違いの改善をもたらすということである。特にデータ量が多い、あるいは頻繁にUIが更新されるような複雑なアプリケーションにおいて、その差は顕著に現れる。

Signalsがこのような優れた性能を発揮する理由は、そのアーキテクチャにある。Virtual DOMは「何が変更されたか分からないから、とりあえず全てを再確認する」というアプローチであり、このために常に不要な処理が発生する可能性がある。これに対してSignalsは、「何が変更されたか正確に知っているから、その部分だけをピンポイントで更新する」というアプローチを取る。これにより、仮想DOMの生成や差分比較といったオーバーヘッドが完全に不要になる。

この仕組みは、開発者体験も簡素化する。開発者は、不要な再レンダリングを避けるためのuseMemoのような最適化フックを意識する必要がなくなる。アプリケーションのパフォーマンスがデフォルトで高くなるため、開発者は「どうすれば高速化できるか」ではなく、「何を実装したいか」に集中できる。

Signalsの採用は、Solid.jsだけでなく、AngularやPreact Signalsといった他のフレームワークでも進んでおり、Webフロントエンド開発の新たな標準となりつつある。これは単なる一時的な最適化ではなく、現代のUI構築における根本的なアーキテクチャの進化である。アプリケーションがよりリッチでデータ駆動型になるにつれて、Signalsが提供するパフォーマンスとシンプルな開発者体験の価値は、今後ますます重要になるだろう。