自作ブラウザエンジンFalcoに学ぶ、独自レンダラー採用の落とし穴

Rust（メモリ安全性を重視したシステムプログラミング言語）で書かれたブラウザエンジン「Falco」のv0.1.0が公開されました。WebKit・Gecko・Chromiumといった既存エンジンに一切依存せず、約36,000行のRustコードでHTMLパーサーからJavaScript VM（仮想マシン）までをゼロから実装しています。

この手のプロジェクトを見ると「自社サービスでも軽量な独自レンダラーを検討してみようか」と考えるフロントエンドエンジニアも出てくるかもしれません。ここでは、Falcoのような従来型ブラウザエンジンを使わない選択肢を評価するときに、どこで足元をすくわれやすいかを整理します。

何が起きるか：仕様準拠と互換性のギャップ

FalcoはWHATWG（Web標準の策定団体の一つで、HTML Living Standardを管理）のHTML5仕様に沿って、トークナイザー（HTML文字列を意味のある単位に分割する処理）の80状態、ツリービルダーの22挿入モードを実装しています。

これは非常に丁寧な仕様準拠です。一方で、CSSのセレクタLevel 4や:has()疑似クラス、Container Queries（要素のサイズに応じてスタイルを変える機能）まで対応しているとはいえ、実際のWebサイトはChromiumのレンダリング挙動に最適化されたコードが大量に存在します。

新規エンジンを本番投入すると、仕様上は正しくてもChromeとの微妙なレンダリング差異（フォントのフォールバック順、フレックスボックスの丸め誤差など）が発生する可能性があります。これは「何かがおかしいのに再現条件が絞れない」という厄介な不具合として現れがちです。

なぜ起きるか：JITとGCの実装差がボトルネックになる

原因を段階的に見ていきます。まずJavaScript実行系です。FalcoはtjsというカスタムバイトコードVMを持ち、世代別GC（ガベージコレクション、使われなくなったメモリを回収する仕組み）とインラインキャッシュ、JITティアアップ（実行頻度の高いコードを機械語に変換して高速化する仕組み）をx86_64限定で備えています。

V8（Chromeが使うJavaScriptエンジン）は10年以上かけてTurboFan・Sparkplug・Maglevといった複数階層のJITコンパイラを磨き上げてきました。新規VMがPromiseやGenerator、Proxyまで実装していても、実行速度の最適化はV8と同じ土俵に立てるわけではありません。

次にレイアウトエンジンです。FalcoはFlexboxとCSS Gridを実装済みですが、レイアウトエンジンの挙動が1ピクセルでもズレると、ピクセルパーフェクトなデザインを求めるプロダクトでは致命的な差分になります。

最後にレンダリングパイプライン全体の話です。ブラウザエンジンはHTML/CSS/JSだけでなく、フォントレンダリング、画像デコーダ、ネットワークスタック、セキュリティサンドボックスまで含む巨大なシステムです。36,000行という規模は意欲的ですが、Chromiumのレンダリングエンジンだけで数百万行規模と言われる開発工数と比べると、カバー範囲の差は避けられません。

自分のプロジェクトが該当するか確認する方法

新しいレンダリングエンジンや軽量ブラウザランタイムを検討する前に、次の観点で自プロジェクトを棚卸しすることをおすすめします。

対象ブラウザの実配布シェアを「caniuse.com」やGoogle Analyticsの実測データで確認する
使用中のCSS機能（Container Queries、「:has()」、Cascade Layersなど）を「package.json」の「browserslist」設定や「.browserslistrc」から洗い出す
ReactやVue製SPAであれば、依存しているDOM API（MutationObserver、Shadow DOM、Custom Elementsなど）をgrepコマンドで棚卸しする
サードパーティ製ウィジェット（決済フォーム、地図、広告タグなど）がChromium固有の挙動に依存していないかベンダーのドキュメントで確認する
CIのE2Eテスト（PlaywrightやCypress）が現在どのブラウザエンジンをターゲットにしているか設定ファイルで確認する

これらの棚卸しで「Shadow DOMやCustom Elementsを多用しているWeb Components設計」「Container Queriesなど比較的新しいCSS機能に依存」と分かった場合、新興エンジンへの乗り換えはリスクが高いと判断できます。

対策の手順

新規ブラウザエンジンやレンダリング系ツールを評価する際は、次の手順を踏むと安全に判断できます。

# 1. 対象エンジンのリリースノートとテストカバレッジを確認
git clone https://github.com/poxk/Falco
cat Falco/CHANGELOG.md 2>/dev/null || ls Falco/releases

# 2. Web Platform Tests（W3C標準の互換性テストスイート）への対応状況を探す
grep -ri "wpt\|web-platform-tests" Falco/README.md

# 3. 自プロジェクトのCSS/JS機能使用状況を洗い出す
npx browserslist

Web Platform Tests（WPT、業界標準の互換性テストスイート）へのスコアが公開されていない、あるいは低い場合は、まだ実運用より検証目的のプロジェクトと捉えるのが妥当です。

評価用途であれば、本番トラフィックには使わず、社内ツールや技術検証用のサンドボックス環境限定で試すのが現実的な落としどころです。

また、エッジランタイム（Cloudflare WorkersやDenoのようなV8ベースの軽量実行環境）やWebAssemblyを使った部分的な高速化と、ブラウザエンジンそのものを置き換える話は次元が異なります。前者はNode.jsの代替として広く実運用されていますが、後者はレンダリングパイプライン全体を自作エンジンに委ねる話であり、リスクの大きさが一桁違います。混同しないよう区別して評価してください。

まとめ

Falcoのような自作ブラウザエンジンは、HTML5・CSS・JavaScript VMまで仕様に忠実に実装しており、技術的な学習素材として価値があります。

一方で本番プロダクトに導入するかどうかは別問題です。まず「browserslist」やgrepコマンドで自プロジェクトの依存機能を棚卸しし、WPTスコアやリリースの成熟度を確認してから判断するのが安全です。

新興エンジンを試すなら、本番環境ではなく検証用サンドボックスから始め、既存のE2Eテストスイートで差分を可視化するところから着手してみてください。